<br><font size=2 face="sans-serif">We successfully run Purify with omniORB on lot of applications, but one, which linked with ILOG Views 3.0.2 and Purify, always crashes.</font>
<br>
<br><font size=2 face="sans-serif">We are using posix.cc and we have the same trouble. The same correction permits us to run Purify.</font>
<br>
<br><font size=2 face="sans-serif">The comment in omnithread.h saids :</font>
<br>
<br><font size=2 face="Courier New">#ifndef __rtems__</font>
<br><font size=2 face="Courier New">static omni_thread::init_t omni_thread_init;</font>
<br><font size=2 face="Courier New">#else</font>
<br><font size=2 face="Courier New">// RTEMS calls global Ctor/Dtor in a context that is not</font>
<br><font size=2 face="Courier New">// a posix thread. Calls to functions to pthread_self() in</font>
<br><font size=2 face="Courier New">// that context returns NULL. </font>
<br><font size=2 face="Courier New">// So, for RTEMS we will make the thread initialization at the</font>
<br><font size=2 face="Courier New">// beginning of the Init task that has a posix context.</font>
<br><font size=2 face="Courier New">#endif</font>
<br>
<br><font size=2 face="sans-serif">The explanation for RTEMS looks good for Solaris in my case. We are continuing to investigate.</font>
<br>
<br><font size=2 face="sans-serif">Best regards,</font>
<br>
<br><font size=2 face="sans-serif">Régis Détré</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Duncan Grisby <duncan@grisby.org></b></font>
<br>
<p><font size=1 face="sans-serif">04/01/2006 12:22</font>
<br><font size=1 face="sans-serif">Delivered date: 04/01/2006 12:22</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: Regis DETRE <regis.detre@sagem.com></font>
<br><font size=1 face="sans-serif"> cc: omniorb-list@omniorb-support.com</font>
<br><font size=1 face="sans-serif"> Subject: Re: [omniORB] Omni 4.0.6 and Purify</font>
<br></table>
<br>
<br>
<br><font size=2 face="Courier New">On Wednesday 4 January, Regis DETRE wrote:<br>
<br>
> We had some troubles to run one of our applications linked with Rational <br>
> Purify (4.2 and 2002) on Solaris 2.5.1 platforms.<br>
> <br>
> After investigations, we have localized the trouble. It happens when <br>
> invoking the libomnithread.so library. The constructor of the static <br>
> member omni_thread_init (in src/lib/omnithread/solaris.cc) calls the <br>
> function thr_self() but the thread is not yet created, so segmentation <br>
> fault occurs.<br>
<br>
Are you using the solaris.cc version of omnithread for a good reason?<br>
Normally the posix.cc version is used on Solaris. solaris.cc is largely<br>
a historical artifact left over from a time before Solaris supported<br>
pthreads.<br>
<br>
> To avoid the trouble, we comment the declaration in omnithread.h (line <br>
> 642). Otherwise, a better solution should be to create the inner class <br>
> instance at te omni_thead creation (singleton pattern). This is probably <br>
> the aim of the static member omni_thread::init_t::count which avoid <br>
> multiple instances.<br>
<br>
It's important that omni_thread is initialised in the way it currently<br>
is, because the things done in omni_thread::init_t::init_t() must happen<br>
before anything else that uses omnithread. The only way that can be<br>
ensured is to trigger it from everywhere that does #include<br>
<omnithread.h>.<br>
<br>
I have successfully run Purify on Solaris with omniORB in the past,<br>
without having to change anything to do with omnithread, so it should be<br>
possible to make it work.<br>
<br>
Cheers,<br>
<br>
Duncan.<br>
<br>
-- <br>
-- Duncan Grisby --<br>
-- duncan@grisby.org --</font>
<br><font size=2 face="Courier New"> -- http://www.grisby.org --<br>
</font>
<br>
<br>