Bug 322256

Summary:	Provide more callstacks on memory pool related errors
Product:	[Developer tools] valgrind	Reporter:	Matthias Schwarzott <zzam>
Component:	memcheck	Assignee:	Julian Seward <jseward>
Status:	REPORTED ---
Severity:	normal	CC:	8e3b3cde, lange, philippe.waroquiers, pjfloyd, tilkax
Priority:	NOR
Version First Reported In:	3.9.0.SVN
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Show callstacks of rellocated block in mempool Show callstacks of reallocated block in mempool

Description Matthias Schwarzott 2013-07-11 19:37:11 UTC

An error related to a memory pool currently could have two callstacks:

==26295== Invalid read of size 1
==26295==    at 0x8048780: main (clireq_nofill.c:23)
==26295==  Address 0x4034028 is 0 bytes inside a recently re-allocated block of size 40 alloc'd
==26295==    at 0x4009D98: malloc (vg_replace_malloc.c:270)
==26295==    by 0x804860E: main (clireq_nofill.c:16)
==26295== 

But as the code that sets the message "inside a recently re-allocated block" suggests it knows about another block that has two callstacks, so the message could be enhanced to:

==26693==    at 0x8048780: main (clireq_nofill.c:23)
==26693==  Address 0x4034028 is 0 bytes inside a recently re-allocated block of size 40 alloc'd
==26693==    at 0x40093A1: malloc (vg_replace_malloc.c:291)
==26693==    by 0x804860E: main (clireq_nofill.c:16)
==26693==   inner block was freed at
==26693==    at 0x804876B: main (clireq_nofill.c:22)
==26693==   inner block was allocated at
==26693==    at 0x80486E0: main (clireq_nofill.c:20)

The attached patch does exactly this.


Reproducible: Always

Comment 1 Matthias Schwarzott 2013-07-11 19:38:53 UTC

Created attachment 81065 [details]
Show callstacks of rellocated block in mempool

Show two more callstacks for reallocated in mempool case.
Run the testcase cli_req also with --keep-stacktraces=alloc-and-free
Only filter_stderr does delete a bit too much of the callstacks so this should be fixed.

Comment 2 Matthias Schwarzott 2014-05-27 08:32:01 UTC

Created attachment 86853 [details]
Show callstacks of reallocated block in mempool

Updated the patch after the refactoring of rev 13965.

Maybe even more info could be extracted (offset+size of the inner block etc.).

Comment 3 Matthias Schwarzott 2014-07-22 06:25:39 UTC

It seems this will not be merged because it enlarges the struct _AddrInfo, of which quite a few are allocated at runtime.

Comment 4 Philippe Waroquiers 2014-07-22 22:25:15 UTC

(In reply to Matthias Schwarzott from comment #3)
> It seems this will not be merged because it enlarges the struct _AddrInfo,
> of which quite a few are allocated at runtime.

Sorry, info given on irc yesterday was for another patch.
Growing (reasonably) struct _AddrInfo is not a problem, as we have
very few of these.
It is struct _MC_Chunk which is more memory critical.

So, it is not hopeless to have this merged.

Philippe

Comment 5 lange 2015-06-10 08:53:26 UTC

I ran into this issue, and the message "bytes inside a recently re-allocated block of size alloc'd" is rather puzzling.
This patch helped me tracking the issue behind it and I would like this to be merged, as this is really required to track issues when using custom mempools