[omniORB] omni_condition::~omni_condition

[glblock at rockwellcollins.com]

All

As far as I can figure this is what is happening...

The poaCurrentStackInsert  creates the omni_thread_dummy by calling
create_dummy(), at no time is a running_cond sema_ created for this object,
but the omni_thread, or omni_thread_dummy, constructor does not initialize
this value to NULL so it contains a random value.  When the poa calls
realease_dummy the omni_thread_dummy's last line will 'delete dummy' this
seems to end up in the omni_thread destructor which calls 'delete
running_cond'.  That is where it falls apart.

 If I initialize the running_cond in the dummy constructor to NULL and put
an if(running_cond) at the delete in the omni_thread destructor all is
well.

This may be the wrong approach but why both destructors are being called
and other platforms dont see this I still need to understand.
Either the dummy thread needs to create a running_cond, which is only done
in ::attach or ::start, or the above needs to done.


Gary




                                                                                                                                         
                      Alex Tingle                                                                                                        
                      <alex.tingle at broner        To:       glblock at rockwellcollins.com                                                   
                      metals.com>                cc:       omniorb-list at omniorb-support.com                                              
                                                 Subject:  Re: [omniORB] omni_condition::~omni_condition                                 
                      03/18/2004 12:32 PM                                                                                                
                                                                                                                                         
                                                                                                                                         





Any chance of seeing a stack dump?

-Alex

--
Dammit Jim, I'm a programmer... not a mind reader!
On 18 Mar 2004, at 18:19, glblock at rockwellcollins.com wrote:

>
>
>
>
> All
>
> OS = vxWorks
> BRD = powerpc
>
> the destructor for the omni_condition ( sema_ ) is being trashed and
> exceptions are being thrown on the destructor.
>
> This usually occurs when doing the following.
>
>    CosNaming::Name name;
>    // register with Naming Service
>    name.length(1);
>    name[0].id = CORBA::string_dup("MyName");
>    name[0].kind = CORBA::string_dup("");
>    try
>    {
>       rootContext->bind_new_context(name);
>    }
>    catch (...)
>    {
>             ok here....never gets here..
>     }
>
>
>    // register   with Naming Service
>    name.length(2);
>    name[1].id = CORBA::string_dup("MyManager");
>    name[1].kind = CORBA::string_dup("");
>    try
>    {
>       rootContext->rebind(name, theManager);
>    }
>    catch (...)
>    {
>       This succeeds to this point but the item that throws the error
> will
> be the omni_condition destructor ??
>   }
>
>  exception occurs here after the above.... the sema_  value seems to be
> trashed and the semDelete is where the exception bubbles up from.
>
>
> Thanks
>
> Gary
>
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list