|Message: Re: Double delete when in MT mode||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
On Fri, 23 Dec 2016 16:01:52 GMT, Giuseppe Vacanti wrote:
> I thought I would post an update on the problem. > > I followed the advice given, cleaned up how I was holding pointers, and > I can run the application if I do not try to write any data out. If I > activate a stepping action I again trigger a core dump. I can post the > few lines of code (m_runman is a const pointer to the MT RunManager): > > ...UserSteppingAction(const G4Step* aStep) > const G4Track * aTrack = aStep->GetTrack(); > G4VPhysicalVolume * volume = aTrack->GetVolume(); > const G4int event_id = m_runman->GetCurrentEvent()->GetEventID(); > const G4int track_id = aTrack->GetTrackID(); > > The pointer called volume seems to be valid, but as soon as I try to > make use of it I get a core dump.
Hmmm. Do you see anything different if you access the volume via the G4Step instead?
G4VPhysicalVolume* volume = aStep->GetPreStepPoint()->GetPhysicalVolume();
Note that I'm using the pre-step volume here. At a boundary, the post-step volume is not where the track _is_, but where it _will_be_ at the start of the next step. Also, when a track leaves the world (status fWorldBoundary), the post-step volume is null.
> I had understood that I'm allowed to fetch geometry-related data in a > thread, as the geometry is constant, but I'm not doing this correctly. > Of course, with a core dump the problem could be somewhere else, and > just manifest itself here.
It looks to me like you're accessing the geometry correctly. The volume pointers are shared across threads (and are implicitly const, therefore :-). If you run in the debugger, does the traceback show the segfault when you dereference "volume", or somewhere else? When you do the dereference, what information are you trying to get? Just the name, or something deeper into the geometry?
-- Mike Kelsey