Re: Severe problem with PyRoot - file segmentation fault

From: James Jackson <james.jackson_at_cern.ch>
Date: Sat, 14 Jun 2008 01:13:55 +0100

Wim,

Right, I think this narrows things down somewhat. Two simple greps on gdb output with LD_DEBUG=files set:

[james_at_slc4vm ~]$ cat gdb.out | grep libCore | grep init

1. calling init: /home/james/root/lib/libCore.so

Looks ok...

[james_at_slc4vm ~]$ cat gdb.out | grep libHist | grep init

1. calling init: /home/james/root/lib/libHist.so
2. calling init: /usr/local/lib/root/libHist.so

Ah. How, /home/james has the location where I had previously installed ROOT. I had deleted all this and started from scratch, but of course the new download / build had re-build the libraries there. I also had a relic in LD_LIBRARY_PATH set in ~/.bash_profile to point to just that location...

Having removed the old LD_LIBRARY_PATH entry and starting with a fresh shell, the test script executes just fine:

[james_at_slc4vm ~]$ python problemscript.py

TFile**		test.root	
  TFile*		test.root	
   OBJ: TH1F	testhist	testhist : 0 at: 0x8e59d00

[james_at_slc4vm ~]$

Many thanks for your help!

Regards,
James.

On 13 Jun 2008, at 23:37, <WLavrijsen_at_lbl.gov> <WLavrijsen_at_lbl.gov> wrote:

> James,
>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread -1208592704 (LWP 6011)]
>> 0x006dabe0 in main_arena () from /lib/tls/libc.so.6
>
> no, unfortunately, that doesn't add. Just the same info as the a
> double
> delete.
>
> There are two things that I can think of that cause this. First, given
> all the "already added to TClassTable" messages, libraries could be in
> multiple linker namespaces (this is what happens on the Mac; looking
> at
> the linux dynamic linker source, I see that at least it can do the
> same
> thing, but I wouldn't know what causes it). These multiple libs, in
> particular libCore dupes will yield multiple global variables, and
> those
> crash in cleanup on application shutdown.
>
> Could you run the sample with the LD_DEBUG environment variable set to
> 'files'? That way, if libs such as libHist.so and libCore.so are
> loaded
> multiple times, it should show up in the output.
>
> Other option is that (for same reasons like above), the TH1F is
> deleted
> twice. Can you add a line:
>
> from ROOT import SetOwnership
> SetOwnership( g, False )
>
> with 'g' being the test histogram and rerun? Normally, ROOT objects,
> such as the TFile f in your example program, communicate when objects
> go away. If there are multiple copies of globals, due to multiple libs
> being loaded, that may not work as intended.
>
> Thanks,
> Wim
> --
> Wim.Lavrijsen_at_cern.ch -- WLavrijsen_at_lbl.gov -- www.lavrijsen.net
>
> "Your day will be somewhat dictated by authority." --fortune
> cookie
Received on Sat Jun 14 2008 - 02:14:05 CEST