Page Index Toggle Pages: [1] 2  Send TopicPrint
Hot Topic (More than 10 Replies) Crash in EndInit() (Read 14569 times)
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
Crash in EndInit()
Mar 7th, 2014 at 10:36am
Print Post  
Hi there,

--> sorry for the double post - I've opened this issue previously in a wrong board.

i have a Calendar control in ResourceView mode. We thought it could be a good idea to use BeginInit() and EndInit() during an update of the Calendar (adding or changing resources, items and so on). But sometimes it's not. We experience crashes after a certain time of use but the crashes are very hard to reproduce. Yesterday we had one at the customers site Sad Here's a stack trace of it:

System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
   bei MindFusion.Scheduling.WinForms.x421238209b42e1b3.x7d1bbacb2d98f3cb(Nullable`1 x10aaa7cdfa38f254, Nullable`1 xca09b6c2b5b18485)
   bei MindFusion.Scheduling.WinForms.x11db8fc7f469a2fc.x7d1bbacb2d98f3cb(Nullable`1 x10aaa7cdfa38f254, Nullable`1 xca09b6c2b5b18485)
   bei MindFusion.Scheduling.WinForms.Calendar.EndInit()
   bei Com.Xavo.BAT.IFO.GUI.Screens.GanttView.buildViewFromModel() in c:\Users\cschwarz\Documents\hg\bfo-source\GUI\Screens\GanttView.cs:Zeile 590.
   bei Com.Xavo.BAT.IFO.GUI.Screens.GanttView.<populateChart>b__29(IJobResult result) in c:\Users\cschwarz\Documents\hg\bfo-source\GUI\Screens\GanttView.cs:Zeile 270.
   bei Com.Xavo.ClientPlatform.Job.OnWorkerCompleted(Object sender, RunWorkerCompletedEventArgs e)
   bei System.ComponentModel.RunWorkerCompletedEventHandler.Invoke(Object sender, RunWorkerCompletedEventArgs e)
   bei System.ComponentModel.BackgroundWorker.OnRunWorkerCompleted(RunWorkerCompletedEv

entArgs e)
   bei System.ComponentModel.BackgroundWorker.AsyncOperationCompleted(Object arg)

MindFusion.Scheduling
Assembly-Version: 5.4.4.14498.
Win32-Version: 5.4.4.14498.

It would be a great help for us to know in what circumstances this could happen, maybe we could provide some prevention for it.

Best regards
Achim
  
Back to top
WWW  
IP Logged
 
Meppy
God Member
*****
Offline


MindFusion support

Posts: 1783
Joined: Jul 20th, 2005
Re: Crash in EndInit()
Reply #1 - Mar 7th, 2014 at 12:46pm
Print Post  
Hi,

This is weird. The only object that can be null at the specified line is initialized in the Calendar's constructor and is never assigned to null afterwards. So the only possibility for a NullReference that I can see is that EndInit is called before this object is initially assigned. And I can see no scenario that this could happen. Can you provide more information about the context of the exception, such as the code that calls EndInit?

Regards,
Meppy
  
Back to top
 
IP Logged
 
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
Re: Crash in EndInit()
Reply #2 - Mar 7th, 2014 at 2:50pm
Print Post  
Hi Meppy,

unfortunately I cannot provide the full source code of the method that does the refresh for both complexity and confidentiality reasons. So let me show you the main parts regarding the calendar control:

Code (C++)
Select All
// suspend gantt control
ganttChart.BeginInit();

// clear the gantt items
ganttChart.Schedule.Items.Clear(); 



This is followed by a fairly complex part which reads a data structure and adds resources and gantt items (appointments) to the calendar control. We finish it like this:

Code (C++)
Select All
// restore position
ganttChart.ScrollPosition = scrollPos;

// resume UI
ganttChart.EndInit(); 



So there is no special magic in here. Today we made a test on out test system with a client application that has the BeginInit() and EndInit() calls, and another that does not call these methods. It seems to work better without these calls (the first client crashed after 20 Minutes, the second did not).

So the question is: does the Calendar control need the BeginInit() and EndInit() calls or are they kind of optional?

