mono always crashes on ppc

[Matteo Settenvini]

Binary package hint: mono

It's since I upgraded to gutsy that mono crashes whatever application I try to run with it. This means it crashes at least with F-Spot, Tomboy and Hipo.

For example, this is the output given trying to run tomboy from console:

matteo@Dahlia:~$ tomboy

** (Tomboy:13979): WARNING **: Exception inside function without unwind info

** ERROR **: file exceptions-ppc.c: line 847 (arch_handle_exception): should not be reached
aborting...
Trace/breakpoint trap (core dumped)
matteo@Dahlia:~$ tomboy

** (Tomboy:14081): WARNING **: Exception inside function without unwind info

** ERROR **: file exceptions-ppc.c: line 847 (arch_handle_exception): should not be reached
aborting...
Trace/breakpoint trap (core dumped)

ProblemType: Crash
Architecture: powerpc
CrashCounter: 1
Date: Wed Jun 27 09:26:10 2007
Dependencies:
 libgcc1 1:4.2-20070626-0ubuntu1
 libglib2.0-0 2.13.5-0ubuntu3
 gcc-4.2-base 4.2-20070626-0ubuntu1
 mono-common 1.2.4-3ubuntu2
 libc6 2.5-11ubuntu1
DistroRelease: Ubuntu 7.10
ExecutablePath: /usr/bin/mono
Package: mono-jit 1.2.4-3ubuntu2
PackageArchitecture: powerpc
ProcCmdline:

ProcCwd: /home/matteo
ProcEnviron:

Signal: 5
SourcePackage: mono
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
Title: mono crashed with signal 5
Uname: Linux Dahlia 2.6.20-15-powerpc64-smp #3 SMP Sun Apr 15 06:52:37 UTC 2007 ppc64 GNU/Linux
UserGroups: adm admin audio cdrom dialout dip floppy lpadmin plugdev pulse pulse-access pulse-rt scanner users video

[Matteo Settenvini (tchernobog)]

Could please someone tell me how to help with this bug? It's quite annoying; expecially since I cannot use F-Spot.

It outputs:

matteo@Dahlia:~$ f-spot
Stacktrace:

  at (wrapper managed-to-native) NDesk.GLib.IO.g_io_add_watch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc,intptr) <0xffffffff>
  at (wrapper managed-to-native) NDesk.GLib.IO.g_io_add_watch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc,intptr) <0x000a4>
  at NDesk.GLib.IO.AddWatch (NDesk.GLib.IOChannel,NDesk.GLib.IOCondition,NDesk.GLib.IOFunc) <0x00064>
  at NDesk.DBus.BusG.Init (NDesk.DBus.Connection,NDesk.GLib.IOFunc) <0x00080>
  at NDesk.DBus.BusG.Init (NDesk.DBus.Connection) <0x000cc>
  at NDesk.DBus.BusG.Init () <0x00044>
  at FSpot.Driver.Main (string[]) <0x00394>
  at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0x00080>

Native stacktrace:

        f-spot [0x10166c64]
        f-spot [0x101404a0]
        [0x100350]
        [(nil)]
        /usr/lib/libglib-2.0.so.0(g_io_add_watch_full+0x5c) [0xfeed20c]
        [0xf6de99dc]
        [0xf6de9858]
        [0xf6de953c]
        [0xf6de93c8]
        [0xf6e6db40]
        [0xf74947a8]
        [0xf74920dc]
        f-spot [0x101402c8]
        f-spot(mono_runtime_invoke+0x1c) [0x10056478]
        f-spot(mono_runtime_exec_main+0x14c) [0x1005ba4c]
        f-spot(mono_runtime_run_main+0x2a4) [0x1005bd40]
        f-spot(mono_jit_exec+0xe0) [0x100134fc]
        f-spot [0x10013638]
        f-spot(mono_main+0x1714) [0x10014fe0]
        f-spot [0x100120e4]
        /lib/libc.so.6 [0xfc32fc0]
        /lib/libc.so.6 [0xfc33210]

Debug info from gdb:

