On Tue, Feb 24, 2009 at 10:03:22PM +0100, Roland Mainz wrote:
> Edward Pilatowicz wrote:
> > On Wed, Feb 18, 2009 at 06:43:33AM +0100, Roland Mainz wrote:
> > > Edward Pilatowicz wrote:
> [snip]
> > fyi, libumem (with the environment settings described in the bug report)
> > will write the 0xdeadbeef pattern to free'd memory. this helps catch
> > applications that try to access free'd memory.
> >
> > looking at the bug report, i see there was some internal analysis done.
> > i've attached that analysis to this email. it seems that we are passing
> > around 0xdeadbeef pointers...
> >
> > ed
> >
> > ------------------------------------------------------------------------
> >
> > eval.txtName: eval.txt
> > Type: Plain Text (text/plain)
>
> Erm... the attachment seems to be empty (the attachment size of the MIME
> stream is "0")
>
hm. sorry about that, i'm not sure what happened.
i'll just include the partial analysis here:
---8<---
[dep, 13Feb2009]
This looks like a ld.so.1 bug. We fail an assertion in scribble:
86 static void
87 scribble(ulong_t *membgn, int pattern, size_t size)
88 {
89 size_t memsize = size / sizeof (ulong_t);
90
91 while (memsize--) {
92 if (pattern == FREMEM)
93 ASSERT(*membgn != patterns[pattern]);
94 *membgn++ = patterns[pattern];
95 }
96 }
which is asserting when we free a buffer that the buffer doesn't
already contain the freed-buffer pattern. Perhaps the author thought
this would detect double-frees, but it assumes that the consumers of
the buffer would never put 0xdeadbeef in it.
[rie, 14Feb2009]
There's a handshake where libc informs ld.so.1 that the locale has been
changed. ld.so.1 uses the new locale to makes sure it's error messaages
are printed as expected.
ld.so.1 first established the locale from the environment. In this case
we've found en_US.ISO8859-1, and maintain this in a duplicated string.
libc then tells us the locale is en_US.ISO8859-1. We skip any work here
recognizing that the locale is no different.
libc then tells us the locale is C. We free the original locale string
and duplicate the new string.
libc then tells us the local is a "0xdeadbeef". We free the original locale
string and duplicate the new string.
libc then tells us the locale is C. We free the original locale string
but fall into our debugging code that checks for 0xdeadbeef".
No, we don't check that users pass us "0xdeadbeef" strings. The checking is
only carried out in the debugging version of ld.so.1.
It seems odd the ksh is calling is over and over again to set the locale,
and even more odd that it's passing us, what looks like, a pointer to freed
memory.
---8<---
