[omniORB] Threading problems

Michael Sommerville msommer@ptc.com
Wed, 10 Mar 1999 14:07:45 +0000


Hi,

I've been trying to use omniORB together with one of our
products which has a 'C' API to an Oracle based
application.  

I'm not at all sure why its happening, but omniORB is 
crashing on initialisation in the thread libray.  Presumably
there is some conflict between the threading used in the 
omnithreads library and that used within the API.  I tried 
recompiling to use Solaris instead of Posix threads with no
success.  

Here's what I get from dbx.

(process id 17840)
signal SEGV (no mapping at the fault address) in thr_self at
0xee2db2f8
thr_self+0x4:   ld      [%g7 + 0x24], %o0
(dbx) where
=>[1] thr_self(0x23fbe8, 0x0, 0x1, 0x23fbe8, 0x0, 0x64), at
0xee2db2f8
 [2] omni_thread::init_t::init_t(0x1, 0xee252e9c, 0x23fbe8,
0x23fba0, 0x0, 0xee043288), at
 [3] __STATIC_CONSTRUCTOR(0xee075ec4, 0xee2b6b60, 0x20e,
0xef7faaf0, 0x0, 0xee22171c), at
 [4] _init(0xef7fbe70, 0x0, 0x0, 0x0, 0x0, 0xee065518), at
0xee065548
 [5] call_init(0xef7fbd30, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [6] call_init(0xef7fbbec, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [7] call_init(0xef7fbaac, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [8] call_init(0xef7fb8cc, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [9] call_init(0xef7fb7b8, 0xef7f9a78, 0x80, 0xef7fac24,
0xeffff05c, 0xef7fac24), at 0xef7
 [10] call_init(0xef7fb6a4, 0xef7facfc, 0xef7f9a20, 0x0,
0xef7c05cc, 0x1), at 0xef7db960
 [11] call_init(0xef7fb590, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [12] call_init(0xef7fb478, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [13] call_init(0xef7fb364, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [14] call_init(0xef7fb248, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [15] call_init(0xef7fb130, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [16] call_init(0xef7fb018, 0x0, 0x0, 0x0, 0x0, 0x0), at
0xef7db960
 [17] call_init(0xef7fac24, 0xef7f9a78, 0x80, 0xef7fac24,
0xeffff05c, 0xef7fac24), at 0xef
 [18] setup(0xef7fac24, 0xef7facfc, 0xef7f9a20, 0x0,
0xef7c05cc, 0x1), at 0xef7db914
 [19] _setup(0xef7fac24, 0x0, 0x0, 0x10074, 0xef7d0000,
0xef7f9890), at 0xef7df078
 [20] _rt_boot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xef7d72dc

This seems strange as dbx claims to have read the symbolic
information
for both the thread and pthread libraries.

I'm using omniORB 2.7.0, Solaris 2.5 and Suns C (4.0) and
C++ (4.1) 
compilers.  Can anyone give me some pointers to what I've
done wrong or how to 
try further investigate this problem??

Many thanks,

Michael