Bug 2248 - NREX when switching tabs after unsplitting the editor buffer
Summary: NREX when switching tabs after unsplitting the editor buffer
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: Trunk
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2011-11-29 08:40 UTC by Marek Habersack
Modified: 2012-01-24 03:58 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Marek Habersack 2011-11-29 08:40:36 UTC
After splitting the text editor buffer horizontally, unsplitting it and trying
to switch the tabs, the following NREX is thrown:

System.NullReferenceException: Object reference not set to an instance of an object
  at MonoDevelop.Ide.Navigation.NavigationHistoryService.DetachFromCurrentDoc () [0x00030] in /Users/grendel/build/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Navigation/NavigationHistoryService.cs:273
  at MonoDevelop.Ide.Navigation.NavigationHistoryService.AttachToDoc (MonoDevelop.Ide.Gui.Document document) [0x00000] in /Users/grendel/build/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Navigation/NavigationHistoryService.cs:247
  at MonoDevelop.Ide.Navigation.NavigationHistoryService.ActiveDocChanged (System.Object sender, System.EventArgs args) [0x00006] in /Users/grendel/build/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Navigation/NavigationHistoryService.cs:242
  at (wrapper delegate-invoke) <Module>:invoke_void__this___object_EventArgs (object,System.EventArgs)
  at (wrapper delegate-invoke) <Module>:invoke_void__this___object_EventArgs (object,System.EventArgs)
  at (wrapper delegate-invoke) <Module>:invoke_void__this___object_EventArgs (object,System.EventArgs)
  at MonoDevelop.Ide.Gui.Workbench.OnDocumentChanged (System.Object s, System.EventArgs a) [0x0000b] in /Users/grendel/build/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/Workbench.cs:559
  at MonoDevelop.Ide.Gui.DefaultWorkbench.OnActiveWindowChanged (System.Object sender, System.EventArgs e) [0x00075] in /Users/grendel/build/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Gui/DefaultWorkbench.cs:735
  at Gtk.Notebook.SwitchPageSignalCallback (IntPtr arg0, IntPtr arg1, UInt32 arg2, IntPtr gch) [0x00000] in <filename unknown>:0
Comment 1 Jeffrey Stedfast 2012-01-09 16:39:20 UTC
I'm not able to reproduce this... BUT what I suspect may have happened is this:

- NavigationHistoryService.cs:DetachFromCurrentDoc() is trying to disconnect some event handlers from currentDoc.Editor.Document (and Caret), and assumes that if Editor is non-null, then Document and Caret must also be non-null.

This seems to be a reasonable assumption, EXCEPT when the currentDocument.Editor has been Dispose()'d (see TextEditorData.cs's Dispose() method).

If you look at Document.Editor implementation, it caches the TextEditorData lookup and there doesn't apear to be any easy way to listen for it being disposed.

TextEditor.OnDestroyed() will call Dispose() on the TextEditorData when its tab/window/whatever gets closed.


A simple fix might just be to make Document.cs not cache the TextEditorData value that it looked up in the Editor property.


I'm going to defer to Mike Krueger for this bug.
Comment 2 Mike Krüger 2012-01-10 02:53:30 UTC
That should've been fixed in december. The "split" text editor is now always internal to the source editor & shouldn't be exposed or used as the new "main" text editor anymore.

(That was the bug that the text editor sometimes used the splitted control as new main editor)

@Marek: Which branch/version did you use ? And are you able to repro that ? If so, we need more details.
Comment 3 Marek Habersack 2012-01-10 03:02:51 UTC
It was with master and I cannot repro it there anymore (haven't tried with the newresolver branch, though).
Comment 4 Mike Krüger 2012-01-24 03:58:39 UTC
Ok marking it as closed since I'm 90% sure that I fixed it in december and the bug got opened before that.