[omniORB] omniORBpy 2.3, Mac OSX 10.3 and static initializers

[Asa MacWilliams]

Hi,

I had OmniORB 4.0.1 and omniORBpy 2.0 working fine on Mac OS 10.2, using 
Python 2.2.
An upgrade to OmniORB 4.0.3 and omniORBpy 2.3 on Mac OS 10.3.1 breaks 
omniORBpy, as you describe; OmniORB itself works fine, as does OmniNotify.

To me, this seems to be (again) a problem with the dynamic library loader on 
Mac OS X.

I have included a stack trace at the constructor of orbOptions below.
On loading the module _omnipymodule.so, the dynamic loader loads 
libomniORB4.dylib and then libomniithread.dylib, and starts calling the 
static initializers. One of them is 

static omni_orbOptions_initialiser initialiser;
which calls
orbOptions::singleton(),
which then calls
orbOptions::orbOptions().

At this point, the dynamic loader performs "lazy binding" of the function 
orbOptions::orbOptions(), and apparently doesn't realize that libomniORB4 is 
already being initialized. It thus tries to load and initialize the library 
again, calling the static initializers again, and calling singleton() again. 

You can see this in the stack trace, showing singleton() twice, which 
obviously shouldn't occur.

Breakpoint 6, 0x0064ff84 in omni::orbOptions::orbOptions() ()
(gdb) backtrace
#0  0x0064ff84 in omni::orbOptions::orbOptions() ()
#1  0x006515bc in omni::orbOptions::singleton() ()
#2  0x006c9694 in __static_initialization_and_destruction_0(int, int) ()
#3  0x8fe178d0 in __dyld_call_module_initializers_for_library ()
#4  0x8fe17648 in __dyld_call_module_initializers ()
#5  0x8fe118ac in __dyld_link_in_need_modules ()
#6  0x8fe11290 in __dyld_bind_lazy_symbol_reference ()
#7  0x8fe01620 in __dyld_stub_binding_helper_interface ()
#8  0x006515b4 in omni::orbOptions::singleton() ()
#9  0x006c9344 in __static_initialization_and_destruction_0(int, int) ()
#10 0x8fe178d0 in __dyld_call_module_initializers_for_library ()
#11 0x8fe17648 in __dyld_call_module_initializers ()
#12 0x8fe118ac in __dyld_link_in_need_modules ()
#13 0x8fe113f4 in __dyld_bind_lazy_symbol_reference ()
#14 0x8fe01620 in __dyld_stub_binding_helper_interface ()
#15 0x006c8c78 in __static_initialization_and_destruction_0(int, int) ()
#16 0x8fe178d0 in __dyld_call_module_initializers_for_library ()
#17 0x8fe17648 in __dyld_call_module_initializers ()
#18 0x8fe118ac in __dyld_link_in_need_modules ()
#19 0x8fe113f4 in __dyld_bind_lazy_symbol_reference ()
#20 0x8fe01620 in __dyld_stub_binding_helper_interface ()
#21 0x006c8658 in __static_initialization_and_destruction_0(int, int) ()
#22 0x8fe178d0 in __dyld_call_module_initializers_for_library ()
#23 0x8fe17648 in __dyld_call_module_initializers ()
#24 0x8fe118ac in __dyld_link_in_need_modules ()
#25 0x8fe11290 in __dyld_bind_lazy_symbol_reference ()
#26 0x8fe01620 in __dyld_stub_binding_helper_interface ()
#27 0x002b9104 in omni_thread::init_t::init_t() ()
#28 0x0043fc8c in __static_initialization_and_destruction_0(int, int) ()
#29 0x8fe17b38 in __dyld_call_module_initializers_for_objects ()
#30 0x8fe17600 in __dyld_call_module_initializers ()
#31 0x8fe118ac in __dyld_link_in_need_modules ()
#32 0x8fe134e4 in __dyld__dyld_link_module ()
#33 0x9003f5a8 in NSLinkModule ()
#34 0x0008b714 in _PyImport_GetDynLoadFunc ()
#35 0x0008b858 in _PyImport_LoadDynamicModule ()
#36 0x0000f21c in load_module ()
...

I still don't see how that causes the "double free", but it obviously can't be 
right. Unfortunately, I haven't been able to reproduce the problem 
independently from OmniORB using a simple dynamic library test program.

Also note that the stack trace shows includes omni_thread::init_t::init_t(), 
which would seem to imply that initialization of the omnithread library leads 
to initialization of omniORB, which also seems strange (it should be the 
other way around).

In theory, adding the option -bind_at_load when linking _omnipymodule.so 
should disable lazy binding. I've tried that as well, and it doesn't seem to 
help. Neither does the environment variable DYLD_BIND_AT_LAUNCH (which would 
only apply to the python executable itself, not loaded modules).

Now I've been trying various downgrades; Python 2.2 doesn't help, neither does 
omniORBpy 2.2. I'll try OmniORB 4.0.1 next.

I'll keep you posted if I discover anything new.

Happy holidays,
Asa

On Friday 05 December 2003 07:25, Zachery Corbiere wrote:
> 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.

-- 

|\ /\ /| Dipl.-Inf. Asa MacWilliams      TU Muenchen, Institut fuer Informatik
| /--\ | asa.macwilliams at in.tum.de    Boltzmannstr. 3, 85748 Garching, Germany
|/ \/ \| www.in.tum.de/~macwilli          Zimmer 01.07.059 (I1), 089-289-18228