Message: Re: Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: 

Forum: Run Management
Re: Warning "WARNING - Attempt to delete the physical volume store while geometry closed !" crash (Yen-Yung Chang)
Re: None Re: (Yen-Yung Chang)
Re: None Re: (Marc Verderi)
Re: None Re: Re: (Yen-Yung Chang)
Date: 10 Nov, 2012
From: Marc Verderi <Marc Verderi>

Hi Yen-Yung,

I'm glad this fixes the problem. However, I may have missed some things, 
as I took this discussion late, but you don't need to kill the track: 
the tracking will do this for you in the case it reaches the 
"OutOfWorld". Also, please note that "OutOfWorld" is not a volume, but 
simply something printed by the SteppingVerbose to tell the track has 
reached the world volume boundary and is hence going "OutOfWorld".

Cheers,
Marc


On 11/10/2012 03:32 AM, Yen-Yung Chang wrote:
> *** Discussion title: Run Management
>
> Dear Marc:
>
> It's exactly what caused the trouble!! I replaced
>
> if (theTrack->GetNextVolume()->GetName() == "OutOfWorld")
>
> by
>
> if (!theTrack->GetNextVolume())
>
> . Now the if script can identify going-out-of-world tracks and kills
> them. Thank you so much!
>
> Yen-Yung Chang
>
> On Fri, 09 Nov 2012 09:29:38 GMT, Marc Verderi wrote:
>
>> Dear Yen-Yung,
>>
>> I believe you hit the typical "trap" of a track reaching the world
>> boundary: when the track reaches the world boundary, there is no "next
>> volume" and hence the pointer is 0. Calling GetName() on this null
>> pointer then creates the crash. Please just check if
>> "theTrack->GetNextVolume()" is null or not before calling GetName().
>>
>> Marc
>>
>> On 11/09/2012 10:05 AM, Yen-Yung Chang wrote:
>>> *** Discussion title: Run Management
>>>
>>> I found this happened at the steps whenever the particle was going out
>>> of the world volume. So I added:
>>>
>>>      if (theTrack->GetNextVolume()->GetName() == "OutOfWorld"){
>>>
>>>         theTrack->SetTrackStatus(fStopAndKill);
>>>         cout << "particle almost goes out op the world volume, killed." << endl;
>>>         getchar();
>>>         }
>>>
>>> But this didn't help. Same crash happened.
>>>
>>> *********************************************************************************************************
>>> * G4Track Information:   Particle = gamma,   Track ID = 1, Parent ID = 0
>>> *********************************************************************************************************
>>>
>>> Step#    X(mm)    Y(mm)    Z(mm) KinE(MeV)  dE(MeV) StepLeng TrackLeng  NextVolume ProcName
>>>       0      0.1     1.44     1.44      0.06        0 0         0    blackBox initStep
>>>       1     0.07     1.44     1.44      0.06        0     0.03 0.03      VM2000 Transportation
>>>       2        0     1.44     1.44      0.06        0     0.07 0.1 crystalCell Transportation
>>>       3   -0.554     1.44     1.44    0.0598        0    0.554 0.654 crystalCell compt
>>>       4       -3    0.901     1.75    0.0598        0     2.52 3.18 inMask_glue_phys Transportation
>>>       5     -3.6    0.769     1.83    0.0598        0    0.619 3.8       glass Transportation
>>>       6     -4.4    0.592     1.93    0.0598        0    0.826 4.62 MAPMTinside Transportation
>>>       7    -20.4    -2.93     3.99    0.0598        0     16.5 21.1 MAPMTcase_back_phys Transportation
>>>       8    -21.2    -3.11     4.09    0.0598        0 0.826        22    blackBox Transportation
>>>       9     -143      -30     19.8    0.0598        0      126 148  OutOfWorld Transportation
>>>
>>>    *** Break *** segmentation violation
>>>
>>> =========================================================== There was a
>>> crash. This is the entire stack trace of all threads:
>>> ===========================================================
>>>
>>> #0  0x00000031832ba2da in waitpid () from /lib64/libc.so.6
>>> #1  0x000000318324142e in do_system () from /lib64/libc.so.6
>>> #2  0x00007fef0a4a10dc in TUnixSystem::StackTrace() () from /home/gixd/root/lib/libCore.so
>>> #3  0x00007fef0a4a3913 in TUnixSystem::DispatchSignals(ESignals) () from /home/gixd/root/lib/libCore.so
>>> #4  <signal handler called>
>>> #5  0x0000003186abd768 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /lib64/libstdc++.so.6
>>> #6  0x00007fef110233eb in N01SteppingAction::UserSteppingAction(G4Step const*) () from /home/gixd/g4work/tmp/Linux-g++/exampleN01/libexampleN01.so
>>> #7  0x00007fef0e381182 in G4SteppingManager::Stepping() () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4tracking.so
>>> #8  0x00007fef0e38b09c in G4TrackingManager::ProcessOneTrack(G4Track*) () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4tracking.so
>>> #9  0x00007fef0e5b96c9 in G4EventManager::DoProcessing(G4Event*) () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4event.so
>>> #10 0x00007fef0e82021e in G4RunManager::DoEventLoop(int, char const*, int) () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4run.so
>>> #11 0x00007fef0e81fd5c in G4RunManager::BeamOn(int, char const*, int) () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4run.so
>>> #12 0x0000000000404671 in main ()
>>>
>>> ===========================================================
>>>
>>> The lines below might hint at the cause of the crash. If they do not
>>> help you then please submit a bug report at http://root.cern.ch/bugs .
>>> Please post the ENTIRE stack trace from above as an attachment in
>>> addition to anything else that might help us fixing this issue.
>>> ===========================================================
>>>
>>> #5  0x0000003186abd768 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /lib64/libstdc++.so.6
>>> #6  0x00007fef110233eb in N01SteppingAction::UserSteppingAction(G4Step const*) () from /home/gixd/g4work/tmp/Linux-g++/exampleN01/libexampleN01.so
>>> #7  0x00007fef0e381182 in G4SteppingManager::Stepping() () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4tracking.so
>>> #8  0x00007fef0e38b09c in G4TrackingManager::ProcessOneTrack(G4Track*) () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4tracking.so
>>> #9  0x00007fef0e5b96c9 in G4EventManager::DoProcessing(G4Event*) () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4event.so
>>> #10 0x00007fef0e82021e in G4RunManager::DoEventLoop(int, char const*, int) () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4run.so
>>> #11 0x00007fef0e81fd5c in G4RunManager::BeamOn(int, char const*, int) () from /home/gixd/geant4/geant4.9.5.p01-build/lib64/libG4run.so
>>> #12 0x0000000000404671 in main ()
>>>
>>> ===========================================================
>>>
>>> WARNING - Attempt to delete the physical volume store while geometry
>>> closed ! WARNING - Attempt to delete the logical volume store while
>>> geometry closed ! WARNING - Attempt to delete the solid store while
>>> geometry closed ! WARNING - Attempt to delete the region store while
>>> geometry closed !
>>>
>>> -------------------------------------------------------------
>>> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
>>> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/runmanage/333/3.html
> -------------------------------------------------------------
> Visit this GEANT4 at hypernews.slac.stanford.edu message (to reply or unsubscribe) at:
> http://hypernews.slac.stanford.edu/HyperNews/geant4/get/runmanage/333/3/1/1.html

 Add Message Add Message
to: "Re:"

 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 ]