Re: allocate_string_data memory corruption

[Ken Raeburn]

On Jan 18, 2006, at 11:57, Chong Yidong wrote:
> There's been some progress tracking down the hyperthreading /
> allocate_string related crash.  We can now reproduce a crash reliably.

That's good news... sort of... :-)

> In this function, data->string is set to s, and nbytes is set to
> nbytes.  If check_sblock is a no-op, there should be no change.

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?  I don't know if you're fluent in x86  
assembly, but I'd check to see if the function's code differs between  
the two cases.

If it doesn't, I think the next thing I'd try would be a watchpoint  
under gdb to see what happens during check_sblock.  If you need to  
run some unpredictable large number of invocations of the function to  
trigger the problem, commands can be run at a breakpoint to enable  
the watchpoint right before the first check, and disable it after the  
second.  You can use convenience variables to store copies of s,  
data, etc.

If the assembly code does differ, I'd inspect the failing version  
more carefully.  And maybe try to tweak the source or build options  
such that check_sblock doesn't influence how allocate_string_data is  
compiled.

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?

>   #1  0x0817499e in allocate_string_data (s=0x8d18778, nchars=8,
>         nbytes=8) at alloc.c:2013
>
>       s            == (struct Lisp_String *) 0x8d18778
>       data->string == (struct Lisp_String *) 0x8d18788 <-- off by 16
>
>       nbytes       == 8
>       data->nbytes == 200                              <-- off by 192
>
>       nchars == 8
>       needed == 20

And you've checked, for example, that data hasn't changed, that s and  
nchars still accurately reflect what the caller passed in, etc?   
Sometimes gdb can get confused if the compiler is too clever.

My Red Hat system at work has hyperthreading in its cpu, perhaps I  
could help if you've got a portable test case setup?

Ken