|Message: Re: Process size growing||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)|
Again I tried to reproduce the observed memory growth with the example application (extended/hadronic/Hadr01) using the run time setup described in the thread,
but failed to detect any noticeable symptom of direct memory leakage either in a visual monitoring (top) or in profiling with IgProf. Memory profiling results on a Linux system, AMD Opteron(tm) Processor 6136 were summarized at
- please see the MEM_LIVE DIFF(100001-1) for a direct memory leakage; anything
great than 100% under "Total %" indicate a direct memory leakage. The link also include the log file and the snapshot of the 'top' process of the application at the bottom of the page.
Since I have a similar conflicted result with the advanced/hadrontherapy example (assuming that the problem is not OS specific - Windows vs. Linux), it is now very difficult how to address this issue correctly. If we assume that reported problems (and my tests) are real, the problem may due to other facts (such as compiler, optimization flag and so forth). Before we investigate the issue further, it would be really nice if someone else can test these two applications (advanced/hadronherapy and extended/hadronic/Hadr01)independently and report behaviour of the memory comsumption in this thread.
|Inline Depth:||Outline Depth:||Add message:|