GNU bug report logs - #74966
31.0.50; Crash report (using igc on macOS)

Previous Next

Package: emacs;

Reported by: Sean Devlin <spd <at> toadstyle.org>

Date: Thu, 19 Dec 2024 09:19:02 UTC

Severity: normal

Found in version 31.0.50

Done: Pip Cet <pipcet <at> protonmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Sean Devlin <spd <at> toadstyle.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 74966 <at> debbugs.gnu.org
Subject: bug#74966: 31.0.50; Crash report (using igc on macOS)
Date: Thu, 19 Dec 2024 20:54:41 +0900
Hi Pip,

> On Dec 19, 2024, at 8:48 PM, Pip Cet <pipcet <at> protonmail.com> wrote:
> 
> "Sean Devlin" <spd <at> toadstyle.org> writes:
> 
>> Hi folks,
> 
> Hello!
> 
>> I was using Emacs and encountered a crash.
> 
> Thanks for reporting it!
> 
>> I am running on macOS, and I built Emacs from scratch/igc using the
>> instructions on that branch.
>> 
>> I didn’t have Emacs running under a debugger, but I do have some crash
>> information captured by macOS. (See attached.)
> 
> I'm not entirely sure this is the actual segfault (the
> EXC_BAD_ACCESS/SIGABRT combination is a little odd):
> 
> Exception Type:        EXC_BAD_ACCESS (SIGABRT)
> Exception Codes:       KERN_INVALID_ADDRESS at 0x595453206f742068 -> 0x000053206f742068 (possible pointer authentication failure)
> Exception Codes:       0x0000000000000001, 0x595453206f742068
> 
> That's an ASCII string that we treated as a pointer, it seems?
> 
> 13  apropos-7c1ecbdf-5d074552.eln 	       0x103407010
> F6170726f706f732d736166652d646f63756d656e746174696f6e_apropos_safe_documentation_0
> + 208
> 
> Is there any way for you to disassemble this function?  At first glance,
> there's nothing unusual about it (it does use the symbol function, which
> always confuses me when (function x) was intended but #'x was what I
> got).
> 
> I'm not quite sure where the apropos-7c1ecbdf-5d074552.eln file lives on
> macOS, but I think, if you can find, you can run
> 
> llvm-objdump -d apropos-7c1ecbdf-5d074552.eln
> 
> (which will produce a lot of output; we're interested in the section
> belonging to the
> F6170726f706f732d736166652d646f63756d656e746174696f6e_apropos_safe_documentation_0
> section).
> 
> As this is reproducible, it's probably not a stack marking problem.

Here’s the function disassembly (using otool):

_F6170726f706f732d736166652d646f63756d656e746174696f6e_apropos_safe_documentation_0:
0000000000006f40	stp	x29, x30, [sp, #-0x40]!
0000000000006f44	mov	x29, sp
0000000000006f48	mov	x1, #0x0
0000000000006f4c	stp	x21, x22, [sp, #0x20]
0000000000006f50	adrp	x22, 20 ; 0x1a000
0000000000006f54	add	x22, x22, #0x198
0000000000006f58	stp	x19, x20, [sp, #0x10]
0000000000006f5c	ldr	x20, [x22]
0000000000006f60	ldr	x2, [x20, #0x2940]
0000000000006f64	blr	x2
0000000000006f68	cbz	x0, 0x6fe8
0000000000006f6c	adrp	x21, 18 ; 0x18000
0000000000006f70	add	x21, x21, #0xd78
0000000000006f74	mov	x2, x0
0000000000006f78	add	x1, x29, #0x30
0000000000006f7c	mov	x0, #0x2
0000000000006f80	ldr	x3, [x21, #0x868]
0000000000006f84	stp	x3, x2, [x29, #0x30]
0000000000006f88	ldr	x2, [x20, #0x1c68]
0000000000006f8c	blr	x2
0000000000006f90	sub	w1, w0, #0x2
0000000000006f94	mov	x19, x0
0000000000006f98	tst	x1, #0x3
0000000000006f9c	b.ne	0x6fc8
0000000000006fa0	ldr	x0, [x21, #0x10]
0000000000006fa4	mov	x1, #0x0
0000000000006fa8	ldr	x2, [x20, #0x2aa8]
0000000000006fac	blr	x2
0000000000006fb0	cbz	x0, 0x6fe8
0000000000006fb4	ldp	x21, x22, [sp, #0x20]
0000000000006fb8	mov	x0, x19
0000000000006fbc	ldp	x19, x20, [sp, #0x10]
0000000000006fc0	ldp	x29, x30, [sp], #0x40
0000000000006fc4	ret
0000000000006fc8	sub	w1, w0, #0x5
0000000000006fcc	tst	x1, #0x7
0000000000006fd0	b.eq	0x7000
0000000000006fd4	mov	x0, #0x0
0000000000006fd8	ldr	x2, [x20, #0x2aa8]
0000000000006fdc	mov	x1, #0x0
0000000000006fe0	blr	x2
0000000000006fe4	cbnz	x0, 0x6fb4
0000000000006fe8	mov	x19, #0x0
0000000000006fec	ldp	x21, x22, [sp, #0x20]
0000000000006ff0	mov	x0, x19
0000000000006ff4	ldp	x19, x20, [sp, #0x10]
0000000000006ff8	ldp	x29, x30, [sp], #0x40
0000000000006ffc	ret
0000000000007000	ldr	x2, [x22]
0000000000007004	mov	w1, #0x2
0000000000007008	ldr	x2, [x2, #0x8]
000000000000700c	blr	x2
0000000000007010	tbnz	w0, #0x0, 0x6fa0
0000000000007014	mov	x0, #0x0
0000000000007018	b	0x6fd8
000000000000701c	nop

> 
>> At the time, I was trying to use apropos-documentation. I invoked the
>> command once, entered a string, and hit RET, and it signaled an error. I
>> tried to do this again and Emacs crashed.
>> 
>> I hope this is useful. Please let me know if there’s any other
>> information I can collect.
> 
> Definitely useful!
> 
> Thanks!
> 
> Pip
> 





This bug report was last modified 130 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.