Hi Alexandros,
yes, you can post the valgrind results if you need help with
interpreting them.
Cheers, Axel.
Alexandros Attikis wrote on 08/31/2010 03:23 PM:
>
> 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:52:54 CEST