|Message: Re: Who's responsible for deletion of hits and hits collection objects?||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)|
Dear Asai-san and all others, > All HitsCollection objects and individual hits stored in them are > for sure deleted when G4Event is deleted at the very end of one event. > One potential source of memery leak is in your hit class which > instantiate something but does not delete it in the destructor of > your hit class. Thanks for the valuable information and your kindness to guide me. I'm glad to hear we can leave the task of Hits & HitsCollection deletion to the toolkit. Sad thing is, the exampleN0 as well as A01app, when run with hundreds of millions of events, too are always killed by oom-killer on my linux system (Fedora Core3, kernel 2.6.10-1.770_FC3, gcc-3.2.4, libstdc++-3.4.2), and I think something is wrong... (I'm interested in the response functions of detectors such as Ge and BGO to several-MeV gamma rays and high statistics is essential) `valgrind --tool=memcheck --leak-check=yes exampleN02` yields the following summary: ==6985== LEAK SUMMARY: ==6985== definitely lost: 800 bytes in 49 blocks. ==6985== possibly lost: 136097 bytes in 3201 blocks. ==6985== still reachable: 885777 bytes in 5833 blocks. ==6985== suppressed: 200 bytes in 1 blocks. (I'm not familier with the tool...) Yours, Kazuyoshi
|Inline Depth:||Outline Depth:||Add message:|