bug#16986: Fw: Re: Crash when idle

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 15 May 2014 09:31:32 +0100, Simon Carter <bbbscarter@gmail.com> 
>>>>> said:

> 10 org.gnu.Emacs 0x00000001000d734a directory_files_internal + 742

> Dump of assembler code for function directory_files_internal:  

> 0x00000001000d732a <+710>: callq 0x1000f4365 <make_uninit_multibyte_string>
> 0x00000001000d732f <+715>: mov %rax,-0x48(%rbp)
> 0x00000001000d7333 <+719>: mov 0x17(%rax),%rdi
> 0x00000001000d7337 <+723>: mov -0x88(%rbp),%rax
> 0x00000001000d733e <+730>: mov (%rax),%rsi
> 0x00000001000d7341 <+733>: mov -0x70(%rbp),%rdx
> 0x00000001000d7345 <+737>: callq 0x1001a1b08
> 0x00000001000d734a <+742>: mov -0x8c(%rbp),%eax

The above callq corresponds to the call to memcpy below:

   276                memcpy (SDATA (fullname), SDATA (directory),
   277                        directory_nbytes);

The second argument is passed to memcpy via the register %rsi, which
is set to `(%rax)' at <+730>.  Note that this is done *without
displacement* (compare it with the instruction for the first argument
%rdi at <+719>).  That means the value of %rax at <+730> is
&XSTRING(directory)->data rather than `directory' itself, which seems
to be optimized out by the compiler possibly because SDATA(directory)
is used inside a loop and `directory' is not used later in the other
places.

As the following comment says, DECODE_FILE can GC in general:

   251        /* Note: DECODE_FILE can GC; it should protect its argument,
   252           though.  */
   253        name = DECODE_FILE (name);
   254        len = SBYTES (name);

And actually the NS port on Darwin uses a special `utf-8-nfd' file
coding system that involves Lisp evaluation via the
`:post-read-conversion' property.

I suspect there are no direct references to the value of `directory'
from stack contents or register values, and thus GC triggered by the
above DECODE_FILE has collected the value of `directory' as a garbage.
If that is the case, %rax at <+730> (i.e., &XSTRING(directory)->data)
would become invalid.

                                     YAMAMOTO Mitsuharu
                                mituharu@math.s.chiba-u.ac.jp