[omniORB] omniORBpy 2.3 and Mac OSX

[Zachery Corbiere]

On Dec 4, 2003, at 10:21 PM, Zachery Corbiere wrote:

> I'm pretty much certain this is caused by (some?) static constructors 
> in shared libraries not being run.  Being a newbie to the OSX 
> platform, though, I'm still feeling my way through fixing the problem.
Yay, replying to my own article.  So after further investigation, I 
found that in this code in orbOptions.cc:
orbOptions&
orbOptions::singleton() {
   static orbOptions* singleton_ = 0;
   if (!singleton_) {
     singleton_ = new orbOptions();
   }
   return *singleton_;
}

singleton_ is actually initialized twice, to different values (!?!).  I 
also put debug printf's in the orbOptions constructor to verify that it 
is being called twice.  Below is the output of my debug prints.  This 
is executing at the python REPL:

 >>> import omniORB
Creating orbOptions 30e6f0, thread: -1610571284.
inited singleton 30e6f0.
&singleton_=114caac
*** malloc[29251]: error for object 0x311240: Double free
begin reg InitRef handler.
end reg InitRef handler.
Creating orbOptions 30e710, thread: -1610571284.
inited singleton 30e710.
&singleton_=114caac
 >>>

Of special note are the begin and end reg InitRef handler lines, which 
are printfs I inserted in initRefs.cc around the registration of the 
InitRef handler.  Those regs are run against one singleton_ value and 
then another is created and, apparently, overwrites the pointer for the 
first.

I now doubt this is due to static constructors not being run.  That's 
what I get for guessing :-)

-- 
Zac Corbiere
zcorb at fluidarch.com