Bug 327058

Created attachment 173815 [details]
banshee and totem crash logs

Just found another gnome application not starting: tomboy. Messages are just about the same as for banshee...

Given the arch-specific nature of this and how widespread it seems to be among mono apps, I suspect this is a mono bug.

"totem" seems to be all right now, but that is not a mono application.

Banshee and tomboy still crash. Installed and tested now a couple more mono apps:

f-spot crashes

tangerine seems to work (at least starts up, even the graphical front end)

beagle is listed in ps aux (don't know how to test it, as I never used it...)

For the Mono-based apps, woudl someone please run the code from the command line and look at the errors?

It might not be a Mono issue, and a log would be useful.

Any chance for me to connect to a box with the packages installed + gdb?
A build env would be good, too (gcc, glib-dev, what's needed just for the basic mono tarball), since the distro packages likely have broken/missing debug info.

Ok, it looks like nobody from opensuse is willing to help with this.
Anyway, the issue is not a Mono bug, but a bug in those packages: they include a broken dbus-sharp-glib implementation that only happens to work on x86, but fails on powerpc/linux and other architectures that pass structures by pointer instead of by copying the data.
Taking the changes from http://git.ndesk.org/?p=dbus-sharp-glib
that fix this breackage should fix these apps on ppc.

There is also an additional and entirely similar issue in the gtk-sharp and gnome-sharp bindings. The main culprit seems to be functions that take a GLib.GType which is defined to be a struct containing a pointer, while the C code expects a pointer.

"grep -R GType . |grep extern" in the sources of the bindings will find most cases. There may be other such structures that are incorrectly used in p/invoke declarations.

The majority of GType parameters are okay, the generator has handled the marshaling as IntPtr correctly since 2004.  There were a few manually coded dllimports still hanging around in .customs that needed to be updated, but those only impacted overriding a few virtual methods on Gnome.CanvasItem,  Gtk.CellRenderer, and Gtk.Container.  

Fixed those stragglers in trunk r87604.

And when will this appear as an on-line update?

*** Bug 337080 has been marked as a duplicate of this bug. ***

Created attachment 182852 [details]
f-spot ppc test rpm 

This appears to be the relevant patch:
http://git.ndesk.org/?p=dbus-sharp-glib;a=commitdiff;h=ead66921dd6a0ce691ea2d126dbd53dbf9ebc5f5;hp=d8bd60e8b342d1004da5fcf49a2e916476dd7f61

Peter can you test the attach f-spot rpms for PPC?

Created attachment 182855 [details]
f-spot lang ppc test rpm

Can you give these a try peter?

Tested, but still fails :-(

Stacktrace:

  at (wrapper managed-to-native) System.Runtime.Remoting.Proxies.RealProxy.InternalGetTransparentProxy (string) <0xffffffff>
  at (wrapper managed-to-native) System.Runtime.Remoting.Proxies.RealProxy.InternalGetTransparentProxy (string) <0x00094>
  at System.Runtime.Remoting.Proxies.RealProxy.GetTransparentProxy () <0x001c8>
  at NDesk.DBus.Connection.GetObject (System.Type,string,NDesk.DBus.ObjectPath) <0x000b4>
  at NDesk.DBus.Connection.GetObject (string,NDesk.DBus.ObjectPath) <0x00044>
  at NDesk.DBus.Bus..ctor (string) <0x00058>
  at NDesk.DBus.Bus.Open (string) <0x000b0>
  at NDesk.DBus.Bus.get_System () <0x000b4>
  at NDesk.DBus.BusG.Init () <0x00030>
  at FSpot.Driver.Main (string[]) <0x00394>
  at (wrapper runtime-invoke) FSpot.Driver.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0x00070>

Native stacktrace:

	f-spot [0x1013d654]
	f-spot [0x10104680]
	[0x100350]
	f-spot [0x1004bec0]
	f-spot [0x1004c2cc]
	f-spot [0x10055184]
	[0x311ad640]
	[0x311ad4e4]
	[0x311a9dd8]
	[0x311a9a48]
	[0x3117ee24]
	[0x3117eab4]
	[0x3117e4d8]
	[0x3117ad64]
	[0x30bd17c0]
	[0x30bcf0e4]
	f-spot [0x10127604]
	f-spot(mono_runtime_invoke+0x28) [0x10047db8]
	f-spot(mono_runtime_exec_main+0xe4) [0x10050a64]
	f-spot(mono_runtime_run_main+0x194) [0x10050df4]
	f-spot(mono_jit_exec+0xa4) [0x10012a94]
	f-spot(mono_main+0x1080) [0x10013b50]
	f-spot [0x10012470]
	/lib/libc.so.6 [0xfc4637c]
	/lib/libc.so.6 [0xfc465a0]

Debug info from gdb:

[?1034h(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 0x3001fe50 (LWP 3842)]
[New Thread 0x30cf54a0 (LWP 3844)]
[New Thread 0x30bc54a0 (LWP 3843)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0x0fcfa014 in select () from /lib/libc.so.6
  3 Thread 0x30bc54a0 (LWP 3843)  0x0fe6a6c8 in nanosleep ()
   from /lib/libpthread.so.0
  2 Thread 0x30cf54a0 (LWP 3844)  0x0fe66074 in pthread_cond_wait@@GLIBC_2.3.2
    () from /lib/libpthread.so.0
  1 Thread 0x3001fe50 (LWP 3842)  0x0fcfa014 in select () from /lib/libc.so.6

Thread 3 (Thread 0x30bc54a0 (LWP 3843)):
#0  0x0fe6a6c8 in nanosleep () from /lib/libpthread.so.0
#1  0x100ccebc in ?? ()
#2  0x0fe60a64 in start_thread () from /lib/libpthread.so.0
#3  0x0fd01b58 in clone () from /lib/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 0x30cf54a0 (LWP 3844)):
#0  0x0fe66074 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#1  0x100d01c4 in ?? ()
#2  0x100d2db8 in ?? ()
#3  0x100d2e7c in ?? ()
#4  0x100e57c4 in ?? ()
#5  0x1006832c in ?? ()
#6  0x1008984c in ?? ()
#7  0x100e4310 in ?? ()
#8  0x101005d8 in ?? ()
#9  0x0fe60a64 in start_thread () from /lib/libpthread.so.0
#10 0x0fd01b58 in clone () from /lib/libc.so.6
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 0x3001fe50 (LWP 3842)):
#0  0x0fcfa014 in select () from /lib/libc.so.6
#1  0x0ff32928 in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
#2  0x0ff32d2c in g_spawn_command_line_sync () from /usr/lib/libglib-2.0.so.0
#3  0x1013d6fc in ?? ()
#4  0x10104680 in ?? ()
#5  <signal handler called>
#6  0x1004be78 in ?? ()
#7  0x1004bed4 in ?? ()
#8  0x1004c2cc in ?? ()
#9  0x10055184 in ?? ()
#10 0x311ad640 in ?? ()
#11 0x311ad4e4 in ?? ()
#12 0x311a9dd8 in ?? ()
#13 0x311a9a48 in ?? ()
#14 0x3117ee24 in ?? ()
#15 0x3117eab4 in ?? ()
#16 0x3117e4d8 in ?? ()
#17 0x3117ad64 in ?? ()
#18 0x30bd17c0 in ?? ()
#19 0x30bcf0e4 in ?? ()
#20 0x10127604 in ?? ()
#21 0x10047db8 in mono_runtime_invoke ()
#22 0x10050a64 in mono_runtime_exec_main ()
#23 0x10050df4 in mono_runtime_run_main ()
#24 0x10012a94 in mono_jit_exec ()
#25 0x10013b50 in mono_main ()
#26 0x10012470 in ?? ()
#27 0x0fc4637c in ?? () from /lib/libc.so.6
#28 0x0fc465a0 in __libc_start_main () from /lib/libc.so.6
#29 0x00000000 in ?? ()
#0  0x0fcfa014 in select () from /lib/libc.so.6


=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

*** Bug 338956 has been marked as a duplicate of this bug. ***

Banshee, f-spot and tomboy all depend on the external ndesk-dbus now, which is up to date for openSUSE 11.0.

Unfortunately I don't see making a PPC specific update here because of the effort and testing involved.