(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -134455296 (LWP 9767)]
[New Thread -146373456 (LWP 9772)]
[New Thread -146160464 (LWP 9771)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0x0fcee318 in select () from /lib/libc.so.6
  3 Thread -146160464 (LWP 9771) 0x0fe6cce0 in ?? () from /lib/libpthread.so.0
  2 Thread -146373456 (LWP 9772) 0x0fe682b4 in pthread_cond_wait@@GLIBC_2.3.2
    () from /lib/libpthread.so.0
  1 Thread -134455296 (LWP 9767) 0x0fcee318 in select () from /lib/libc.so.6

Thread 3 (Thread -146160464 (LWP 9771)):
#0 0x0fe6cce0 in ?? () from /lib/libpthread.so.0
#1 0x0fe6cccc in ?? () from /lib/libpthread.so.0
#2 0x100cb5d8 in ?? ()
#3 0x0fe62944 in start_thread () from /lib/libpthread.so.0
#4 0x0fcf6584 in clone () from /lib/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread -146373456 (LWP 9772)):
#0 0x0fe682b4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1 0x100d1d14 in ?? ()
#2 0x100d214c in ?? ()
#3 0x100d1eec in ?? ()
#4 0x100e9768 ...

[Alessandro Decina (alessandro.decina)]

I can confirm this bug on gutsy. It is reported upstream and to debian.
Upstream fixed it in svn see http://bugs.ximian.com/show_bug.cgi?id=81852. The debian mantainer has a patch and is waiting for some testing (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428190).

[Alessandro Decina (alessandro.decina)]

With the patch attached on the debian bug I no longer get the assertion error. The NDesk exception is still there though (but it seems to be unrelated).

[Alessandro Decina (alessandro.decina)]

The ndesk segfault is due to an inconsistency in how structs are passed in pinvoke. On ppc structs are always passed by-address. This is how GIOChannel is wrapped in ndesk-glib:

 struct IOChannel
 {
  const string GLIB = "libglib-2.0-0.dll";

  public IntPtr Handle;

  [DllImport(GLIB)]
   static extern IntPtr g_io_channel_unix_new (int fd);
  public IOChannel (int fd)
  {
   Handle = g_io_channel_unix_new (fd);
  }
[snip]

Then g_io_add_watch is defined as a pinvoke method:

[snip]
   [DllImport(GLIB)]
   protected static extern uint g_io_add_watch (IOChannel channel, IOCondition condition, IOFunc func, IntPtr user_data);
[snip]

The g_io_add_watch wrapper takes a IOChannel structure as its first argument. The real g_io_add_watch takes a GIOChannel * argument as first argument.
On x86 this works because IOChannel is passed by value, so the GIOChannel * pointer in the real g_io_add_watch gets the value of IOChannel::Handle which points to the right location.
On ppc IOChannel is passed by address, so the GIOChannel * pointer in the real g_io_add_watch gets *a pointer* to IOChannel::Handle.

setting PPC_PASS_STRUCTS_BY_VALUE to 1 in mono/mini/mini-ppc.h and recompiling fixes the bug here. Anyway i don't know why it is set to 0 by default and if changing it has any drawbacks.

[Sebastian Dröge (slomo)]

The fix was uploaded to gutsy some hours ago.

[Alessandro Decina (alessandro.decina)]

f-spot and tomboy (and all the apps that use dbus in general) still crash, see comment #5.
The patch added in 1.2.4-3ubuntu3 fixes only the first part, the arch_handle_exception assertion.

[Alessandro Decina (alessandro.decina)]

Reopening as it's not completely fixed yet.

[Sebastian Dröge (slomo)]

Can you please file a bug on ndesk-dbus for this?
The relevant Debian bug for this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431168

Would be nice if you could add everything you found out so far there...

[Alessandro Decina (alessandro.decina)]

I could but this is actually a bug in mono-jit. Of course it can be worked around in ndesk-glib, but it would need fixing in all the mono apps/libs that pass structs by value in p/invoke...
Anyway, i'm going to open a bug on ndesk-glib and will attach a workaround there.

[Apport retracing service (apport)]

StacktraceTop:?? () from /usr/bin/mono
?? () from /usr/bin/mono
?? () from /usr/bin/mono
?? () from /usr/bin/mono
<signal handler called>

[Alessandro Decina (alessandro.decina)]

https://bugs.launchpad.net/ubuntu/+source/ndesk-dbus-glib/+bug/127424 is the bug against ndesk-dbus-glib

[Matteo Settenvini (tchernobog)]

Can be closed as fixed, I think... cannot reproduce anymore here.

[Alessandro Decina (alessandro.decina)]

I did a quick test and I can reproduce it with banshee:

alessandro@homeless:~/src$ banshee
Debug: [3/26/2008 10:30:46 PM] (Loading audio profiles) - /usr/share/banshee/audio-profiles
Debug: [3/26/2008 10:30:49 PM] (Default player engine) - GStreamer 0.10
Debug: [3/26/2008 10:30:49 PM] (Audio CD Core Initialized) -

(Banshee:12399): GLib-GObject-WARNING **: cannot retrieve class for invalid (unclassed) type `(null)'
Stacktrace:

  at (wrapper managed-to-native) Gtk.CellRenderer.gtksharp_cellrenderer_override_get_size (GLib.GType,Gtk.CellRenderer/GetSizeDelegate) <0xffffffff>
  at (wrapper managed-to-native) Gtk.CellRenderer.gtksharp_cellrenderer_override_get_size (GLib.GType,Gtk.CellRenderer/GetSizeDelegate) <0x0009c>
  at Gtk.CellRenderer.OverrideGetSize (GLib.GType) <0x000bc>
  at (wrapper runtime-invoke) Gtk.Widget.runtime_invoke_void_GType (object,intptr,intptr,intptr) <0x00080>
  at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[]) <0xffffffff>
  at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke (object,object[]) <0x00098>
  at System.Reflection.MonoMethod.Invoke (object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo) <0x0012c>
  at System.Reflection.MethodBase.Invoke (object,object[]) <0x00040>
  at GLib.Object.ConnectDefaultHandlers (GLib.GType,System.Type) <0x00254>
  at GLib.Object.RegisterGType (System.Type) <0x00150>
  at GLib.Object.LookupGType (System.Type) <0x00168>
  at GLib.Object.LookupGType () <0x00034>
  at GLib.Object.CreateNativeObject (string[],GLib.Value[]) <0x00114>
  at Gtk.Object.CreateNativeObject (string[],GLib.Value[]) <0x00030>
  at Gtk.CellRendererText..ctor () <0x000ac>
  at Banshee.Gui.SourceRowRenderer..ctor () <0x00020>
  at Banshee.Gui.SourceView..ctor () <0x001bc>
  at Banshee.PlayerUI.BuildWindow () <0x01da4>
  at Banshee.PlayerUI..ctor () <0x0015c>
  at <>c__CompilerGenerated0.<Startup>c__17 () <0x0004c>
  at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void () <0x00068>
  at Banshee.Base.ComponentInitializer.Run () <0x00170>
  at Banshee.Base.Globals.Initialize (Banshee.Base.ComponentInitializerHandler) <0x00f68>
  at Banshee.BansheeEntry.Startup (string[]) <0x00d58>
  at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void_string[] (string[]) <0x0008c>
  at Banshee.Gui.CleanRoomStartup.Startup (Banshee.Gui.CleanRoomStartup/StartupInvocationHandler,string[]) <0x00128>
  at Banshee.BansheeEntry.Main (string[]) <0x00088>
  at (wrapper runtime-invoke) Banshee.BansheeEntry.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0x00070>

Native stacktrace:

 banshee [0x101affec]
 banshee [0x1018ab80]
 [0x100350]
 /usr/lib/mono/gtk-sharp-2.0/libgtksharpglue-2.so(gtksharp_cellrenderer_override_get_size+0x54) [0xdaf7404]
 [0x4bbbd308]
 [0x4bbbd1c8]
 [0x490bf414]
 banshee [0x1018a9a8]
 banshee(mono_runtime_invoke+0x44) [0x100602e4]
 banshee(mono_runtime_invoke_array+0x77c) [0x10062d20]
 banshee [0x1007034c]
 [0x49069900]
 [0x49069140]
 [0x49068a6c]
 [0x490bee28]
 [0x490bde7c]
 [0x490bdcdc]
 [0x490bdb50]
 [0x490bd958]
 [0x490bd824]
 [0x4bbbce90]
 [0x4bbbcdb4]
 [0x4bbba43...

[Jo Shields (directhex)]

The original poster's bug is fixed, as of a fair while ago (1.2.4-5). Alessandro Decina's problem is a different one - can you please try with a recent Mono (preferably on Intrepid) to see if it still happens, and report a new bug if it does? Keeping multiple unrelated bugs inside the same bug report makes it very hard to keep track of what's solved and what isn't