Re: Sample code?

[Justin Schoeman <justin expertron co za>]

I have been doing some further testing, and have some interesting new 
results:

1) Tried 2.9.0
   - Does not build with debug enable - attached patch fixes this. 
(Needed for current CVS too).
   - Instant segfault on multi-threaded servers.  Client also segfaults 
when server segfaults.
   - Still leaks NameService initial reference.

2) Tried CVS
   - Could not get autogen to run - which versions of automake and 
autoconf are recommended?

3) Experimented with NameService initial reference - it leaks in the 
internal reference table => it is leaked even if the application does 
not resolve the initial reference.  Seems something is wrong with 
ORBit_RootObject_release()?

If anybody could give me some help/advice on getting these last minor 
glitches ironed out, I would really appreciate it!

Thanks,
-justin

Justin Schoeman wrote:
> Oops, I lied - it does not generate the assertion, because the name 
> service object is no longer being released!
> 
> Does anybody know why the name service is not being release?
> 
> Thanks,
> Justin
> 
> Justin Schoeman wrote:
> 
>> OK - my attempt at sample code is at:
>>
>> http://www.expertron.co.za/justin/echo-test.tbz (7kB)
>>
>> It was 'clean' until I changed to CORBA_ORB_resolve_initial_references 
>> to get the name service, now it leaks a name service reference... I 
>> don't know why, as I am definitely releasing it :-(
>>
>> If you want to see those asserts (and perhaps get a dump yourself, 
>> seeing as I can't get it right), try run echo_server a couple of times 
>> ;-)
>>
>> Thanks,
>> -justin
>>
>> Michael Meeks wrote:
>>
>>> Hi Justin,
>>>
>>> On Mon, 2003-10-27 at 17:10, Justin Schoeman wrote:
>>>
>>>> The abort is for the CORBA_Object_release of the name service 
>>>> object. Unfortunately, I have not yet figured out how to get the app 
>>>> to do a core dump for all the threads, so I do not know which thread 
>>>> is receiving the message...
>>>
>>>
>>>
>>>
>>>     Well; if it's a size problem: ulimit -c unlimited may help; mostly a
>>> core dump is for all threads; you simply have to do: thread apply all
>>> backtrace to get all traces; and thread <N> to switch thread for
>>> debugging.
>>>
>>>     It'd be great to get a trace,
>>>
>>>     Thanks,
>>>
>>>         Michael.
>>>
>>
>>
> 
> _______________________________________________
> orbit-list mailing list
> orbit-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/orbit-list
> 
--- src/orb/orb-core/orbit-object.c~	Tue Oct 28 17:07:18 2003
+++ src/orb/orb-core/orbit-object.c	Tue Oct 28 17:07:18 2003
@@ -67,11 +67,12 @@
 int
 ORBit_RootObject_shutdown (gboolean moan)
 {
+#ifdef G_ENABLE_DEBUG
+	int valid_running = 1; /* The ORB */
+#endif
 	if (!moan)
 		return 0;
 #ifdef G_ENABLE_DEBUG
-	int valid_running = 1; /* The ORB */
-
 	if (!ORBit_RootObject_lifecycle_lock &&
 	    alive_root_objects - valid_running)
 		g_warning ("ORB: a total of %ld refs to %ld ORB "