Opened 10 years ago
Closed 9 years ago
#623 closed defect (wontfix)
Fix memory leaks
| Reported by: | kilian | Owned by: | kilian |
|---|---|---|---|
| Priority: | P5 | Milestone: | v2.2.6 |
| Component: | core | Version: | 2.2.0beta |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Run nagfor -mtrace on the test suite and try to fix all o'them.
Leaks that do not occur in frequent loops are harmless, so this is not high priority.
Change History (13)
comment:1 Changed 10 years ago by
| Priority: | P4 → P1 |
|---|
comment:2 Changed 10 years ago by
| Status: | new → assigned |
|---|
comment:3 Changed 10 years ago by
comment:4 Changed 10 years ago by
| Priority: | P1 → P5 |
|---|
Some more leaks fixed (r5788).
So far, I checked some exemplary use cases, in particular smtest_1. The leaks that I found are fixed, some of them may have had an impact (see above). There are lots of reported leaks remaining. It appears that most, if not all of them are due to a NAG Fortran bug, connected to the deallocation of allocatable strings in function results. I will postpone further investigation until this has been fixed. I submitted the bug report to NAG. I expect that it won't take long to fix it; nevertheless this will be likely after the release.
We should make this automatic, upon request. Note that the files generated are almost GB in size, for each test, so they have to be either compressed or deleted.
In short, postponing.
comment:5 Changed 10 years ago by
| Milestone: | v2.2.0 → v2.2.1 |
|---|
JRR & WK d'accord: postpone to 2.2.X. (2.2.2 for now)
comment:6 Changed 10 years ago by
The C pointers from LHAPDF6 are not (yet) deleted. This (very small) memory leak has to be fixed some day. I add this here in order to be able to close the LHAPDF6 ticket soon-ish.
comment:7 Changed 10 years ago by
| Milestone: | v2.2.2 → v2.2.3 |
|---|
comment:9 Changed 10 years ago by
| Milestone: | v2.2.3 → v2.2.4 |
|---|
comment:11 Changed 10 years ago by
There are very likely still memory leaks, although none of them bites us, hopefully. Recently, I fixed some associated with the scan command, but I couldn't catch everything. The problem is that finding leaks is time-consuming.
Upshot: keep the ticket as a reminder.
comment:12 Changed 9 years ago by
| Milestone: | v2.2.5 → v2.2.6 |
|---|
comment:13 Changed 9 years ago by
| Resolution: | → wontfix |
|---|---|
| Status: | assigned → closed |
Not relevant at the moment.
Yes, I'm doing this right now as far as time allows.
So far, I have fixed a major (but harmless) leak: the parse tree which is built when a model is read from file was lost in Nirwana.
On top of that, there are tons of strings allocated while reading from a parse tree, which are reported as leaks. This should not happen, and is likely a bug in the NAG Fortran library (or in the memory tracer). I have isolated the issue and will file a bug report to NAG.