Message: Double deletes in ~G4Track() Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Double deletes in ~G4Track() 

Forum: Event and Track Management
Date: 18 Sep, 2012
From: Tom Roberts <Tom Roberts>

I am having trouble with double deletes.

    // VERY simplified Example that displays the problem:
    void someFunction(const G4Track *track) {
        G4Track *p = new G4Track(*track);
        // ... some code using *p and *track
        delete p;

When the caller deletes track, in ~G4Track() both the G4DynamicParticle and the G4VUserTrackInformation are deleted a second time. This is due to the fact that they are deleted in ~G4Track(), but their POINTERS are copied in the copy constructor. (Basic C++: every delete must be matched by a corresponding new, but here there is an extra delete for each of these two pointers.)

I believe the G4Track copy constructor should be changed to perform a deep 
copy to avoid these double deletes. This has thorns, as there is no way to do 
such a deep copy of the user's class via the virtual base-class pointer. Some
possible approaches:
 1. enhance G4VUserTrackInformation with a virtual clone() function
 2. the G4Track copy constructor issues a fatal G4Exception if there is
    a G4VUserTrackInformation present
 3. don't delete G4VUserTrackInformation in ~G4Track(), and document this
    clearly to the user (requires existing users to change their code in ways
    that may be difficult or impossible)
 4. omit the copy constructor and implement a G4Track::clone() function
    that does a deep copy (combined with #1 so that's possible)
Any approach except 4 also needs to have the copy constructor construct a new 
G4DynamicParticle. (I suspect that Geant4 code never uses the copy constructor, 
so #2 might be best, forcing the user to deal with it when there is a 
G4VUserTrackInformation present.)

In my code, there never is a G4VUserTrackInformation, so that problem doesn't happen.

If I don't duplicate the G4Track, the program crashes badly, in strange ways unrelated to this code -- memory got corrupted via a dual delete of the G4Track itself.

If I do duplicate the G4Track (as above), it APPEARS to work correctly, but I think the double delete of G4DynamicParticle puts a short-circuit loop into its G4AllocatorPool free list, causing G4AllocatorPool to leak memory.

This is clearly very old code, and I am astounded this problem has not been noticed....

(Note: the above example is VERY simplified and unrealistic. My actual problem is with duplicating secondary tracks inside a G4WrapperProcess that wraps another physics process. The underlying issue is with G4Track, not my need to copy secondary G4Track-s from a G4ParticleChangeForLoss to a G4ParticleChange [each of which will delete the secondary G4Track-s they hold].)

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

1 None: Re: Double deletes in ~G4Track()   (Hisaya Kurashige - 18 Sep, 2012)
(_ None: Re: Double deletes in ~G4Track()   (Tom Roberts - 19 Sep, 2012)
 Add Message Add Message
to: "Double deletes in ~G4Track()"

 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 ]