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
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.
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.).
It seems this will not be merged because it enlarges the struct _AddrInfo, of which quite a few are allocated at runtime.
(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
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