Bug 371770

Summary:	Memleak trace back for overwritten or freed memory pointers
Product:	[Developer tools] valgrind	Reporter:	Joe Veazey <joe.veazey>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	philippe.waroquiers
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	attachment-9537-0.html

Description Joe Veazey 2016-10-27 22:11:26 UTC

Would it be possible to have an option in valgrind memleak that could track when allocated memory was actually leaked?

Since all pointers to active allocated memory are tracked by valgrind, when the pointer to a piece of active allocated memory gets overwritten or freed (the pointer, not the memory), that is the moment when the memory leak occurs.

So, if valgrind/memleak could at that moment generate an appropriate error message showing exactly where the pointer got overwritten or freed, that would speed up fixing the problem tremendously.

I realize this could be very significant overhead, so this enhanced leak tracking should be selectable via an option flag.

In a test environment, even several hours of run time for a leaky program followed by a quick fix, would be much better than a couple of days of programmer data flow analysis and a possibly ineffective fix or new bug.

Comment 1 Philippe Waroquiers 2016-10-31 21:42:30 UTC

Equivalent request have already been done see e.g. bug 74899.

There was even at a moment an experimental tool called omega doing this.
The tool was however never considered working reasonably well, as it is
difficult to detect exactly when the last pointer disappears (IIRC e.g. because
copies of 'dead pointers' can be kept in registers or similar).

We will keep 74899 as the place holder for this enhancement request (in case
someone one day works again on the omega tool or equivalent).

In the meantime, the alternative is to search the most probable last pointer
or last scope having a pointer by doing leak search at regular intervals e.g.
using a client request or by using gdb+vgdb and breakpoints.

Comment 2 Philippe Waroquiers 2016-10-31 21:42:58 UTC


*** This bug has been marked as a duplicate of bug 74899 ***

Comment 3 Joe Veazey 2016-10-31 21:45:17 UTC

Created attachment 101931 [details]
attachment-9537-0.html

I will investigate your suggestions. gdb+vgdb w/breakpoints sounds the most
feasible for my task.

Thanks for the reply!

*Joe.Veazey@ipdatatel.com <Joe.Veazey@ipdatatel.com>*
Cell: 281-543-8330

On Mon, Oct 31, 2016 at 4:42 PM, Philippe Waroquiers <
bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=371770
>
> Philippe Waroquiers <philippe.waroquiers@skynet.be> changed:
>
>            What    |Removed                     |Added
> ------------------------------------------------------------
> ----------------
>                  CC|
> |philippe.waroquiers@skynet.
>                    |                            |be
>
> --- Comment #1 from Philippe Waroquiers <philippe.waroquiers@skynet.be>
> ---
> Equivalent request have already been done see e.g. bug 74899.
>
> There was even at a moment an experimental tool called omega doing this.
> The tool was however never considered working reasonably well, as it is
> difficult to detect exactly when the last pointer disappears (IIRC e.g.
> because
> copies of 'dead pointers' can be kept in registers or similar).
>
> We will keep 74899 as the place holder for this enhancement request (in
> case
> someone one day works again on the omega tool or equivalent).
>
> In the meantime, the alternative is to search the most probable last
> pointer
> or last scope having a pointer by doing leak search at regular intervals
> e.g.
> using a client request or by using gdb+vgdb and breakpoints.
>
> --
> You are receiving this mail because:
> You reported the bug.