[omniORB] Omni 4.0.6 and Purify

[Regis DETRE]

We successfully run Purify with omniORB on lot of applications, but one, 
which linked with ILOG Views 3.0.2 and Purify, always crashes.

We are using posix.cc and we have the same trouble. The same correction 
permits us to run Purify.

The comment in omnithread.h saids :

#ifndef __rtems__
static omni_thread::init_t omni_thread_init;
#else
// RTEMS calls global Ctor/Dtor in a context that is not
// a posix thread. Calls to functions to pthread_self() in
// that context returns NULL. 
// So, for RTEMS we will make the thread initialization at the
// beginning of the Init task that has a posix context.
#endif

The explanation for RTEMS looks good for Solaris in my case.  We are 
continuing to investigate.

Best regards,

Régis Détré






Duncan Grisby <duncan at grisby.org>

04/01/2006 12:22
Delivered date: 04/01/2006 12:22

 
        To:     Regis DETRE <regis.detre at sagem.com>
        cc:     omniorb-list at omniorb-support.com
        Subject:        Re: [omniORB] Omni 4.0.6 and Purify



On Wednesday 4 January, Regis DETRE wrote:

> We had some troubles to run one of our applications linked with Rational 

> Purify (4.2 and 2002) on Solaris 2.5.1 platforms.
> 
> After investigations, we have localized the trouble. It happens when 
> invoking the libomnithread.so library. The constructor of the static 
> member omni_thread_init (in src/lib/omnithread/solaris.cc) calls the 
> function thr_self() but the thread is not yet created, so segmentation 
> fault occurs.

Are you using the solaris.cc version of omnithread for a good reason?
Normally the posix.cc version is used on Solaris. solaris.cc is largely
a historical artifact left over from a time before Solaris supported
pthreads.

> To avoid the trouble, we comment the declaration in omnithread.h (line 
> 642). Otherwise, a better solution should be to create the inner class 
> instance at te omni_thead creation (singleton pattern). This is probably 

> the aim of the static member omni_thread::init_t::count which avoid 
> multiple instances.

It's important that omni_thread is initialised in the way it currently
is, because the things done in omni_thread::init_t::init_t() must happen
before anything else that uses omnithread. The only way that can be
ensured is to trigger it from everywhere that does #include
<omnithread.h>.

I have successfully run Purify on Solaris with omniORB in the past,
without having to change anything to do with omnithread, so it should be
possible to make it work.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20060104/90b85623/attachment.htm