Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#24265 - [monodevelop] Unhandled exception if closing Window with Frame container

Attached to Project: Arch Linux
Opened by Andreas Neiser (aneiser) - Friday, 13 May 2011, 21:10 GMT
Last edited by Isenmann Daniel (ise) - Thursday, 06 October 2011, 06:31 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Isenmann Daniel (ise)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
I'm using the current ArchLinux distribution and monodevelop-git (checkout from
May 13 aka today, is labeled Beta2) and since the update to Gnome3, I get a
rather unspecific unhandled exception if doing the following:
1) Create a new GTK project.
2) Drag a frame container to the automatically created MainWindow-
3) Close the Gui Editor.
Then the exception shows up:

ERROR [2011-05-13 22:48:47Z]: Unhandled Exception
System.NullReferenceException: Object reference not set to an instance of an
object
at GLib.Object.NotifyCallback (IntPtr handle, IntPtr pspec, IntPtr gch)
[0x00000] in <filename unknown>:0

Furthermore, compiling the project brings the exception up again. Clicking ok
seems to run the program without problems.

Can anyone tell me how to debug this further? Seems to be related to the Gtk
bindings and Gtk3. Maybe at least someone can reproduce this bug or tell me
that he successfully uses Gnome3 with current monodevelop. BTW, the stable
release 2.4 shows the same behavior.

Reported it upstream already here: https://bugzilla.novell.com/show_bug.cgi?id=693802
and Forum thread here: https://bbs.archlinux.org/viewtopic.php?id=117933
This task depends upon

Closed by  Isenmann Daniel (ise)
Thursday, 06 October 2011, 06:31 GMT
Reason for closing:  Fixed
Additional comments about closing:  Package monodevelop-2.8-1 released to [extra].
Comment by Isenmann Daniel (ise) - Thursday, 19 May 2011, 05:25 GMT
The monodevelop 2.4 shows the same behaviour because I have add an patch (http://projects.archlinux.org/svntogit/packages.git/tree/monodevelop/trunk/monodevelop_gnome3.patch) that it run at all. Without the patch, monodevelop wouldn't even start. The patch was from the GIT repo of monodevelop, I have asked the monodevelop devs before and checked the patch. They told me the same as they told you that it is a library issue.
Comment by Andreas Neiser (aneiser) - Thursday, 19 May 2011, 07:11 GMT
Hm, but it seems to me that nobody knows exactly which library is concerned?! If I knew that I wouldn't hesitate to file a bug report there... Do you have any idea where the problem really comes from?
Comment by Andreas Neiser (aneiser) - Thursday, 19 May 2011, 21:00 GMT
Hm I reported something here: https://bugzilla.novell.com/show_bug.cgi?id=694988
Let's see if someone has a clue.
Comment by Andreas Neiser (aneiser) - Monday, 23 May 2011, 20:05 GMT
And I found another hint that it has something to do with glib2: https://bugzilla.redhat.com/show_bug.cgi?id=679373 Should we contact Jan de Groot?
Comment by Andreas Neiser (aneiser) - Friday, 03 June 2011, 18:07 GMT
Is there anything going on? The still is even reproducible in the most recent Fedora Xfce Live CD...very annoying! Just install monodevelop, make a new Gtk# project, drag a frame container on the MainWindow in the GUI editor and close it. You get a nice unspecific null pointer exception.

I found a really ugly, ugly temporary WORKAROUND for the problem: Downgrade the following packages (this list is neither minimal nor exhaustive):
[2011-06-04 13:34] Running 'pacman-color -R lib32-glib2'
[2011-06-04 13:34] Running 'pacman-color -R nspluginwrapper-debian'
[2011-06-04 13:34] removed nspluginwrapper-debian (1.3.0-1)
[2011-06-04 13:34] Running 'pacman-color -R lib32-libxmu'
[2011-06-04 13:34] removed lib32-libxmu (1.1.0-1)
[2011-06-04 13:34] Running 'pacman-color -R lib32-gdk-pixbuf2'
[2011-06-04 13:35] Running 'pacman-color -R lib32-gtk2'
[2011-06-04 13:36] Running 'pacman-color -U lib32-glib2-2.26.1-2-x86_64.pkg.tar.xz'
[2011-06-04 13:36] upgraded lib32-glib2 (2.28.6-1 -> 2.26.1-2)
[2011-06-04 13:36] Running 'pacman-color -U glib2-2.26.1-1-x86_64.pkg.tar.xz'
[2011-06-04 13:37] Running 'pacman-color -U gdk-pixbuf2-2.22.1-2-x86_64.pkg.tar.xz'
[2011-06-04 13:37] upgraded gdk-pixbuf2 (2.23.3-1 -> 2.22.1-2)
[2011-06-04 13:38] Running 'pacman-color -U glib2-2.26.1-1-x86_64.pkg.tar.xz'
[2011-06-04 13:38] upgraded glib2 (2.28.7-1 -> 2.26.1-1)
[2011-06-04 13:41] Running 'pacman-color -U lib32-glib2-2.26.1-1-x86_64.pkg.tar.xz'
[2011-06-04 13:43] Running 'pacman-color -U lib32-gdk-pixbuf2-2.22.1-1-x86_64.pkg.tar.xz'
[2011-06-04 13:44] upgraded lib32-gdk-pixbuf2 (2.23.3-1 -> 2.22.1-1)
[2011-06-04 13:49] Running 'pacman-color -U dconf-0.5.1-1-x86_64.pkg.tar.xz'
[2011-06-04 13:49] upgraded dconf (0.7.5-1 -> 0.5.1-1)

dconf downgrade was necessary otherwise firefox failed with some rather obscure message. Hope that doesn't introduce any other problems, and you'll likely need to use XFCE instead of Gnome, otherwise the downgrades aren't possible, I guess.
Comment by Andreas Neiser (aneiser) - Wednesday, 15 June 2011, 17:57 GMT
Well, just forget my workaround. It introduces more problems than it solves, although it might help some people who need a working monodevelop IDE.
Comment by Andreas Neiser (aneiser) - Thursday, 28 July 2011, 17:31 GMT
In monodevelop-git it seems to be fixed by the following workaround:
https://github.com/mono/monodevelop/commit/05169ac73899cfe58ca6252e7614dc20ab8a314c
Comment by Andreas Neiser (aneiser) - Monday, 26 September 2011, 09:13 GMT
  • Field changed: Percent Complete (100% → 0%)
This is not true. I tested it with monodevelop 2.6 in my case, and it is still a problem. monodevelop-git does not show this issue.
Comment by Eric Belanger (Snowman) - Monday, 26 September 2011, 09:14 GMT
Looks like that commit didn't make it in 2.6. It isn't in 2.6.0.1 either.

Loading...