From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: Simon Carter <bbbscarter@gmail.com>
Cc: 16986@debbugs.gnu.org
Subject: bug#16986: Fw: Re: Crash when idle
Date: Wed, 23 Jul 2014 19:09:50 +0900 [thread overview]
Message-ID: <wl38dsqtch.wl%mituharu@math.s.chiba-u.ac.jp> (raw)
In-Reply-To: <etPan.53747b64.507ed7ab.6376@scarter-mac.europe.corp.microsoft.com>
>>>>> 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
next prev parent reply other threads:[~2014-07-23 10:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-11 11:33 bug#16986: Crash when idle Simon Carter
2014-03-26 5:53 ` Paul Eggert
2014-03-27 16:54 ` bug#16986: Fw: " Simon Carter
2014-03-27 17:00 ` Simon Carter
2014-03-27 18:17 ` Paul Eggert
2014-04-24 21:12 ` Simon Carter
2014-05-15 8:31 ` Simon Carter
2014-07-23 10:09 ` YAMAMOTO Mitsuharu [this message]
2014-08-01 8:17 ` Dmitry Antipov
2014-08-02 23:11 ` bug#16986: " Paul Eggert
2014-08-11 1:21 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=wl38dsqtch.wl%mituharu@math.s.chiba-u.ac.jp \
--to=mituharu@math.s.chiba-u.ac.jp \
--cc=16986@debbugs.gnu.org \
--cc=bbbscarter@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).