RE: graceful mulit-threaded shutdown

[Tyler Kohn <TKohn axeda com>]

Ok, I think I figured this out.  I needed to release my orb reference from
my client explicitly.  Does it matter if it is before or after the destroy.
in the test classes it's done after, which is conceptually a little odd to
me since it already "destroyed".  anyway, it looks like the problem was also
a bug of mine (some pointer issues in a global variable I had been using to
reference the orb - stupid, stupid, stupid).   Thanks for all the help!!!!!

One more question, did the signal handling change in 2.9.1?  I am setting:
	signal(SIGINT,  server_shutdown);
	signal(SIGTERM, server_shutdown);
In previous builds (haven't tested this yet - just a quick observation) when
I broke the process (ctrl-c: sigint) this shutdown would get called and the
app would shutdown, clumsily and I'd see the "must shutdown from main
thread" error.  fine, not the appropriate way to shut it down, but it would
force things.  Now, ctrl-c doesn't shut down the app, it seems to get
caught, but keep processing.  When I then try and shut it down correctly I
get a seg fault and the following trace from the core (although it looks a
little useless to me):

#0  0x4145614e in impl_c2dMessage__destroy (servant=0x0, ev=0x41464e6c)
    at Components/app/app-skelimpl.c:101
101        objid = PortableServer_POA_servant_to_id(servant->poa, servant,
ev);
(gdb) bt
#0  0x4145614e in impl_c2dMessage__destroy (servant=0x0, ev=0x41464e6c)
    at Components/app/app-skelimpl.c:101
#1  0x41456611 in CorbaServer_Run () at
Components/Maquet/maquet-server.c:144
#2  0x4144b7fd in MaquetMgr::InitCorbaServerThread (this=0x80ce518)
    at Components/app/appMgr.cpp:1130
#3  0x41454baa in MaquetMgr::InitCorbaServerThreadStub (pThis=0x80ce518)
    at Components/app/appMgr.h:128
#4  0x4012e0b9 in EThread::ThreadStub (pParam=0x80ce578)
    at Base/EOS_linux.cpp:358
#5  0x402ab881 in pthread_start_thread () from /lib/i686/libpthread.so.0
Current language:  auto; currently c

Did some of the shut down changes modify how signals are handled?

-Tyler

-----Original Message-----
From: Tyler Kohn 
Sent: Monday, November 17, 2003 10:44 AM
To: 'Michael Meeks'
Cc: 'Jan Kratochvil'; 'orbit-list@gnome.org'
Subject: RE: graceful mulit-threaded shutdown



Michael,

>	Interesting. Can you confirm that you are using a recent ORBit2 eg.
the
>just released ORBit2-2.9.1 which has a _load_ of shutdown related
>problems fixed (mostly by Justin Schoeman) - that's the best place to
>start for debugging these problems.
>

I just grabbed 2.9.1 and recompiled (I was using 2.9.0).

I've been compiling with --enable-debug=yes and exported ORBIT2_DEBUG=refs
but I'm not seeing anything tell me what type of object is leaked (it would
help!)  

>	Ok - if you compile ORBit2 with --enable-debug (perhaps you did this
>already), then export ORBIT2_DEBUG=refs, then re-run - it should show
>you the type of object that is leaked - which may help.
>
>
>	Right; so you need to binary chop the reference leak out. Ultimately
>you're missing a CORBA_Object_release (foo, NULL); somewhere.
>	Heh :-)
>
>	Are you just missing a:
>
>		CORBA_Object_unref (orb, ev);
>
>	If you dig at ORBit2/test/everything/client.c you can see what that
>does for shutdown.
>

Is CORBA_Object_unref a wishfull thinking method (can't find it)?  or just
the gist of what should I should be doing?  If I try to release the ORB
duing the client shutdown I get the assertion failure in do_unref.

I'll take a look at the test code, that will probably help.

-Tyler
_______________________________________________
orbit-list mailing list
orbit-list@gnome.org
http://mail.gnome.org/mailman/listinfo/orbit-list