RE: graceful mulit-threaded shutdown

[Tyler Kohn <TKohn axeda com>]

Thanks Michael,

>	As Jan says it's best to use a memory debugger of some sort; I would
>recommend valgrind - google for it; you need to build ORBit2 with
>--enable-purify and run with --alignment=8 but it's an extremely
>powerful & useful tool.

Thanks for the recommendation, I'm now using it (or attempting to anyway).
I upgraded to 2.9 as well with the same result.  Let me know if I should
pull from HEAD and rebuild.  The BT from the core is the same (valgrind
exits on the abort and the core is generated, but gdb is not invoked (i do
have --gdb-attach=yes).  

>
>> In my "run" method, after g_main_loop_run (loop) returns I call:
>>     CORBA_Object_release(servant, ev);
>
>	Servants are normally user-instantiated objects, and not
CORBA_Objects
>- is the above correct ?

The servant is instantiated via (eventually) by:
	PortableServer_POA_servant_to_reference(poa, newservant, ev); 
in skelimpl.  Is it invalid to "release" the servant in this way?  I was
trying to follow the examples for shutting down.

>
>> I'm not calling the shutdown directly as the destroy should handle this
>
>	Sure.
>
>> I exit the run method and complete the shutting down of the rest of my
app,
>> it hangs for a second or two and then seg faults!
>
>	Of course, possibly this is indeed a bug :-) we're fixing a number
of
>interesting threading bugs in HEAD currenty.
>
>> Am I not properly cleaning the client references? I'm wading throught the
>> source, but would appreciate any insight.
>
>	A better trace using valgrind would prolly be helpful; checking the
>servant unref prolly too. A patch to allow shutdown from any thread [
>which should be feasible ] would be even nicer :-)

The seg fault could very well be a bug in my code, somewhat unrelated as
well.  But in any case I don't like to see the ** ERROR ** Must shut down
from main thread.  

I'm continuing to dig through and get familiar with valgrind.

Thanks,
Tyler