Sometimes tomboy crashes when I try to delete a note

[caringi]

I'm using tomboy shipped with Fedora 25 (package tomboy-1.15.7-1.fc25.x86_64), and sometimes (not always), when I try to delete a note tomboy crashes with the following backtrace:

Marshaling clicked signal
Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
  at Tomboy.NoteRecentChanges.GetSelectedNotes () <0x4035d910 + 0x000a8> in <filename unknown>:0 
  at Tomboy.NoteRecentChanges.UpdateResults () <0x4035d1e0 + 0x0004b> in <filename unknown>:0 
  at Tomboy.NoteRecentChanges.OnNotesDeleted (System.Object sender, Tomboy.Note deleted) <0x403b6f60 + 0x00017> in <filename unknown>:0 
  at (wrapper delegate-invoke) <Module>:invoke_void_object_Note (object,Tomboy.Note)
  at Tomboy.NoteManager.Delete (Tomboy.Note note) <0x403aacc0 + 0x00161> in <filename unknown>:0 
  at Tomboy.NoteUtils.ShowDeletionDialog (System.Collections.Generic.List`1 notes, Gtk.Window parent) <0x403a8c40 + 0x0033f> in <filename unknown>:0 
  at Tomboy.NoteWindow.OnDeleteButtonClicked (System.Object sender, System.EventArgs args) <0x403a8bb0 + 0x0005f> in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) <0x4027d210 + 0x000a3> in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) <0x4027d210 + 0x00107> in <filename unknown>:0 
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) <0x4027d1d0 + 0x0002a> in <filename unknown>:0 
  at System.Delegate.DynamicInvokeImpl (System.Object[] args) <0x40360830 + 0x0028b> in <filename unknown>:0 
  at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) <0x40360760 + 0x00037> in <filename unknown>:0 
  at System.Delegate.DynamicInvoke (System.Object[] args) <0x40360730 + 0x00018> in <filename unknown>:0 
  at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs args) <0x403605b0 + 0x0015b> in <filename unknown>:0 
  at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) <0x40360570 + 0x0002f> in <filename unknown>:0 
  at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) <0x4035faa0 + 0x002d3> in <filename unknown>:0 
  at GLib.ExceptionManager.RaiseUnhandledException (System.Exception e, Boolean is_terminal) [0x00000] in <filename unknown>:0 
  at GLib.SignalClosure.MarshalCallback (IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) [0x00000] in <filename unknown>:0 
  at Gtk.Application.gtk_main () [0x00000] in <filename unknown>:0 
  at Gtk.Application.Run () [0x00000] in <filename unknown>:0 
  at Tomboy.GnomeApplication.StartMainLoop () [0x00000] in <filename unknown>:0 
  at Tomboy.Application.StartMainLoop () [0x00000] in <filename unknown>:0 
  at Tomboy.Tomboy.StartTrayIcon () [0x00000] in <filename unknown>:0 
  at Tomboy.Tomboy.Main (System.String[] args) [0x00000] in <filename unknown>:0 

[alex-ter]

Is this when deleting from Search All window or note window, or both, maybe?

[caringi]

@alex-ter both...

[chrisbliss18]

I can confirm this behavior. I've been experiencing this at least since June 8.

In my testing, the problem only occurs when running tomboy --search which is how it is set to run from the GUI in Ubuntu's /usr/share/applications/tomboy.desktop file. If I run tomboy --search from the command line, I can recreate the issue. If I run tomboy from the command line, the problem does not occur. Changing the tomboy.desktop to run tomboy also causes the problem to go away when running Tomboy from Unity's Applications panel.

The following is an example error:

Marshaling clicked signal
Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object
  at Tomboy.NoteRecentChanges.GetSelectedNotes () [0x00012] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at Tomboy.NoteRecentChanges.UpdateResults () [0x00001] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at Tomboy.NoteRecentChanges.OnNotesDeleted (System.Object sender, Tomboy.Note deleted) [0x00007] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at (wrapper delegate-invoke) <Module>:invoke_void_object_Note (object,Tomboy.Note)
  at Tomboy.NoteManager.Delete (Tomboy.Note note) [0x000b7] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at Tomboy.NoteUtils.ShowDeletionDialog (System.Collections.Generic.List`1[T] notes, Gtk.Window parent) [0x00103] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at Tomboy.NoteWindow.OnDeleteButtonClicked (System.Object sender, System.EventArgs args) [0x00014] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00038] in <8f2c484307284b51944a1a13a14c0266>:0
   --- End of inner exception stack trace --- 
  at System.Reflection.MonoMethod.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00053] in <8f2c484307284b51944a1a13a14c0266>:0
  at System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) [0x00000] in <8f2c484307284b51944a1a13a14c0266>:0
  at System.Delegate.DynamicInvokeImpl (System.Object[] args) [0x0010d] in <8f2c484307284b51944a1a13a14c0266>:0
  at System.MulticastDelegate.DynamicInvokeImpl (System.Object[] args) [0x0000b] in <8f2c484307284b51944a1a13a14c0266>:0
  at System.Delegate.DynamicInvoke (System.Object[] args) [0x00000] in <8f2c484307284b51944a1a13a14c0266>:0
  at GLib.Signal.ClosureInvokedCB (System.Object o, GLib.ClosureInvokedArgs args) [0x0006d] in <5a439e0caae7469886e7119d9f6bc621>:0
  at GLib.SignalClosure.Invoke (GLib.ClosureInvokedArgs args) [0x0000c] in <5a439e0caae7469886e7119d9f6bc621>:0
  at GLib.SignalClosure.MarshalCallback (System.IntPtr raw_closure, System.IntPtr return_val, System.UInt32 n_param_vals, System.IntPtr param_values, System.IntPtr invocation_hint, System.IntPtr marshal_data) [0x0006c] in <5a439e0caae7469886e7119d9f6bc621>:0
  at GLib.ExceptionManager.RaiseUnhandledException (System.Exception e, System.Boolean is_terminal) [0x00000] in <5a439e0caae7469886e7119d9f6bc621>:0
  at GLib.SignalClosure.MarshalCallback (System.IntPtr raw_closure, System.IntPtr return_val, System.UInt32 n_param_vals, System.IntPtr param_values, System.IntPtr invocation_hint, System.IntPtr marshal_data) [0x00000] in <5a439e0caae7469886e7119d9f6bc621>:0
  at Gtk.Application.gtk_main () [0x00000] in <573b897a54ae4730b20442c8cd3b9a43>:0
  at Gtk.Application.Run () [0x00000] in <573b897a54ae4730b20442c8cd3b9a43>:0
  at Tomboy.GnomeApplication.StartMainLoop () [0x00000] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at Tomboy.Application.StartMainLoop () [0x00000] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at Tomboy.Tomboy.StartTrayIcon () [0x00000] in <1e78acb82a1946cb9286bdf291347fdd>:0
  at Tomboy.Tomboy.Main (System.String[] args) [0x00000] in <1e78acb82a1946cb9286bdf291347fdd>:0
 Source ID 2692 was not found when attempting to remove it

