Re: allocate_string_data memory corruption

[Chong Yidong <cyd@stupidchicken.com>]

Ken Raeburn <raeburn@raeburn.org> writes:

> By "no-op", do you mean, for example, a macro or previously-defined
> empty function, such that the compiler will produce different code
> for allocate_string_data?

Sorry, that was the wrong phrase to use.  I meant that check_sblock
only scans the values in current_sblock, and aborts if they are
illegal -- it does not write into the heap at any point.

> Is this consistent across OSes?  E.g., Linux and *BSD or Solaris?
> How about compiler versions?  Could be a subtle OS bug in task
> switching or something.  Anything interesting going on with signal
> handlers at the time?

The user is running SuSE 9.1.  He has a certain Emacs Lisp setup that
he can use to crash Emacs reproducibly, when hyperthreading is turned
on.  Without hyperthreading, he has gotten one or two strange bus
errors, but these seem to be difficult to reproduce, and we're not
sure if they are real.

His Emacs Lisp setup seems to be pretty idiosyncratic.  He said before
that he didn't know how to whittle it down into a small test case, but
I can ask him again.