BTW, for those only seeing this on the external list, the "Evaluation"
section of the bug report has more of an explanation - unfortunately,
that section is censored from externally sent e-mails at the moment,
since many existing evaluations contain non-public information, such
as details of encumbered code.   This one however, seems clean enough
to release:

Entry 1 [2009-02-14 02:43]:
---------------------------
 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.

Entry 2 [2009-02-14 17:51]:
---------------------------

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 locale 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.


-- 
        -Alan Coopersmith-           alan.coopersmith at sun.com
         Sun Microsystems, Inc. - X Window System Engineering

Reply via email to