I should note that despite how the error would indicate that the proper note could not be found for deletion, upon reopening Tomboy, the note selected for deletion no longer exists.

Tomboy Version: 1.15.7
OS: Ubuntu 17.04 64-bit
Unity Version: 7.5.0
Compiz Version: 0.9.13.1

[alex-ter]

It's strange, but I can't reproduce this on Fedora 25. I've tried starting both from the shortcut and command line, deleted several dozen notes, both from the Search All window and note windows - works all the time. Also tried the tip of the master branch with the same result.

I'm installing a Ubuntu 17.04 VM now to check it there.

I see Fedora's version got updated to 1.15.8 by now - @caringi could you please give the new version a try and let me know how that works out? There were no changes between 1.15.7 and .8, which could fix this, but the fact that I can't reproduce at least makes it worth checking out.

[alex-ter]

Ubuntu still has 1.15.7, but I cannot reproduce this either. However looking further into the stack trace, in both cases it points to actually a "note window" way of deletion and that in turn points at fix for #13, however it's not immediately apparent to me how it could be causing this. I've tested it then and same as now I don't see any problems.

So maybe it's something additional - @caringi, @chrisbliss18, could you please start your Tomboy instances from console, with --debug switch and post (or send to me directly) log files generated, from the very start up until and including the crash?

Given the circumstances, the only way you should be seeing this would be deleting from the note window, with Search All window visible.

[chrisbliss18]

The detail about the Search All window is interesting, so I ran some tests related to the state of that window and found that its destruction (not creation or presence) certainly is related to this bug. If I run "tomboy --search", the Search All window will open when Tomboy starts. With the Search All window still open, deleting a note does not trigger the issue; however, after I close the Search All window, deleting a note does trigger the issue. Upon this realization, I ran a new test by running "tomboy", manually opening the Search All window, closing the Search All window, and then deleting a note. This resulted in the triggering the issue. So, the "tomboy --search" command creates this issue since it automatically opens the Search All window, which I then always immediately closed, resulting in the creation of the right environment to trigger this bug.

I created two debug log gists: running "tomboy --search --debug" and running "tomboy --debug". I annotated each log with details of my actions.

Note: I'm running Ubuntu 17.04 with Tomboy 1.15.7.

I have not reviewed the code, but upon running these tests and looking at issue #13, it would seem to me that the creation of the Search All window creates an action handler which refreshes the Search All window when a note is deleted from the note's window. Is it possible that this action handler is not removed when the Search All window is destroyed, thus causing a null reference unhandled exception when the handler attempts to refresh a non-existent window? This would explain the error message coming from GTK referencing an unhandled null reference exception:

Exception in Gtk# callback delegate
  Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object

[alex-ter]

Thanks, that's I think exactly what is happening here and as I always had the search window opened in my tests, that explains why I couldn't reproduce. I appreciate the information, it helps a lot.

[alex-ter]

All right, I've found the bug and fixed it, the patch is coming. The reason was that "note deleted" event handler was not properly disconnected when search window was closed, due to a typo. It's not related to #13, but was just exposed by a fix for it, as the note deletion event was now called more frequently.

Thanks again @chrisbliss18 for your help, you saved me noticeable debugging time :)

[alex-ter]

Oh, and one more thing - I've run out of time today, but I'll try to make a release on the weekend, so that you could enjoy the fix without self-building. Not sure how it works on Ubuntu, but Fedora seems to have an automated process, which picks the newest versions up (kudos to whoever set this up, or does this manually), so @caringi, you should have one automagically.

[davidbannon]

Sorry Alex, my sticky fingers there I'm afraid. Thought it was too easy at the time ! David

…

On 14/07/17 04:31, Alex Tereschenko wrote: All right, I've found the bug and fixed it, the patch is coming. The reason was that "note deleted" event handler was not properly disconnected when search window was closed, due to a typo. It's not related to #13 <#13>, but was just exposed by a fix for it, as the note deletion event was now called more frequently. Thanks again @chrisbliss18 <https://github.com/chrisbliss18> for your help, you saved me noticeable debugging time :) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF__MCnHHtEf2H82g8_JS_B5iJ9Shfk_ks5sNmKegaJpZM4NyWXy>.

[alex-ter]

No worries, David, that was outside of your change, so you wouldn't have really known (this typo, removing an incorrect handler, was there for a while). And the very specific requirement of opening the window, but then closing before the deletion, helped it evade exposure during your and my testing :)