[omniORB] Linux, EGCS 1.1a and OmniORB 2.6.0: dumps core in ORB_init

Brent Fulgham bfulgham@xpsystems.com
Tue, 22 Sep 1998 08:16:21 -0700


Richard and Sai-Lai --

I can attest that the Debian 2.0 (glibc) build (which I did using egcs 1.1c)
works very well.  One glitch I had was that the configure file format
changed a bit (it now uses "NAMESERVER IOR:..." instead of "IOR:....."), so
my old configuration file was not usable.   I start omniNames with a script
at system boot, so I didn't realize it wasn't running.  If I tried to use
eg3_impl or similar that called the Nameserver I would segfault.

The other possibility (besides any compiler issues) is that you are not
using the correct stdc++ library.  You might want to verify that you are
using the library built with your compiler.

-Brent


>Richard,
>
>Did you find out what was wrong?
>
>I would suspect your egcs 1.1a build is the source of the problem.
>Just to be sure:
>
>1. Did you build egcs with --enable-threads?
>2. Do you use binutils-2.9.1.x as instructed?
>
>We have been using egcs snapshot up to 980824 on x86 redhat 5.1. Haven't
tried
>egcs-1.1 though.
>
>Regards,
>
>Sai Lai
>
>
>
>>>>>> Richard Jones writes:
>
>> Does the following bug ring any bells? I'm not sure if it's
>> a Linux 2.1 problem, something to do with egcs 1.1a, pthreads
>> or OmniORB itself ... Any program beyond the most trivial
>> bombs out at the very first line in ORB_init. eg1 and
>> eg2_impl run OK however. But eg3_impl also dumps core in
>> the same way.
>
>> Configuration: Linux 2.1.119
>> EGCS 1.1a
>> glibc-2.0.7-19 (includes pthread-0.7)
>> OmniORB latest snapshot / 2.6.0 (also seen with 2.5.0)
>
>> Stack trace:
>
>> Program received signal SIGUSR1, User defined signal 1.
>> 0x401f3984 in __syscall_sigsuspend ()
>> Current language:  auto; currently c
>> (gdb) bt
>> #0  0x401f3984 in __syscall_sigsuspend ()
>> #1  0x40217e7c in __DTOR_END__ ()
>> #2  0x401182ed in pthread_create (thread=0x80cf61c, attr=0xbffff5f4,
>>     start_routine=0x4010f440 <omni_thread_wrapper>, arg=0x80cf5e8)
>>     at restart.h:32
>> #3  0x4010f79f in omni_thread::start ()
>> #4  0x4010f8b9 in omni_thread::start_undetached ()
>> #5  0x400c1205 in outScavenger_t::outScavenger_t ()
>> #6  0x4007585c in StrandScavenger::initOutScavenger ()
>> #7  0x4005b186 in CORBA::ORB_init ()
>> #8  0x804ae7b in main (argc=1, argv=0xbffff764) at main.cc:30
>
>> Any guidance as to where to look would be most helpful :-)
>
>--
>Dr. Sai-Lai Lo                          |       Research Scientist
>                                        |
>E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research
Lab
>                                        |       24a Trumpington Street
>Tel:            +44 223 343000          |       Cambridge CB2 1QA
>Fax:            +44 223 313542          |       ENGLAND