#2991 closed Bugs (duplicate)
Broadcast of bool leaks memory
| Reported by: | Owned by: | Douglas Gregor | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | mpi |
| Version: | Boost Development Trunk | Severity: | Cosmetic |
| Keywords: | mpi broadcast bool bug leak | Cc: | Matthias Troyer |
Description
Good morning.
Running valgrind on the attached test program, reveals that broadcasting a single boolean variable leaks memory. The new created data-type is not freed after its usage (and this causes the leak).
Demonstration: if you try to re-build the attached test program with -DLEAK_WORKAROUND, and then run it under valgrind again, the leak is disappeared.
May you fix this bug, please ?
Best regards.
Michele De Stefano
Attachments (1)
Change History (5)
by , 13 years ago
| Attachment: | bool_bcast.cpp added |
|---|
follow-up: 2 comment:1 by , 13 years ago
| Resolution: | → duplicate |
|---|---|
| Severity: | Problem → Cosmetic |
| Status: | new → closed |
| Version: | Boost 1.38.0 → Boost Development Trunk |
This is a duplicate of #2594. It is a cosmetic issue that comes up with valgrind but has no other impact.
comment:2 by , 13 years ago
| Resolution: | duplicate |
|---|---|
| Status: | closed → reopened |
Replying to troyer:
This is a duplicate of #2594. It is a cosmetic issue that comes up with valgrind but has no other impact.
Excuse me, but ticket #2594 shows something totally different ... please, read carefully my comments for that ticket (the problem for that ticket is absolutely not cosmetic and this ticket is not a duplicate of that one ... for ticket #2594, if you don't fix the bug the code does not get built at all, because you receive an error from the compiler).
For this ticket, I repeat, if you free the new data type, no leak is generated (please, look at the example code I sent). I don't think this is cosmetic: who does free the new data type if you never call MPI_Type_free ?
follow-up: 4 comment:3 by , 13 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | reopened → closed |
Sorry, I meant 2586. This is cosmetic since the memory would be released by a destructor call of a static member variable. This destructor would only called at the end of the program execution anyway, and the leak thus has no effect besides being detected by valgrind. Hence I call it cosmetic.
comment:4 by , 13 years ago
Replying to anonymous:
Sorry, I meant 2586. This is cosmetic since the memory would be released by a destructor call of a static member variable. This destructor would only called at the end of the program execution anyway, and the leak thus has no effect besides being detected by valgrind. Hence I call it cosmetic.
Ok. Clear.
Thank you very much.
Test program that demonstrates the bug and its possible solution