GNOME Bugzilla – Bug 378454
crash to ORBit_handle_request function
Last modified: 2007-06-30 11:53:46 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/evolution/+bug/67974 "I don't know how to reproduce this, but Evolution had crashed recently. ... http://librarian.launchpad.net/4932391/_usr_lib_evolution_2.8_evolution-alarm-notify.1000.crash complete report from crash utility (I thought I had debug pacakges, but don't see debug info here) D'oh! That was the wrong crash report -- here is the right one....
+ Trace 88754
..."
Without a way to reproduce this it's impossible to find the cause. Closing as incomplete. Please file a new bug if it happens again. Thanks for your report.
Reopening and changing the product to ORBit2, Ubuntu got a bunch of duplicates from that crash, often on gaim. The crashes apparently happen when halting the computer with the application running
very odd - of course we shouldn't crash. Kjartan, I'm concerned about this: g_assert(g_hash_table_remove(orb->forw_binds, objectId)); is it possible that assertions (or something) are being turned off in Ubuntu ? - if so, that might not get executed & cause problems later. Can we split that into 2 lines: gboolean removed = g_hash ... g_assert (removed); otherwise I can't see how this could crash (cf. forw_bind)...
The build is a normal one with no assertion change, backtrace from a debug build:
+ Trace 103785
Do you need any other information? The Ubuntu bug has over 30 duplicates which means it happen pretty often, bugzilla probably has not that many bugs about because bug-buddy doesn't dump somewhere crashes happening on logout for example
Seems that some other thread has shutdown that CORBA_ORB (via CORBA_ORB_destroy), and has started free'ing its memory. In the coredumps, you can see that the lock has been dropped, and the life flags shows it as dead: (gdb) up
+ Trace 109208
$1 = (CORBA_ORB) 0x8086298 (gdb) print orb->lock $2 = (GMutex *) 0x0 (gdb) print orb->life_flags $3 = 1024 ./include/orbit/poa/poa-types.h:#define ORBit_LifeF_Destroyed (1<<10) Since LINK_MUTEX_LOCK only locks if !NULL, ORBit_forw_bind_find (via ORBit_handle_request), attempts to access the hash anyway. I can't actually reproduce this crash, but perhaps adding: orb->forw_binds = NULL; after the "g_hash_table_destroy (orb->forw_binds);" in CORBA_ORB_destroy may help spark some more asserts, since this code would get hit: tprintf ("Error: failed to find adaptor or objkey for " "object while invoking method '%s'", giop_recv_buffer_get_opname (recv_buffer));
Created attachment 82203 [details] [review] suggested debugging aid
Kees - interesting; if we shut-down the ORB I guess we should -really- wait until the incoming I/O thread has also shut-down. ORB shutdown is one of those problematic things that we never quite finished :-) OTOH - I'm well up for your patch to help debugging, particularly if it turns a crash into a warning; can you commit ?
Michael, I don't have an svn account yet, but Seb said he'd do the commit for me. I wasn't sure where the thread management was being done, so I didn't debug it any further. Is it a simple case to flush IO and shut down those threads before shutting down ORB? That's the "real" bug here. :)
debug patch commited: 2007-02-09 Sebastien Bacher <seb128@ubuntu.com> * src/orb/orb-core/corba-orb.c: (CORBA_ORB_destroy): - explicitly set variable for better debugging, patch by Kees Cook
Should we still split up the assert above?
sure, why not - can't do any harm - can you handle Kjartan ? :-) [ thanks ].
Created attachment 82450 [details] [review] split the asserts Does this look like it does what you intended? g_hash_table_lookup returns a gpointer so I used that instead.
Marking the other as commited.
looks lovely to me - thanks Kjartan :-)
Has anyone seen the original problem since this was done?
The Ubuntu bug has not recent duplicate
Time to close this bug, then?
closing, I'll reopen if there is a new duplicate