|
From: Roger B. <ro...@ro...> - 2012-12-29 06:45:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm running 3.8.1 on MacOS 10.7 with an Objective-C app compiled using ARC. I need to see where an object was allocated, not just where it was freed. An object is getting accessed after free in an autoreleasepool. However due to ARC pretty much everything is freed in an autoreleasepool so I can't tell where the item was actually allocated to further help diagnose. ==30881== Invalid read of size 8 ==30881== at 0x51FE8C: objc_msgSend (in /usr/lib/libobjc.A.dylib) ==30881== by 0x1000023B0: -[MiniPython setCode:error:] (MiniPython.m:241) ==30881== by 0x100014159: main (testMiniPython.m:96) ==30881== Address 0x10104b9e0 is 0 bytes inside a block of size 48 free'd ==30881== at 0xDCB8: free (vg_replace_malloc.c:450) ==30881== by 0x524D52: object_dispose (in /usr/lib/libobjc.A.dylib) ==30881== by 0x67E085: -[NSObject dealloc] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==30881== by 0x67E00D: -[__NSArrayM dealloc] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==30881== by 0x52503B: (anonymous namespace)::AutoreleasePoolPage::pop(void*) (in /usr/lib/libobjc.A.dylib) ==30881== by 0x1000023B0: -[MiniPython setCode:error:] (MiniPython.m:241) ==30881== by 0x100014159: main (testMiniPython.m:96) This is an NSMutableArray (or its contents) which I use many of all over the place. The diagnostic telling me where it was freed is nowhere near as helpful as it telling me where the allocation happened. I am running with --track-origins=yes --freelist-vol=1000000000 Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlDekXQACgkQmOOfHg372QT6dgCePGTcnr16ICl+a4ofG8qQ2UFJ /CMAoLU15AD11XKBk5BWzdgAJvB9puaD =flVn -----END PGP SIGNATURE----- |
|
From: Philippe W. <phi...@sk...> - 2012-12-31 12:40:45
|
On Fri, 2012-12-28 at 22:45 -0800, Roger Binns wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm running 3.8.1 on MacOS 10.7 with an Objective-C app compiled using > ARC. I need to see where an object was allocated, not just where it was > freed. > > An object is getting accessed after free in an autoreleasepool. However > due to ARC pretty much everything is freed in an autoreleasepool so I > can't tell where the item was actually allocated to further help diagnose. Currently, memcheck remembers only one stack trace per block. When a block is allocated, this stack trace is the allocation stack trace. When this block is freed, the alloc stack trace is replaced by the stack trace where the block is freed. I think (not tested) that the below trivial change will keep the alloc stack trace: In the function die_and_free_mem (in memcheck/mc_malloc_wrappers.c), just comment the line: /* Record where freed */ mc->where = VG_(record_ExeContext) ( tid, 0/*first_ip_delta*/ ); Then the "where" will continue to be the alloc stack trace. It might be a good idea to have a new memcheck option --keep-alloc-stacktrace=yes|no and/or to allow to (optionally) remember and report the alloc stack trace in addition to the "free" stack trace. This will however imply (for a 64 bits platform) 8 bytes more per allocated block. Philippe |
|
From: Roger B. <ro...@ro...> - 2012-12-31 20:17:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31/12/12 04:40, Philippe Waroquiers wrote: > I think (not tested) that the below trivial change will keep the alloc > stack trace: Tested and confirmed that it does (although the header printed says it was where freed). Thanks. > It might be a good idea to have a new memcheck option > --keep-alloc-stacktrace=yes|no and/or to allow to (optionally) remember > and report the alloc stack trace in addition to the "free" stack > trace. This will however imply (for a 64 bits platform) 8 bytes more > per allocated block. This option if present would have saved me hours of work. In the end I only found the problem through sheer guesswork and luck. I will gladly trade as much memory as it takes in order to improve my productivity/reduce debug time. (I even run with the freelist set to several gigabytes because that will catch program shutdown problems with memory cycled at the beginning of the program run.) What will it take to get this into valgrind proper and the ability to show both free and alloc stacks? Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlDh8usACgkQmOOfHg372QSt+ACgx8N64p2QUjTg/JqhGBHXdWR0 338AniCc86KQD/z/+X/NugtB+QQmt03b =JUzs -----END PGP SIGNATURE----- |
|
From: Philippe W. <phi...@sk...> - 2013-01-01 19:34:51
|
On Mon, 2012-12-31 at 12:17 -0800, Roger Binns wrote: > > It might be a good idea to have a new memcheck option > > --keep-alloc-stacktrace=yes|no and/or to allow to (optionally) remember > > and report the alloc stack trace in addition to the "free" stack > > trace. This will however imply (for a 64 bits platform) 8 bytes more > > per allocated block. > What will it take to get this into valgrind proper and the ability to show > both free and alloc stacks? I think it would not be very difficult. Not too clear if we just need the option: --keep-alloc-stacktrace=yes|no remember alloc stack trace for freed blocks [no] or if we better have something like: --keep-alloc-stacktrace=yes|until-freed|no [until-freed] --keep-free-stacktrace=yes|no [yes] or maybe --keep-stacktraces=alloc|free|alloc-and-free|alloc-else-free|none [alloc-else-free] (default values in [] brackets are backward compatible with current behaviour). Philippe |
|
From: Roger B. <ro...@ro...> - 2013-01-01 22:15:01
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/01/13 11:34, Philippe Waroquiers wrote: > --keep-stacktraces=alloc|free|alloc-and-free|alloc-else-free|none > [alloc-else-free] Something like this would make most sense and is future proof if you allow a comma separated list eg --keep-stacktraces=alloc,free I could see future functionality such as wanting to mark when memory was last written to or last read etc so you could have additional stacktraces like lastread,lastwritten. Others could include threading markers. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlDjX8sACgkQmOOfHg372QSaWwCdFfc83PwpfjquIdAyIvh8Jh4t 9QoAoJJhXcgokm3oekBG8yQs7V/OLpSi =J9zd -----END PGP SIGNATURE----- |
|
From: Philippe W. <phi...@sk...> - 2013-01-08 22:11:22
|
> > On 01/01/13 11:34, Philippe Waroquiers wrote: > > > --keep-stacktraces=alloc|free|alloc-and-free|alloc-else-free|none > > > [alloc-else-free] A patch implementing the above idea has been attached to https://bugs.kde.org/show_bug.cgi?id=312913 Waiting for review and/or feedback Philippe |
|
From: Philippe W. <phi...@sk...> - 2013-01-12 19:56:22
|
On Tue, 2013-01-08 at 23:11 +0100, Philippe Waroquiers wrote: > > > On 01/01/13 11:34, Philippe Waroquiers wrote: > > > > --keep-stacktraces=alloc|free|alloc-and-free|alloc-else-free|none > > > > [alloc-else-free] > > A patch implementing the above idea has been attached to > https://bugs.kde.org/show_bug.cgi?id=312913 > > Waiting for review and/or feedback Committed in revision 13223, providing --keep-stacktraces=alloc|free| alloc-and-free|alloc-then-free|none |