|
From: Julian S. <js...@ac...> - 2005-12-02 23:53:18
|
I was playing around in m_redir.c and wondering about how to know
what to free when, when it occurred to me we could do an old trick
that many do (including OOo 2.0) which is to fill up freed areas
with a bad value (traditionally 0xAA since AAAAAAAA is the sound of
a (32-bit) program dying, I'm told). This then catches some reads
of freed memory. So I added this to m_mallocfree.c:
===================================================================
--- coregrind/m_mallocfree.c (revision 5272)
+++ coregrind/m_mallocfree.c (working copy)
@@ -1070,6 +1070,13 @@
a->bytes_on_loan -= b_pszB;
+ if (aid != VG_AR_CLIENT) {
+ Int i;
+ UChar* p = (UChar*)ptr;
+ for (i = 0; i < b_pszB; i++)
+ p[i] = 0xAA;
+ }
+
// Put this chunk back on a list somewhere.
b_listno = pszB_to_listNo(b_pszB);
mkFreeBlock( a, b, b_bszB, b_listno );
and hey presto:
sewardj@suse10:~/VgTRUNK/trunk$ ./Inst/bin/valgrind ./memcheck/tests/mempool
[.. gets halfway through ..]
--17776-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--17776-- si_code=1; Faulting address: 0xAAAAAAA2; sp: 0x622B3E50
valgrind: the 'impossible' happened:
Killed by fatal signal
==17776== at 0xB0016D0F: vgPlain_arena_free (m_mallocfree.c:181)
==17776== by 0xB00176CD: vgPlain_free (m_mallocfree.c:1378)
==17776== by 0xB000DDDB: vgPlain_HT_destruct (m_hashtable.c:242)
==17776== by 0xB000183E: vgMAC_destroy_mempool (mac_malloc_wrappers.c:458)
==17776== by 0xB0006F4E: vgMAC_handle_common_client_requests
(mac_shared.c:1018)
==17776== by 0xB0003D75: mc_handle_client_request (mc_main.c:2501)
Check it out! 0xAAAAAAA2.
I'm also contemplating enabling this (line 1061)
# ifdef DEBUG_MALLOC
vg_assert(blockSane(a, b));
# endif
for non-client frees, in the hope of discovering blocks which V has
overrun the ends, at free-time.
If this doesn't cause noticable slowdowns, do you thing it would be a
safe thing to commit?
J
|
|
From: Tom H. <to...@co...> - 2005-12-03 00:00:17
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> I was playing around in m_redir.c and wondering about how to know
> what to free when, when it occurred to me we could do an old trick
> that many do (including OOo 2.0) which is to fill up freed areas
> with a bad value (traditionally 0xAA since AAAAAAAA is the sound of
> a (32-bit) program dying, I'm told). This then catches some reads
> of freed memory. So I added this to m_mallocfree.c:
I thought 0xDEADBEEF was the traditional value... That's an IBM
thing I think.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-12-04 19:20:56
|
On Fri, 2 Dec 2005, Julian Seward wrote: > Check it out! 0xAAAAAAA2. > > I'm also contemplating enabling this (line 1061) > > # ifdef DEBUG_MALLOC > vg_assert(blockSane(a, b)); > # endif > > for non-client frees, in the hope of discovering blocks which V has > overrun the ends, at free-time. > > If this doesn't cause noticable slowdowns, do you thing it would be a > safe thing to commit? Sounds good to me. Only thing is that you should use a different value to 0xAAAAAAAA because the COMPVBITS branch uses 10b for each "readable" byte, which becomes 0xAAAA... across multiple bytes. How about 0xCCCCCCCC? Nick |
|
From: Julian S. <js...@ac...> - 2005-12-04 19:43:29
|
> Sounds good to me. Only thing is that you should use a different value to > 0xAAAAAAAA because the COMPVBITS branch uses 10b for each "readable" byte, > which becomes 0xAAAA... across multiple bytes. How about 0xCCCCCCCC? Could COMPVBITS could change to use 00b for "readable"? That might save a comparison instruction in the helper fns on x86/amd64. Nevertheless - 0xCC is 4-aligned. 0xDDDDDDDD might be better; it's in kernel-space for the most part, and even if not, is 1 % 4, so will cause sigbus if dereferenced on ppc. (Hmm. Does ppc trap on misaligned loads/stores? I dunno). J |
|
From: Nicholas N. <nj...@cs...> - 2005-12-04 20:01:55
|
On Sun, 4 Dec 2005, Julian Seward wrote: > Could COMPVBITS could change to use 00b for "readable"? That might > save a comparison instruction in the helper fns on x86/amd64. It could. I like having 0x00 mean "unaddressable" as is done now, because it seems like 0 is the most likely accidental value and so bugs will cause memory to be marked as unaddressable and thus likely to be found first? Maybe it's not important. Either way, the values of note for COMPVBITS are 0x0000, 0x5555, 0xaaaa and 0xffff -- they're what you get when you concatenate 00b, 01b, 10b, 11b. > Nevertheless - 0xCC is 4-aligned. 0xDDDDDDDD might be better; it's > in kernel-space for the most part, and even if not, is 1 % 4, so will > cause sigbus if dereferenced on ppc. Ok, 0xDDDD sounds fine. Nick |
|
From: Paul M. <pa...@sa...> - 2005-12-04 22:04:41
|
Julian Seward writes: > cause sigbus if dereferenced on ppc. (Hmm. Does ppc trap on > misaligned loads/stores? I dunno). No, PowerPC processors typically handle almost all unaligned loads and stores in hardware, and the kernel fixes up the rest. (That doesn't apply to the load-and-reserve/store-conditional instructions used for atomic operations, though.) Paul. |