RE: [ROOT] Crashing before main()

From: Philippe Canal (pcanal@fnal.gov)
Date: Tue May 25 2004 - 18:17:24 MEST


> Do you think that I can force the loading order of the libraries ?

Not really but you can alleviate the issue by using the techniques I 
described.

However ... if the problem is really stemming from libraries incompatibilities
this might not help :(

To check the origin, you can also try 
  strings /opt/sag/exx/v611/lib/libbasecrypt.so

Cheers,
Philippe.

-----Original Message-----
From: Hermann-Josef Mathes [mailto:Hermann-Josef.Mathes@ik.fzk.de]
Sent: Tuesday, May 25, 2004 9:03 AM
To: Christian Holm Christensen
Cc: pcanal@fnal.gov; Hermann-Josef Mathes; roottalk@cern.ch;
kopmann@ik.fzk.de; michael.funcke@physik.uni-wuppertal.de
Subject: Re: [ROOT] Crashing before main()


Hello Christian and Philippe,

thanks for your proposals and assistance.

Well it could really be a compiler problem as DCOM/Entire-X 6.1.1 is from
the SuSE 6.4 days when the egcs compiler was used. A new one (7.1.1) is
said to be compatible with gcc 3.2. The mico package was created from
source by me, also ROOT - so there is no incompatibility with my present
environment.

Unfortunatley the 3rd party libraries hide their origin very well:
> nm -C /opt/sag/exx/v611/lib/libbasecrypt.so
nm: /opt/sag/exx/v611/lib/libbasecrypt.so: no symbols
> nm -C /opt/sag/exx/v611/lib/liboleaut32.so
nm: /opt/sag/exx/v611/lib/liboleaut32.so: no symbols
> nm -C /opt/sag/exx/v611/lib/libmutant.so
nm: /opt/sag/exx/v611/lib/libmutant.so: no symbols

Some of the (not top secret) libs gave messages like:
"gcc2_compiled" or "*@@@GLIBC_2.0"

nm -C /usr/local/mico/lib/libmico.so | more
give of course many "gcc2_compiled" messages.

As we are planning soon a move to gcc 3.x I see no reason to downgrade to
pre-2.95 times ;-)

Do you think that I can force the loading order of the libraries ?

Thanks again & Cheers
Hermann-Josef

On Thu, 20 May 2004, Christian Holm Christensen wrote:

> Hi,
>
> Philippe Canal <pcanal@fnal.gov> wrote concerning
>   RE: [ROOT] Crashing before main() [Wed, 19 May 2004 16:01:14 -0500]
> ----------------------------------------------------------------------
> > Hi,
> >
> > Indeed, the most likely cause is a load ordering issue.
>
> A long time ago, I had a similar problem that was bothering me a lot.
> I was trying to run a small program that used a third-party,
> proprietary, binary-only, library - it kept SIGSEGV even before I
> could break into main.
>
> Well, it turned out, that the third-party library I was linking
> against, was compiled with another (and incompatible) compiler than
> the one I was using (I think it was EGCS vs. GCC - yes, that long time
> ago :-).  I solved the problem by using the compiler used to build the
> third-party library.
>
> So, I guess you should check Mico and see if it's build with the same
> compiler as you build ROOT and your application with.
>
> > Surprisingly (actually I think this is a compiler error), gSystem
> > must be neither zero nor a valid value.
>
> What about NULL?
>
> > You could assert this 'guess' by putting a fprintf(stderr,"0x%x\n",gSystem);
> > in TTimer::Reset().
>
> Why not
>
>   std::cout << "0x" << std::hex << gSystem << std::endl;
>
> :-)
>
> > You may also want to check that ldd esmd returns the expected libraries.
>
> This may also give you a hint of what I was talking about.
>
> You can also check
>
>   nm -C <path to lib>/libmico.so
>
> (or what ever it's called) and see what kind of GCC was used (the
> symbols are obvious).
>
> >
> > Cheers,
> > Philippe.
> >
> > -----Original Message-----
> > From: owner-roottalk@pcroot.cern.ch
> > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Mathes, Hermann-Josef
> > Sent: Monday, May 10, 2004 10:46 AM
> > To: roottalk@cern.ch
> > Cc: Mathes, Hermann-Josef; kopmann@ik.fzk.de;
> > michael.funcke@physik.uni-wuppertal.de
> > Subject: [ROOT] Crashing before main()
> >
> >
> > Dear Rooters,
> >
> > I have a problem in a large application coming probably from some dynamic library incompatibilities.
> >
> > The program is crashing before main() is executed.
> >
> > I am using the following 'environment':
> > - SuSE Linux 7.3 with gcc 2.95.3 and kernel 2.4.10
> > - root 3.05.07, generated with the options:
> >   "./configure linux --enable-table --enable-thread --enable-soversion"
> > - Mico 2.3.0 (a free CORBA implementation)
> > - Entire-X 6.1.1 (DCOM for Linux/Unix) + OCSLTK 1.1 (this is an OPC=OLE for
> >   Process Control built on top of DCOM)
> >
> > The problem persits independent from the fact if a TROOT object is created. Im not using any ROOT classes (like TObject & Co. or TSocket) simply the dictionary compiled into one of my own libs.
> >
> > Using this rather 'old' releases is done for technical (hardware & driver compatibility) reasons.
> >
> > The DCOM-stuff is using threads (intrinsically for IUnknown derived client side interfaces=callbacks).
> >
> > This is the error I get (with/without debugger):
> >
> > mathes@ikauger2:~/FD-DAS/Eye/Esm/daemon> esmd
> > Segmentation fault
> > mathes@ikauger2:~/FD-DAS/Eye/Esm/daemon> gdb esmd
> > GNU gdb 20010316
> > CThis GDB was configured as "i386-suse-linux"...
> > (gdb) r
> > Starting program: /home/mathes/FD-DAS/Eye/Esm-devel/daemon/esmd
> > [New Thread 1024 (LWP 4509)]
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1024 (LWP 4509)]
> > 0x410547b1 in TTimer::Reset () from /usr/local/root-3.05.07/lib/libCore.so.3.05
> > (gdb) back
> > #0  0x410547b1 in TTimer::Reset ()
> >    from /usr/local/root-3.05.07/lib/libCore.so.3.05
> > #1  0x41054317 in TTimer::TTimer ()
> >    from /usr/local/root-3.05.07/lib/libCore.so.3.05
> > #2  0x41054b8e in __static_initialization_and_destruction_0 ()
> >    from /usr/local/root-3.05.07/lib/libCore.so.3.05
> > #3  0x41054e12 in global constructors keyed to TTimer::TTimer ()
> >    from /usr/local/root-3.05.07/lib/libCore.so.3.05
> > #4  0x412d8f27 in __do_global_ctors_aux ()
> >    from /usr/local/root-3.05.07/lib/libCore.so.3.05
> > #5  0x40fe4452 in _init () from /usr/local/root-3.05.07/lib/libCore.so.3.05
> > #6  0x4000b7a7 in call_init () from /lib/ld-linux.so.2
> > #7  0x4000b900 in _dl_init () from /lib/ld-linux.so.2
> > (gdb)
> >
> > Thanks for any help or proposal to solve the problem.
> > Regards
> > Hermann-Josef
>
> Yours,
>
>  ___  |  Christian Holm Christensen
>   |_| |	 -------------------------------------------------------------
>     | |	 Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
>      _|	          DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
>     _|	          Denmark                    Office: (+45) 353  25 404
>  ____|	 Email:   cholm@nbi.dk               Web:    www.nbi.dk/~cholm
>  | |
>
>



This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:08 MET