Achim
  
Back to top
WWW  
IP Logged
 
Meppy
God Member
*****
Offline


MindFusion support

Posts: 1783
Joined: Jul 20th, 2005
Re: Crash in EndInit()
Reply #3 - Mar 7th, 2014 at 4:17pm
Print Post  
Hi,

The BeginInit/EndInit methods are optional, but they can (and are specifically designed to) improve the initialization speed of the control by suspending unnecessary updates until after the initialization is complete.

Our only guess is that this problem may have something to do with multi-threading (seeing that you use background workers). Keep in mind that the control is not thread-safe. If you are populating the data from a different thread, try detaching the Schedule from the control before starting the thread and reattaching the schedule again after it completes.

Regards,
Meppy
  
Back to top
 
IP Logged
 
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
Re: Crash in EndInit()
Reply #4 - Mar 10th, 2014 at 10:37am
Print Post  
Hi Meppy,

that was exactly my intention to use BeginInit/EndInit. I removed the calls and it seems to make no difference in terms of performance and user experience. So we seem to have a workaround to make the customers solution run stable.

But after all I'm curious to know what the problem is. One of my first thoughts was the threading issue too. But the calls are made in the RunWorkerCompleted method wich is in the main thread. I've double checked it using the debugger.

What exactly do you mean with "detaching" and "reattaching" the schedule from the control?

Regards,
Achim
  
Back to top
WWW  
IP Logged
 
Meppy
God Member
*****
Offline


MindFusion support

Posts: 1783
Joined: Jul 20th, 2005
Re: Crash in EndInit()
Reply #5 - Mar 10th, 2014 at 10:57am
Print Post  
Hi,

I'm curious about this too. I cannot see any scenario that could lead to this exception. Apart from adding items and resources to the calendar, do you set any other properties or call any methods inside the BeginInit/EndInit block?

By detaching, I mean setting a new, dummy schedule to the calendar so that the changes to the original schedule do not cause updates in the control. For example:

Code
Select All
var schedule = calendar.Schedule;
calendar.Schedule = new Schedule();
// Modify the original schedule here
// ...
// Reattach the schedule once the modifications are completed
calendar.Schedule = schedule; 


Regards,
Meppy
  
Back to top
 
IP Logged
 
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
Re: Crash in EndInit()
Reply #6 - Mar 10th, 2014 at 12:34pm
Print Post  
Hi,

no I only make some Schedule.Items.Add() calls and restoring the scroll position at the end.

What I've seen in the meantime: the Schedule class implements IDisposable. Can you tell me why it is disposable and when it should be disposed? I think the Schedule class is only a data model which represents the current schedule within the calendar and therefore has no resources that have to be disposed, right?

Another information might be important for you: as you can see in the stack trace we have a method called buildViewFromModel(). This method is called about every five minutes when the system has updates for the view. Maybe the issues have to do with our cyclic refresh of the control...

Regards & thanks for any help
Achim
  
Back to top
WWW  
IP Logged
 
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
Re: Crash in EndInit()
Reply #7 - Mar 10th, 2014 at 12:46pm
Print Post  
Hi again,

two more things I have to add: first I also add resources between BeginInit/EndInit. Second I'm wondering if it can lead to problems if I call BeginInit/EndInit twice. Like this:

Code (C++)
Select All
calendar.BeginInit();
//... do something
calendar.BeginInit();
//.. do something else
calendar.EndInit();
calendar.EndInit(); 



What do you think?

Achim

  
Back to top
WWW  
IP Logged
 
Meppy
God Member
*****
Offline


MindFusion support

Posts: 1783
Joined: Jul 20th, 2005
Re: Crash in EndInit()
Reply #8 - Mar 10th, 2014 at 1:58pm
Print Post  
Hi,

The Schedule class keeps an instance of the System.Windows.Forms.Timer class, which it uses to regularly check for reminders. This is the only resource used by the schedule and I think it is not even necessary to dispose it. It might indeed be more appropriate if this function was part of the view rather than the model but its a minor issue.

