From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: 64-bit emacs crashes a lot
Date: Fri, 16 Aug 2013 07:39:40 -0400 [thread overview]
Message-ID: <520E0F7C.6000608@cs.utoronto.ca> (raw)
In-Reply-To: <8338qangma.fsf@gnu.org>
On 16/08/2013 5:13 AM, Eli Zaretskii wrote:
> Please move this discussion to emacs-devel@gnu.org.
OK. For history's sake, here's the link back to the cygwin thread:
http://cygwin.com/ml/cygwin/2013-08/msg00275.html
>> Date: Fri, 16 Aug 2013 01:59:41 -0400
>> From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
>>
>> The variable pending_exact has value 0x0, which would be a Bad Thing...
>> except that the code looks like this:
>>> if (!pending_exact
>>>
>>> /* If last exactn not at current position. */
>>> => || pending_exact + *pending_exact + 1 != b
>>>
>> ... with corresponding assembly code looking very reasonable:
>>> 0x0000000100535cfa <regex_compile+34482>: cmpq $0x0,0x3f8(%rbp)
>>> 0x0000000100535d02 <regex_compile+34490>: je 0x100535eca
>>> <regex_compile+34946>
>>> 0x0000000100535d08 <regex_compile+34496>: mov 0x3f8(%rbp),%rax
>>> => 0x0000000100535d0f <regex_compile+34503>: movzbl (%rax),%eax
>>> 0x0000000100535d12 <regex_compile+34506>: movzbl %al,%eax
>>> 0x0000000100535d15 <regex_compile+34509>: lea 0x1(%rax),%rdx
>>> 0x0000000100535d19 <regex_compile+34513>: mov 0x3f8(%rbp),%rax
>>> 0x0000000100535d20 <regex_compile+34520>: add %rdx,%rax
>>> 0x0000000100535d23 <regex_compile+34523>: cmp %rbx,%rax
>>> 0x0000000100535d26 <regex_compile+34526>: jne 0x100535eca
>>> <regex_compile+34946>
> What is the value in the RAX register at the point of the crash? Is
> it also zero? Or maybe it is some other invalid pointer value?
Also zero, iirc
I tested it before, but my computer seems to have rebooted itself in the
night and the history was lost. Unfortunately, I'm having trouble
getting the debug emacs-nox to crash this morning. The -Og and -O2
builds crash even more often than before, though, usually while trying
to invoke compile for the first time; the stack traces have been total
garbage. I'll have to get back to you when the bug is being more
cooperative...
>> A third crash:
>>> #1 0x0000000100541930 in re_match_2_internal (bufp=0x10095ce20
>>> <searchbufs+2912>, string1=0x0, size1=0, string2=0x6fffff00028 "-*-
>>> mode: compilation; default-directory: \"~/\" -*-\nCompilation started
>>> at Fri Aug 16 01:32:19\n\nls\n#message-20130808-090732#\t
>>> emacs-crash.txt\t\tmusic\n6b8ob06a.default.tar.xz\t\t
>>> emacs-nox.exe."..., size2=355, pos=254, regs=0x10095def0
>>> <search_regs>, stop=317) at regex.c:6217
>>> 6217 abort ();
>> This time, p (the subject of the case statement) points to 0x76b3b6c7,
>> which is the middle of a function (ntdll!RtlFillMemory, though the
>> memory map places that address smack in the middle of kernel32.dll
>> instead). This time it makes perfect sense that the switch statement
>> should fail, but how did p go so wrong?
> What is bufp->buffer at this point, and what is its contents?
I'll let you know once I hit the crash again...
Ryan
next prev parent reply other threads:[~2013-08-16 11:39 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51F3151D.7040000@cs.utoronto.ca>
[not found] ` <51F33565.1090406@cornell.edu>
[not found] ` <51F33F52.4060405@cs.utoronto.ca>
[not found] ` <51FB1D9E.5090102@cs.utoronto.ca>
[not found] ` <20130802080211.GA18054@calimero.vinschen.de>
[not found] ` <51FB9228.2020309@cornell.edu>
[not found] ` <51FBA100.90005@cs.utoronto.ca>
[not found] ` <51FD5462.5020400@cs.utoronto.ca>
[not found] ` <51FFBDFF.7040501@cornell.edu>
[not found] ` <51FFC4F2.8080909@cs.utoronto.ca>
[not found] ` <5203D89E.6030801@cornell.edu>
[not found] ` <5203DCCA.1010105@cs.utoronto.ca>
[not found] ` <5205B364.8090007@cs.utoronto.ca>
[not found] ` <52064730.50404@cornell.edu>
[not found] ` <"52065B3C.6060104@cs.utoronto <520CCA41.3000107"@cs.utoronto.ca>
[not found] ` <520D089A.1020806@cornell.edu>
[not found] ` <83ioz6op5v.fsf@gnu.org>
[not found] ` <520D4036.8010303@cs.utoronto.ca>
[not found] ` <8361v6nhdb.fsf@gnu.org>
2013-08-16 11:37 ` 64-bit emacs crashes a lot Ryan Johnson
2013-08-16 13:10 ` Eli Zaretskii
[not found] ` <520D900A.8000907@cornell.edu>
[not found] ` <520DABDC.8020304@cs.utoronto.ca>
[not found] ` <520DBFCD.4080808@cs.utoronto.ca>
[not found] ` <8338qangma.fsf@gnu.org>
2013-08-16 11:39 ` Ryan Johnson [this message]
[not found] ` <834naqnh9t.fsf@gnu.org>
2013-08-16 11:41 ` Ryan Johnson
2013-08-16 13:31 ` Eli Zaretskii
2013-08-16 14:16 ` Ryan Johnson
2013-08-16 14:49 ` Eli Zaretskii
2013-08-16 14:20 ` Ken Brown
2013-08-16 14:24 ` Ryan Johnson
2013-08-16 15:03 ` Eli Zaretskii
2013-08-16 15:45 ` Eli Zaretskii
2013-08-16 16:51 ` Ryan Johnson
2013-08-16 17:46 ` Ken Brown
[not found] ` <520E5D71.3020307@cornell.edu>
2013-08-16 17:24 ` Ryan Johnson
2013-08-16 18:55 ` Ken Brown
2013-08-16 19:37 ` Eli Zaretskii
2013-08-16 20:17 ` Eli Zaretskii
2013-08-16 20:33 ` Ken Brown
2013-08-16 21:20 ` Ryan Johnson
2013-08-17 7:01 ` Eli Zaretskii
2013-08-17 12:17 ` Ken Brown
2013-08-17 19:43 Angelo Graziosi
2013-08-17 20:16 ` Ken Brown
2013-08-17 22:23 ` Angelo Graziosi
2013-08-18 17:43 ` Ken Brown
2013-08-18 19:10 ` Angelo Graziosi
2013-08-18 19:14 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520E0F7C.6000608@cs.utoronto.ca \
--to=ryan.johnson@cs.utoronto.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.