|Message: Re: Double delete in G4CrossSectionDataSetRegistry?||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 Wed, 03 Nov 2010 18:04:03 GMT, Matthew Blackston wrote:
> I'm getting a similar error. I'm using > > Geant4 version Name: geant4-09-03-patch-01 (9-April-2010) > > The error is: > > dualImager(90997) malloc: *** error for object 0x109953460: pointer > being freed was not allocated > *** set a breakpoint in malloc_error_break to debug > > When I use gdb and set the malloc_error_break, I get the following > backtrace: > > (gdb) backtrace > #0 0x00007fff887a9491 in malloc_error_break () > #1 0x00007fff886d3603 in free () > #2 0x00000001013f5de1 in > G4ElectroNuclearCrossSection::~G4ElectroNuclearCrossSection(this=0x109953460) > at src/G4ElectroNuclearCrossSection.cc:80 > #3 0x00000001013ef67b in G4CrossSectionDataSetRegistry::Clean > (this=0x102314d90) at src/G4CrossSectionDataSetRegistry.cc:72 > #4 0x00000001013ef71c in > G4CrossSectionDataSetRegistry::~G4CrossSectionDataSetRegistry > (this=0x102314d90) at src/G4CrossSectionDataSetRegistry.cc:61 > #5 0x00000001013ef774 in __tcf_0 () at > src/G4CrossSectionDataSetRegistry.cc:50 > #6 0x00007fff886df7f4 in __cxa_finalize () > #7 0x00007fff886df70c in exit () > #8 0x0000000100002153 in start () at G4ReferenceCountedHandle.hh:315
Hi, Matthew. Could you run in GDB and set two breakpoints?
Then run your job. If you capture the |where| traceback each time it stops, it should isolate exact where the double-delete originates. It's not in the Registry::Clean() call, as that explicitly sets the pointers stored in the vector to zero, even before clearing the vector (so any cached reference will see the null pointer).
|Inline Depth:||Outline Depth:||Add message:|