Message: Re: Ancestor's tracking problem [maybe by linux version] Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Question Re: Ancestor's tracking problem [maybe by linux version] 

Forum: Event and Track Management
Re: Question Ancestor's tracking problem [maybe by linux version] (Margot )
Re: Idea Re: Ancestor's tracking problem [maybe by linux version] (Jaafar EL Bakkali)
Date: 05 Sep, 2017
From: Margot <Margot >

Hello, Ja3far:

Thank you for the advice. As you suggested, I used valgrind (+ the debugger) to see the cause of the segmentation fault. If my interpretation is not wrong, it seems to be a memory problem (like pointing a null space). From what I have looked for, this kind of error in geant4 is asociated with bugs, but, as I said in the first message, in my computer the code works fine. Any idea on what is going on and what shoud I do, please?

This is the relevant part of the message. (Last line means 'Segmentation fault'.)

### Run 0 starts. ... open Root analysis file : prueba.root - done ==28241== Invalid read of size 8 ==28241== at 0x426CFB: B1StackingAction::ClassifyNewTrack(G4Track const*) (in /home/margo/geant4/geant4.10.02/G4WORKDIR/neuflux/v27/v27-build/exampleB1) ==28241== by 0x764AA5A: G4StackManager::PushOneTrack(G4Track*, G4VTrajectory*) (G4StackManager.cc:168) ==28241== by 0x760E80B: G4EventManager::StackTracks(std::vector<G4Track*, std::allocator<G4Track*> >*, bool) (G4EventManager.cc:294) ==28241== by 0x760F3AC: G4EventManager::DoProcessing(G4Event*) (G4EventManager.cc:232) ==28241== by 0x73AA776: G4RunManager::ProcessOneEvent(int) (G4RunManager.cc:399) ==28241== by 0x73A90E2: G4RunManager::DoEventLoop(int, char const*, int) (G4RunManager.cc:367) ==28241== by 0x73A8EDD: G4RunManager::BeamOn(int, char const*, int) (G4RunManager.cc:273) ==28241== by 0x73C1FB2: G4RunMessenger::SetNewValue(G4UIcommand*, G4String) (G4RunMessenger.cc:376) ==28241== by 0xAEBDB44: G4UIcommand::DoIt(G4String) (G4UIcommand.cc:230) ==28241== by 0xAED59E7: G4UImanager::ApplyCommand(char const*) (G4UImanager.cc:523) ==28241== by 0xAEAE526: G4UIbatch::ExecCommand(G4String const&) (G4UIbatch.cc:170) ==28241== by 0xAEAFB4A: G4UIbatch::SessionStart() (G4UIbatch.cc:215) ==28241== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==28241== ==28241== ==28241== Process terminating with default action of signal 11 (SIGSEGV) ==28241== Access not within mapped region at address 0x0 ==28241== at 0x426CFB: B1StackingAction::ClassifyNewTrack(G4Track const*) (in /home/margo/geant4/geant4.10.02/G4WORKDIR/neuflux/v27/v27-build/exampleB1) ==28241== by 0x764AA5A: G4StackManager::PushOneTrack(G4Track*, G4VTrajectory*) (G4StackManager.cc:168) ==28241== by 0x760E80B: G4EventManager::StackTracks(std::vector<G4Track*, std::allocator<G4Track*> >*, bool) (G4EventManager.cc:294) ==28241== by 0x760F3AC: G4EventManager::DoProcessing(G4Event*) (G4EventManager.cc:232) ==28241== by 0x73AA776: G4RunManager::ProcessOneEvent(int) (G4RunManager.cc:399) ==28241== by 0x73A90E2: G4RunManager::DoEventLoop(int, char const*, int) (G4RunManager.cc:367) ==28241== by 0x73A8EDD: G4RunManager::BeamOn(int, char const*, int) (G4RunManager.cc:273) ==28241== by 0x73C1FB2: G4RunMessenger::SetNewValue(G4UIcommand*, G4String) (G4RunMessenger.cc:376) ==28241== by 0xAEBDB44: G4UIcommand::DoIt(G4String) (G4UIcommand.cc:230) ==28241== by 0xAED59E7: G4UImanager::ApplyCommand(char const*) (G4UImanager.cc:523) ==28241== by 0xAEAE526: G4UIbatch::ExecCommand(G4String const&) (G4UIbatch.cc:170) ==28241== by 0xAEAFB4A: G4UIbatch::SessionStart() (G4UIbatch.cc:215) ==28241== If you believe this happened as a result of a stack ==28241== overflow in your program's main thread (unlikely but ==28241== possible), you can try to increase the size of the ==28241== main thread stack using the --main-stacksize= flag. ==28241== The main thread stack size used in this run was 10485760. ==28241== ==28241== HEAP SUMMARY: ==28241== in use at exit: 19,848,443 bytes in 166,375 blocks ==28241== total heap usage: 877,962 allocs, 711,587 frees, 327,176,897 bytes allocated ==28241== ==28241== LEAK SUMMARY: ==28241== definitely lost: 951,760 bytes in 1,810 blocks ==28241== indirectly lost: 1,396 bytes in 28 blocks ==28241== possibly lost: 1,031,343 bytes in 23,478 blocks ==28241== still reachable: 17,863,944 bytes in 141,059 blocks ==28241== suppressed: 0 bytes in 0 blocks ==28241== Rerun with --leak-check=full to see details of leaked memory ==28241== ==28241== For counts of detected and suppressed errors, rerun with: -v ==28241== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) Violación de segmento

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 Idea: Re: Ancestor's tracking problem [maybe by linux version]   (Jaafar EL Bakkali - 06 Sep, 2017)
(_ Feedback: Re: Ancestor's tracking problem [maybe by linux version]   (Margot - 06 Sep, 2017)
(_ Idea: Re: Ancestor's tracking problem [maybe by linux version]   (Jaafar EL Bakkali - 06 Sep, 2017)
 Add Message Add Message
to: "Re: Ancestor's tracking problem [maybe by linux version]"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]