Regular updates should be no problem for the control. However, it is not intended to nest BeginInit/EndInit calls. Maybe you should try switching to a single BeginInit/EndInit block. Even then, the nested calls should result in unnecessary updates but not exceptions.

Regards,
Meppy
  
Back to top
 
IP Logged
 
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
Re: Crash in EndInit()
Reply #9 - Mar 11th, 2014 at 9:26am
Print Post  
Hi,

uhm, that seems indeed to be better a part of the view. This could only lead to problems if one uses a newly created schedule without disposing the old one for each refresh - but we don't do this, we keep one instance of Schedule for the whole lifetime of the view.

I removed the BeginInit/EndInit nesting but I keep one call to these methods in the outer block because otherwise the vertical scrollbar flickers during updates.

So it seems we run out of ideas what could cause these exceptions right?

Regards,
Achim
  
Back to top
WWW  
IP Logged
 
Meppy
God Member
*****
Offline


MindFusion support

Posts: 1783
Joined: Jul 20th, 2005
Re: Crash in EndInit()
Reply #10 - Mar 11th, 2014 at 10:10am
Print Post  
The NullReference exception happens for an object, which is initialized in the Calendar constructor and the only scenario that this object could ever become null is if you assign a nonexistent view type to the Calendar.CurrentView property. In the latest build we've added a check that this object is not null, but I have no idea how it might be null at this point.

Regards,
Meppy
  
Back to top
 
IP Logged
 
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
Re: Crash in EndInit()
Reply #11 - Mar 12th, 2014 at 4:03pm
Print Post  
Hi Meppy,

is the latest build already released? I have made an inquiry for the source code to your office. So in case the error reproduces on our dev-system we will be able to step in and see what happens.

I made the BeginInit/EndInit calls optional so that we can switch it off at runtime if it ever fails again on the customers system. But I'm not feeling very good with this since we have absolutely no idea what could cause this exception.

Best regards
Achim
  
Back to top
WWW  
IP Logged
 
Meppy
God Member
*****
Offline


MindFusion support

Posts: 1783
Joined: Jul 20th, 2005
Re: Crash in EndInit()
Reply #12 - Mar 13th, 2014 at 9:10am
Print Post  
Hi,

The latest build should be up-to-date with the exception of a single null reference check at the line where the exception happens (inside the Calendar.UpdateItemLanes(DateTime?, DateTime?) method). Try to run your application using the latest official source code and see if you can reproduce this exception. I am curious to learn what might be the cause for this.

Regards,
Meppy
  
Back to top
 
IP Logged
 
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
Re: Crash in EndInit()
Reply #13 - Mar 17th, 2014 at 2:27pm
Print Post  
Hi Meppy,

so far so good: it seems to have to do with nested BeginInit()/EndInit() calls. We had built a version without nested calls and it worked since last Thursday without any issues.

But i've seen another issue: when I don't call BeginInit/EndInit and, remove all resources from the control, and then add a new bunch of resources again, it scrolls to the top. When I do the same WITH BeginInit()/EndInit() calls, it remains on the old vertical scroll position - which is our desired behavior.

So I am experiencing that EndInit does not only affect the performance of the control but also the behavior. Maybe this could lead you to find out what happens...

Best regards
Achim
  
Back to top
WWW  
IP Logged
 
Achim
Junior Member
**
Offline


MindFusion rocks!

Posts: 70
Location: Bayreuth, Germany
Joined: Jun 28th, 2012
It happened again...
Reply #14 - Mar 25th, 2014 at 6:24am
Print Post  
Hi again,

unfortunately it happened again. Obviously your "workaround" to catch the exception did not help - is it maybe another place where the error occurs? Please find attached the stack trace.

One thing we've noticed additionally: we have a crash reporter in the application that should catch all exceptions from the AppDomain and the Application (there are events to subscribe to for handling uncatched exceptions). But this exception is not handled by the crash reporter. When it occurs the Windows JIT Debugger shows a window with the stack trace and error information.

Any thoughts on this?

Best regards
Achim
  

stacktrace.txt (Attachment deleted)
Back to top
WWW  
IP Logged
 
Page Index Toggle Pages: [1] 2 
Send TopicPrint