GNOME Bugzilla – Bug 112725
bonobo-activation locks up entering main_loop
Last modified: 2004-12-22 21:47:04 UTC
Bonobo-activation-server 2.3.1 (now part of the libbonobo package) locks up and zombies on FreeBSD -CURRENT just after entering the g_main_loop. This did not happen with bonobo-activation-server 2.2.1.1 on the same OS. It also does not occur on FreeBSD -STABLE. When running the test.sh for the activation server, this is what I see: ** (process:91574): WARNING **: Update registry 0x0 ** (process:91574): WARNING **: Compare old_mtime on '/usr/local/libdata/bonobo/servers' with 0 ==? 1052594367 ** (process:91574): WARNING **: Compare old_mtime on '/usr/X11R6/libdata/bonobo/servers' with 0 ==? 1052594565 ** (process:91574): WARNING **: Compare old_mtime on '.' with 0 ==? 1052594826 ** (process:91574): WARNING **: Re-load 1 0 ** (process:91574): WARNING **: Property 'name' has no value ** (process:91574): WARNING **: Property 'description' has no value ** (process:91574): WARNING **: Property 'name' has no value ** (process:91574): WARNING **: Property 'description' has no value ** (process:91574): WARNING **: Property 'nautilus:view_as_name' has no value iid OAFIID:BrokenNoType:20000808 has a NULL type invalid character '#' in iid 'OAFIID:This#!!%$iid%^$%_|~!OAFIID_ContainsBadChars' ** (process:91574): WARNING **: Server register. 'OAFIID:Bonobo_CosNaming_NamingContext' : 0x80aa280 -- TEST HANGS HERE INDEFINITELY-- Then, ps reports: root 0 0.0 0.0 0 0 p3 ZW+ - 0:00.00 (lt-bonobo-activatio) <-- Zombie at _exit(0) marcus 72640 0.0 0.4 5456 3984 ?? Is 3:24PM 0:00.11 /usr/local/libexec/bonobo-activation-server --ac-activate --ior-output-fd=24 root 91557 0.0 0.2 3784 2508 p3 I+ 3:27PM 0:00.02 lt-bonobo-activation-test root 91574 0.0 0.4 5464 3920 ?? Is 3:27PM 0:00.12 lt-bonobo-activation-server --ac-activate --ior-output-fd=7 I'm at a loss as to why this is happening. I've been troubleshooting extensively, and traced everything down to g_main_loop_run (main_loop); at line 306 in activation-server-main.c. Everything works up to that point. Note, if I replace the activation-server directory with the one from bonobo-activation-2.2.1.1, 8 of the 16 tests pass, and the lockup does not occur. Attached is a truss of the failing test showing all syscalls and children. I appreciate any guidance you can offer. Thanks.
The reason this is a blocker is that it's holding up the GNOME 2.3.1 roll-out on FreeBSD.
Created attachment 16414 [details] Truss output of the failing activation test
I should also say, the test is not the olnly thing that's failing. It was just easier to demonstrate the failure using the test. Applications such as Nautilus, Evo-1.3, gnome-panel, etc. cause the same behavior in bonobo-activation.
It's possible (but unlikely) that this is a deadlock in the new ORBit2 threading stuff - do you have a stack-trace of both sides ? b-a-s and the client ?
Thanks for replying. I have tried to get a good stack trace, but every time, I found it to be lacking. I'll give it another try ASAP. Note, I have been using the new ORBit2 for a while with the _old_ b-a-s and and libbonobo, and I didn't see this problem. However, now that you mention it, it may explain why Nautilus 2.3.1 doesn't work either. It either crashes or zombies when starting up. Right now, I'm in the middle of trying to isolate whether the problem is in gnomevfs2 or nautilus itself....
Okay, this is from the test. I even backed down to ORBit2 2.6.1 (I had to hack libbonobo a bit), and the problem persists: Backtrace from lt-bonobo-activation-test: [Switching to Process 82949, Thread 1] 0x282bb833 in poll () from /usr/lib/libc.so.5 (gdb) bt
+ Trace 36755
* 1 Process 97423, Thread 1 0x28425833 in poll () from /usr/lib/libc.so.5
Looks like this was a false alarm. I sincerely apologize. The newer libtool has a check that prevents -lc_r from being passed to the linker on all versions of FreeBSD. For -STABLE, this is good. For -CURRENT, this is very bad. In any event, I've patched the local ltmain.sh, and the problem has been solved. Thanks for your help, and sorry again for the inconvenience.
Hey - that's no problem - I'm just really glad it's not some evil bug of my own creation :-)