Re: TChain->GetEntry(jentry) - Segmentation Fault

From: Alexandros Attikis <attikis_at_cern.ch>
Date: Tue, 31 Aug 2010 15:23:34 +0200

On 31 Aug 2010, at 14:53, Axel Naumann wrote:

> Hi Alexandros,
> 
> do you have a memory leak (check with e.g. ps, free,...)? Can you run
> with valgrind (see http://valgrind.org)?
I am already running with it. It should take quite a long time according to the link. Should I post here the result?
> Can you post the complete
> backtrace you got from GDB (the one ending with memset)? Can you reduce
> your code to something we can run, and give us the ROOT file so we can
> reproduce it?

I will put gdb on the side for now.
I guess I should finish off with valgrind and if I am still at a dead-end I can move to gdb.  
> 
> Cheers, Axel.
> 
> On 8/31/10 2:48 PM, Alexandros Attikis wrote:

>> Hi ROOTers,
>>
>> I have a used "makeClass" to access an ntuple and manipulate it using
>> C++ code and ROOT. I compile the code with g++ and
>> have run on multiple samples including millions of events.
>>
>> Now, when trying to run on a specific QCD ntuple, I get a segmentation
>> fault after ~140k events, always at the same point if a start from zero.
>> I have tried to start 10 events before it and and runs smoothly up to
>> some other event later on where it crashes with the same error.
>> Obviously it is not
>> the specific event that is causing the seg. fault. I have also had a
>> look at the ROOT files (2) and they seem okay.
>>
>> I have used cout to pinpoint the error to right before I access the
>> specific entry of the TChain:
>> nb = fChain->GetEntry(jentry);
>>
>> I have tried to use gdb (beginner using this) but with no success of
>> finding something useful. The Crash when running gdb gives:
>> Program received signal SIGSEV, Segmentation fault.
>> 0x00000033c627ac4a in memset () from /lib64/libc.so.6
>>
>> Back-tracing hasn't been very useful, but as I said I am not experienced
>> in using gdb.
>>
>> Can someone direct as to how to locate/fix the problem?
>> Is it the aforementioned piece of code or is it possible that the
>> problem lies somewhere else?
>>
>>
>> Cheers,
>> Alexandros

> Received on Tue Aug 31 2010 - 15:23:39 CEST

This archive was generated by hypermail 2.2.0 : Tue Aug 31 2010 - 17:50:02 CEST