System.NullReferenceException

I have a crash reporter integrated in my application and get the following stack trace sent from a few few clients:

Top-level ExceptionType: System.NullReferenceExceptionMessage: Object reference not set to an instance of an object.Source: AutomaticUpdaterStack Trace: at wyDay.Controls.UpdateHelper.bw_RunWorkerCompleted(Object sender, RunWorkerCompletedEventArgs e) at System.ComponentModel.BackgroundWorker.OnRunWorkerCompleted(RunWorkerCompletedEventArgs e) at System.ComponentModel.BackgroundWorker.AsyncOperationCompleted(Object arg)

AutomaticUpdater, Version=2.6.18.4

Is this a bug?

Well, the AutomaticUpdater shouldn't crash, so yes, I'd say it's a bug. But it's a bug I believe we've already fixed. Try the latest version of the AutomaticUpdater from subversion.

Thanks for the hint. Using the SVN head the updater just hangs at InstallNow() and the application freezes. In my case it looks as follows:

updater.ReadyToBeInstalled += delegate {... updater.InstallNow(); };

Reproduced on different boxes.

Any ideas?

I'll look into this.

The problem seems to be a little bit different. Did some more testing with the SVN head version and it looks like with r113 you introduced a deadlock I hit when a new update is available. My updater works in the background and shows a custom form in case of a new update available.

--> Worker Thread (holds _lock):

AutomaticUpdater.dll!wyDay.Controls.AutomaticUpdater.InvokeMyself(System.Delegate method, object[] args) Line 519 + 0x41 bytes C# AutomaticUpdater.dll!wyDay.Controls.AutomaticUpdater.auBackend_UpdateAvailable(object sender, System.EventArgs e) Line 626 + 0x85 bytes C# AutomaticUpdater.dll!wyDay.Controls.AutomaticUpdaterBackend.UpdateReady() Line 641 + 0x34 bytes C# AutomaticUpdater.dll!wyDay.Controls.AutomaticUpdaterBackend.StartNextStep(wyUpdate.Common.UpdateStep updateStepOn) Line 608 + 0xa bytes C# AutomaticUpdater.dll!wyDay.Controls.AutomaticUpdaterBackend.updateHelper_ProgressChanged(object sender, wyUpdate.Common.UpdateHelperData e) Line 564 + 0x18 bytes C# AutomaticUpdater.dll!wyDay.Controls.UpdateHelper.ProcessReceivedMessage(wyUpdate.Common.UpdateHelperData data) Line 610 + 0x35 bytes C# AutomaticUpdater.dll!wyDay.Controls.UpdateHelper.SafeProcessReceivedMessage(byte[] message) Line 526 + 0x10 bytes C# AutomaticUpdater.dll!wyDay.Controls.PipeClient.Read() Line 221 + 0x44 bytes C#-> Invoke on ownerForm's thread (in my case MainThread):

AutomaticUpdater.dll!wyDay.Controls.UpdateHelper.FlushResponses() Line 146 + 0x24 bytes C# AutomaticUpdater.dll!wyDay.Controls.AutomaticUpdaterBackend.FlushResponses() Line 266 + 0x20 bytes C# AutomaticUpdater.dll!wyDay.Controls.AutomaticUpdater.ownerForm_Load(object sender, System.EventArgs e) Line 1546 + 0x26 bytes C# [External Code] Cyberduck.exe!Ch.Cyberduck.Ui.Winforms.BaseForm.Show() Line 249 + 0xa bytes C# Cyberduck.exe!Ch.Cyberduck.Ui.Winforms.UpdateForm.ConfigureUpdater.AnonymousMethod__2(object param0, System.EventArgs param1) Line 161 + 0xd bytes C#

-> Deadlock since the MainThread tries to acquire the lock in FlushResponses which is already held by the worker thread.

I can confirm that there are deadlocks in the latest SVN version of AutomaticUpdater. In our application it locks up 50% of the time in ForceCheckForUpdate().

The code in SVN isn't release-ready yet.

Reply
Discard post