GNU bug report logs - #30705
Segfault in get_next_display_element

Previous Next

Package: emacs;

Reported by: Clément Pit-Claudel <clement.pitclaudel <at> live.com>

Date: Sun, 4 Mar 2018 22:38:01 UTC

Severity: normal

Merged with 27761

Fixed in version 26.1

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30705 in the body.
You can then email your comments to 30705 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#30705; Package emacs. (Sun, 04 Mar 2018 22:38:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clément Pit-Claudel <clement.pitclaudel <at> live.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 04 Mar 2018 22:38:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Clément Pit-Claudel <clement.pitclaudel <at> live.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Segfault in get_next_display_element
Date: Sun, 4 Mar 2018 17:37:26 -0500
[Message part 1 (text/plain, inline)]
Hi all,

A user of one of my packages reported (https://github.com/cpitclaudel/company-coq/issues/159) a segfault in get_next_display_element, and collected the following information:

➜  ~ lldb /usr/local/Cellar/emacs/25.3/Emacs.app/Contents/MacOS/Emacs
(lldb) target create "/usr/local/Cellar/emacs/25.3/Emacs.app/Contents/MacOS/Emacs"
Current executable set to '/usr/local/Cellar/emacs/25.3/Emacs.app/Contents/MacOS/Emacs' (x86_64).
(lldb) run
Process 21443 launched: '/usr/local/Cellar/emacs/25.3/Emacs.app/Contents/MacOS/Emacs' (x86_64)
### [At this point I did exactly what I wrote in my previous post]
Process 21443 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3aefd8)
    frame #0: 0x0000000100018e58 Emacs`get_next_display_element + 44
Emacs`get_next_display_element:
->  0x100018e58 <+44>: callq  *(%r12,%rax,8)
    0x100018e5c <+48>: movb   %al, %r13b
    0x100018e5f <+51>: movq   0x838(%rbx), %rcx
    0x100018e66 <+58>: testl  %ecx, %ecx

additionally, the user noted: "at this point (lldb) bt spits out 60290 entries:"

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3aefd8)
  * frame #0: 0x0000000100018e58 Emacs`get_next_display_element + 44
    frame #1: 0x000000010001988e Emacs`get_next_display_element + 2658.
...  (these are all identical)
    frame #60207: 0x000000010001988e Emacs`get_next_display_element + 2658.
    frame #60208: 0x000000010001b29e Emacs`move_it_in_display_line_to + 3968
    frame #60209: 0x0000000100018b3f Emacs`move_it_to + 807
    frame #60210: 0x0000000100020522 Emacs`move_it_vertically + 70
    frame #60211: 0x0000000100051d3e Emacs`Fwindow_end + 423
    frame #60212: 0x0000000100102847 Emacs`Ffuncall + 983
    frame #60213: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60214: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60215: 0x0000000100102cae Emacs`call1 + 46
    frame #60216: 0x00000001001095b7 Emacs`mapcar1 + 459
    frame #60217: 0x00000001001097d2 Emacs`Fmapc + 78
    frame #60218: 0x0000000100102847 Emacs`Ffuncall + 983
    frame #60219: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60220: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60221: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60222: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60223: 0x0000000100102c7a Emacs`call0 + 25
    frame #60224: 0x0000000100054031 Emacs`run_funs + 29
    frame #60225: 0x0000000100053eda Emacs`run_window_configuration_change_hook + 427
    frame #60226: 0x00000001000543f3 Emacs`set_window_buffer + 851
    frame #60227: 0x00000001000548fa Emacs`Fset_window_buffer + 178
    frame #60228: 0x000000010010285b Emacs`Ffuncall + 1003
    frame #60229: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60230: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60231: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60232: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60233: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60234: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60235: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60236: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60237: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60238: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60239: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60240: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60241: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60242: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60243: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60244: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60245: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60246: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60247: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60248: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60249: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60250: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60251: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60252: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60253: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60254: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60255: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60256: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60257: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60258: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60259: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60260: 0x0000000100103253 Emacs`funcall_lambda + 730
    frame #60261: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60262: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60263: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60264: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60265: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60266: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60267: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60268: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60269: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60270: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60271: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60272: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60273: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60274: 0x00000001001023a2 Emacs`Fapply + 579
    frame #60275: 0x00000001001027d0 Emacs`Ffuncall + 864
    frame #60276: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60277: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60278: 0x00000001001023a2 Emacs`Fapply + 579
    frame #60279: 0x00000001001027d0 Emacs`Ffuncall + 864
    frame #60280: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60281: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60282: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60283: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60284: 0x000000010013280c Emacs`exec_byte_code + 2035
    frame #60285: 0x0000000100102710 Emacs`Ffuncall + 672
    frame #60286: 0x00000001000fd6e2 Emacs`Ffuncall_interactively + 58
    frame #60287: 0x00000001001027d0 Emacs`Ffuncall + 864
    frame #60288: 0x00000001000fdbaa Emacs`Fcall_interactively + 1203
    frame #60289: 0x000000010010285b Emacs`Ffuncall + 1003
    frame #60290: 0x0

The user's version is GNU Emacs 25.3.1 (x86_64-apple-darwin16.7.0, NS appkit-1504.83 Version 10.12.6 (Build 16G29)) of 2017-09-25; Emacs was installed via Homebrew with Cocoa support.

Is there extra information that I should ask the user for to help debug this issue?

Thanks,
Clément.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30705; Package emacs. (Mon, 05 Mar 2018 18:18:02 GMT) Full text and rfc822 format available.

Message #8 received at 30705 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Clément Pit-Claudel <clement.pitclaudel <at> live.com>
Cc: 30705 <at> debbugs.gnu.org
Subject: Re: bug#30705: Segfault in get_next_display_element
Date: Mon, 05 Mar 2018 20:17:18 +0200
> From: Clément Pit-Claudel <clement.pitclaudel <at> live.com>
> Date: Sun, 4 Mar 2018 17:37:26 -0500
> 
> A user of one of my packages reported (https://github.com/cpitclaudel/company-coq/issues/159) a segfault in get_next_display_element, and collected the following information:
> [...]
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff5f3aefd8)
>   * frame #0: 0x0000000100018e58 Emacs`get_next_display_element + 44
>     frame #1: 0x000000010001988e Emacs`get_next_display_element + 2658.
> ...  (these are all identical)
>     frame #60207: 0x000000010001988e Emacs`get_next_display_element + 2658.

This is bug#27661, already fixed in Emacs 26.  I suggest that this
user upgrades to the latest pretest of 26.1.

Thanks.




Forcibly Merged 27761 30705. Request was from Glenn Morris <rgm <at> gnu.org> to control <at> debbugs.gnu.org. (Mon, 05 Mar 2018 18:47:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 03 Apr 2018 11:24:04 GMT) Full text and rfc822 format available.

This bug report was last modified 7 years and 72 days ago.

Previous Next


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