Re: Emacs 25 hangs on windows arbitrarily during search of a unicode file

[C K Kashyap]

Okay, I've narrowed it down.

If I just open the attached file (it's a unicode file) and do nothing but
C-g C-s a few times quickly, I run into the hang.

I'd appreciate it very much if someone could let me know how I could avoid
this hang or dig out more information.

Regards,
Kashyap

On Wed, Oct 18, 2017 at 11:24 AM, C K Kashyap <ckka...@gmail.com> wrote:

> Hi,
> I noticed that my emacs 25 hangs every time I try to do searches in quick
> successions in a json file (quite small file - about 20 lines). I cant do
> anything but kill emacs at this point.
> Has anyone else seen this? How can I debug this situation and get more
> information?
> Regards,
> Kashyap
>

[Eli Zaretskii]

> From: C K Kashyap <ckka...@gmail.com>
> Date: Wed, 18 Oct 2017 18:18:20 -0700

>
> If I just open the attached file (it's a unicode file) and do nothing but
> C-g C-s a few times quickly, I run into the hang.
>
> I'd appreciate it very much if someone could let me know how I could avoid
> this hang or dig out more information.

I can see it in Emacs 25.2, but not in the pretest of what will become
Emacs 26.1. So one thing you could do is install that pretest, it's
available from alpha.gnu.org.

[seagl...@gmail.com]

I perfer rg on Windows to search with emacs. Try it.
Best Regards,
Vincent Zhang

-------- 原始邮件 --------
主题：Re: Emacs 25 hangs on windows arbitrarily during search of a
unicode
file
�件人：C K Kashyap
收件人：help-gn...@gnu.org
抄�：

Okay, I've narrowed it down.

If I just open the attached file (it's a unicode file) and do
nothing but
C-g C-s a few times quickly, I run into the hang.
I'd appreciate it very much if someone could let me know how I could
avoid
this hang or dig out more information.

Regards,
Kashyap

[Eli Zaretskii]

> From: Richard Copley <rco...@gmail.com>
> Date: Sat, 28 Oct 2017 12:05:28 +0100
> Cc: "help-gn...@gnu.org" <help-gn...@gnu.org>

>
> >> If I just open the attached file (it's a unicode file) and do nothing but
> >> C-g C-s a few times quickly, I run into the hang.
> >>
> >> I'd appreciate it very much if someone could let me know how I could avoid
> >> this hang or dig out more information.
> >

> > I can see it in Emacs 25.2, but not in the pretest of what will become
> > Emacs 26.1. So one thing you could do is install that pretest, it's
> > available from alpha.gnu.org.
>

> I don't see a hang, I see an immediate segfault. I build emacs-26 myself.
> The recipe from "emacs -Q servicelistpage.txt":
> Type C-g.
>
> The crash occurs at -O1 and -O3. It does not occur at -O0. Attached is
> a gdb backtrace (at -O1 -ggdb3). This is built with the 64-bit mingw-w64
> toolchain from MSYS2, up to date as of now, from the fsf emacs-26
> branch, with no local patches.

I have 26.0.90 compiled with -Og, and it is not reproducible on my
system. Maybe it's something specific to the 64-bit build? My builds
are 32-bit.

[Richard Copley]

> Maybe it's something specific to the 64-bit build?

I suspect it might be the 64-bit specific alignment issue
discussed in this thread:
<http://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00329.html>

I've downloaded the 32-bit pretest for now, as the build I
described is unusable, I'm sorry to report. It very frequently
crashes on C-g.

After repeating my recipe above with that build, the faulting
instruction in ntdll!RtlCaptureContext is

=> 0x00007ffaa1b693a0 <+384>: movaps 0x60(%rax),%xmm0

... and %rax is 17185954536 decimal, 4005CDAE8 hex (not 16-byte
aligned).

[Eli Zaretskii]

> From: Richard Copley <rco...@gmail.com>
> Date: Sat, 28 Oct 2017 13:10:50 +0100
> Cc: "help-gn...@gnu.org" <help-gn...@gnu.org>

What variable is in RAX in that case?

[Richard Copley]

I don't think I can see that from here. I might be missing something.
If it is an argument passed to ntdll!RtlCaptureContext, perhaps I
can work it out from the function signature and the disassembly.
Is that what you meant?

(If you would you like to work it out yourself, how can I help?)

[Eli Zaretskii]

> Date: Sat, 28 Oct 2017 15:19:13 +0300
> From: Eli Zaretskii <el...@gnu.org>

>
> > => 0x00007ffaa1b693a0 <+384>: movaps 0x60(%rax),%xmm0
> >
> > ... and %rax is 17185954536 decimal, 4005CDAE8 hex (not 16-byte
> > aligned).
>
> What variable is in RAX in that case?

I'm guessing it's the jmp_buf from the longjmp call, and this is
probably some snafu related to the MinGW64's deviant _setjmp
machinery, sigh. In which case please involve the MinGW64 developers
in this issue, and ask them to suggest a solution.

(And this discussion should have moved to bug-gnu-emacs ages ago.)

Thanks.

[Richard Copley]

On 28 October 2017 at 13:25, Richard Copley <rco...@gmail.com> wrote:
> On 28 October 2017 at 13:19, Eli Zaretskii <el...@gnu.org> wrote:

>> What variable is in RAX in that case?
>

> I don't think I can see that from here. I might be missing something.
> If it is an argument passed to ntdll!RtlCaptureContext, perhaps I
> can work it out from the function signature and the disassembly.
> Is that what you meant?
>
> (If you would you like to work it out yourself, how can I help?)

Sorry. It's the first field in the longjmp record.

(gdb) p $rax
$1 = 17185954536
(gdb) up
#1 0x00007ffaa1ad8f27 in ntdll!RtlUnwindEx ()
from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) up
#2 0x00007ffaa0671f4a in msvcrt!_setjmpex ()
from C:\WINDOWS\System32\msvcrt.dll
(gdb) up
#3 0x00000004000b1a9a in quit_throw_to_read_char (
from_signal=from_signal@entry=false) at keyboard.c:10548
10548 sys_longjmp (getcjmp, 1);
(gdb) p &getcjmp
$2 = (sys_jmp_buf *) 0x4005cdae8 <main_thread+224>


(rax is 17185954536 = 4005CDAE8h).

[Eli Zaretskii]

> From: Richard Copley <rco...@gmail.com>
> Date: Sat, 28 Oct 2017 13:31:57 +0100
> Cc: "help-gn...@gnu.org" <help-gn...@gnu.org>

>
> (gdb) p $rax
> $1 = 17185954536

p/x $rax is usually more useful.

> (gdb) up
> #1 0x00007ffaa1ad8f27 in ntdll!RtlUnwindEx ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> (gdb) up
> #2 0x00007ffaa0671f4a in msvcrt!_setjmpex ()
> from C:\WINDOWS\System32\msvcrt.dll
> (gdb) up
> #3 0x00000004000b1a9a in quit_throw_to_read_char (
> from_signal=from_signal@entry=false) at keyboard.c:10548
> 10548 sys_longjmp (getcjmp, 1);
> (gdb) p &getcjmp
> $2 = (sys_jmp_buf *) 0x4005cdae8 <main_thread+224>
>
>
> (rax is 17185954536 = 4005CDAE8h).

So my guess was correct, and we should ask the MinGW64 developers for
advice about using longjmp. Most probably, something in that area has
changed in recent releases of their runtime, because otherwise I
cannot explain to myself why these issues pop up only now.

Thanks.

[Richard Copley]

Eli Zaretskii <el...@gnu.org> wrote:

> (And this discussion should have moved to bug-gnu-emacs ages ago.)

#29040 (CC'd).

>> (gdb) p $rax
>> $1 = 17185954536
>
> p/x $rax is usually more useful.

Much better, thank you.

> So my guess was correct, and we should ask the MinGW64 developers for
> advice about using longjmp. Most probably, something in that area has
> changed in recent releases of their runtime, because otherwise I
> cannot explain to myself why these issues pop up only now.

I thought Paul was of a differing opinion (see
<http://lists.gnu.org/archive/html/emacs-devel/2017-10/msg00482.html>)
but perhaps I'm mixing up different issues.

Do I take it we don't get to allocate the jmp_buf ourselves?

> Thanks.

Thanks.