* bug#5973: Crash in get_next_display_element @ 2010-04-19 16:08 David Reitter [not found] ` <handler.5973.B.12716933351499.ack@debbugs.gnu.org> 2010-04-19 17:23 ` bug#5973: Crash in get_next_display_element Eli Zaretskii 0 siblings, 2 replies; 19+ messages in thread From: David Reitter @ 2010-04-19 16:08 UTC (permalink / raw) To: 5973 I just had a crash. I can't pinpoint what triggered it. Line xdisp.c:5946 is this in the build that I was running: it->face_id = FACE_FOR_CHAR (it->f, face, it->c, pos, it->string); FWIW, the build was done with CPP=cc -E -no-cpp-precomp CFLAGS=-g -O0 -Wdeclaration-after-statement -Wno-pointer-sign So one may possibly infer from the trace below that face_for_char() was NOT called by FACE_FOR_CHAR, and that the invalid pointer was somewhere in (FACE)->ascii_face->id (see dispextern.h:1693). Maybe FACE_FROM_ID returned a null pointer as it is documented to do if the face doesn't exist (?? frame? face got just deleted with frame??) and this bit of code doesn't check face. But that's speculation - I don't know the display code very well. -- Process: Aquamacs [16933] Path: /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/MacOS/Aquamacs Identifier: org.gnu.AquamacsEmacs Version: 2.0preview6 (???) Code Type: X86-64 (Native) Parent Process: launchd [200] Date/Time: 2010-04-19 11:47:16.858 -0400 OS Version: Mac OS X 10.6.3 (10D573) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000110 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Application Specific Information: abort() called Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff86572886 __kill + 10 1 org.gnu.AquamacsEmacs 0x00000001000909ce fatal_error_signal + 286 (emacs.c:402) 2 libSystem.B.dylib 0x00007fff8658480a _sigtramp + 26 3 libSystem.B.dylib 0x00007fff86572886 __kill + 10 4 libSystem.B.dylib 0x00007fff86612eae abort + 83 5 org.gnu.AquamacsEmacs 0x00000001001764bb ns_term_shutdown + 106 (nsterm.m:4278) 6 org.gnu.AquamacsEmacs 0x0000000100090a04 fatal_error_signal + 340 (emacs.c:388) 7 libSystem.B.dylib 0x00007fff8658480a _sigtramp + 26 8 org.gnu.AquamacsEmacs 0x000000010002cabc get_next_display_element + 2796 (xdisp.c:5946) 9 org.gnu.AquamacsEmacs 0x000000010002d525 move_it_in_display_line_to + 245 (xdisp.c:6744) 10 org.gnu.AquamacsEmacs 0x000000010002e9ee move_it_to + 302 (xdisp.c:7165) 11 org.gnu.AquamacsEmacs 0x000000010000642a buffer_posn_from_coords + 282 (dispnew.c:5960) 12 org.gnu.AquamacsEmacs 0x0000000100094543 make_lispy_position + 611 (keyboard.c:5521) 13 org.gnu.AquamacsEmacs 0x000000010009de39 make_lispy_event + 1017 (keyboard.c:6033) 14 org.gnu.AquamacsEmacs 0x00000001000a0702 read_char + 7986 (keyboard.c:4347) 15 org.gnu.AquamacsEmacs 0x00000001000a188f read_key_sequence + 1215 (keyboard.c:9541) 16 org.gnu.AquamacsEmacs 0x00000001000a3e0b command_loop_1 + 587 (keyboard.c:1643) 17 org.gnu.AquamacsEmacs 0x00000001001091e7 internal_condition_case + 327 (eval.c:1490) 18 org.gnu.AquamacsEmacs 0x000000010009b147 command_loop_2 + 55 (keyboard.c:1361) 19 org.gnu.AquamacsEmacs 0x00000001001092f0 internal_catch + 224 (eval.c:1226) 20 org.gnu.AquamacsEmacs 0x000000010009bb6b command_loop + 75 (keyboard.c:1326) 21 org.gnu.AquamacsEmacs 0x000000010009c03f recursive_edit_1 + 159 (keyboard.c:954) 22 org.gnu.AquamacsEmacs 0x000000010009c1df Frecursive_edit + 287 (keyboard.c:1017) 23 org.gnu.AquamacsEmacs 0x000000010010ad90 Ffuncall + 1232 (eval.c:3021) 24 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 25 org.gnu.AquamacsEmacs 0x000000010010a134 Feval + 1476 (eval.c:2352) 26 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 27 org.gnu.AquamacsEmacs 0x00000001000496f1 Fsave_window_excursion + 81 (window.c:6585) 28 org.gnu.AquamacsEmacs 0x0000000100146672 Fbyte_code + 2946 (bytecode.c:841) 29 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 30 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 31 org.gnu.AquamacsEmacs 0x000000010010c866 Fapply + 566 (eval.c:2448) 32 org.gnu.AquamacsEmacs 0x000000010010ae1b Ffuncall + 1371 (eval.c:3005) 33 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 34 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 35 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 36 org.gnu.AquamacsEmacs 0x000000010010c745 Fapply + 277 (eval.c:2504) 37 org.gnu.AquamacsEmacs 0x000000010010c8c2 apply1 + 50 (eval.c:2778) 38 org.gnu.AquamacsEmacs 0x00000001001096ff call_debugger + 495 (eval.c:272) 39 org.gnu.AquamacsEmacs 0x0000000100109874 maybe_call_debugger + 340 (eval.c:1880) 40 org.gnu.AquamacsEmacs 0x0000000100109a9c find_handler_clause + 476 (eval.c:1939) 41 org.gnu.AquamacsEmacs 0x000000010010b0f6 Fsignal + 438 (eval.c:1679) 42 org.gnu.AquamacsEmacs 0x000000010010ad71 Ffuncall + 1201 (eval.c:3027) 43 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 44 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 45 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 46 org.gnu.AquamacsEmacs 0x000000010010c8de apply1 + 78 (eval.c:2778) 47 org.gnu.AquamacsEmacs 0x0000000100106099 Fcall_interactively + 633 (callint.c:396) 48 org.gnu.AquamacsEmacs 0x000000010010ad5c Ffuncall + 1180 (eval.c:3030) 49 org.gnu.AquamacsEmacs 0x000000010010af06 call3 + 38 (eval.c:2856) 50 org.gnu.AquamacsEmacs 0x00000001000a4082 command_loop_1 + 1218 (keyboard.c:1912) 51 org.gnu.AquamacsEmacs 0x00000001001091e7 internal_condition_case + 327 (eval.c:1490) 52 org.gnu.AquamacsEmacs 0x000000010009b147 command_loop_2 + 55 (keyboard.c:1361) 53 org.gnu.AquamacsEmacs 0x00000001001092f0 internal_catch + 224 (eval.c:1226) 54 org.gnu.AquamacsEmacs 0x000000010009bb6b command_loop + 75 (keyboard.c:1326) 55 org.gnu.AquamacsEmacs 0x000000010009c03f recursive_edit_1 + 159 (keyboard.c:954) 56 org.gnu.AquamacsEmacs 0x000000010009c1df Frecursive_edit + 287 (keyboard.c:1017) 57 org.gnu.AquamacsEmacs 0x000000010010ad90 Ffuncall + 1232 (eval.c:3021) 58 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 59 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 60 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 61 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 62 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 63 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 64 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 65 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 66 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 67 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 68 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 69 org.gnu.AquamacsEmacs 0x000000010010a848 apply_lambda + 216 (eval.c:3135) 70 org.gnu.AquamacsEmacs 0x0000000100109df3 Feval + 643 (eval.c:2406) 71 org.gnu.AquamacsEmacs 0x0000000100109faa Feval + 1082 (eval.c:2331) 72 org.gnu.AquamacsEmacs 0x000000010010a801 apply_lambda + 145 (eval.c:3122) 73 org.gnu.AquamacsEmacs 0x0000000100109df3 Feval + 643 (eval.c:2406) 74 org.gnu.AquamacsEmacs 0x000000010010d21b Fcond + 91 (eval.c:388) 75 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 76 org.gnu.AquamacsEmacs 0x000000010010a801 apply_lambda + 145 (eval.c:3122) 77 org.gnu.AquamacsEmacs 0x0000000100109df3 Feval + 643 (eval.c:2406) 78 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 79 org.gnu.AquamacsEmacs 0x000000010010a728 funcall_lambda + 680 (eval.c:3204) 80 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 81 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 82 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 83 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 84 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 85 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 86 org.gnu.AquamacsEmacs 0x000000010010a848 apply_lambda + 216 (eval.c:3135) 87 org.gnu.AquamacsEmacs 0x0000000100109df3 Feval + 643 (eval.c:2406) 88 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 89 org.gnu.AquamacsEmacs 0x000000010010a728 funcall_lambda + 680 (eval.c:3204) 90 org.gnu.AquamacsEmacs 0x000000010010a848 apply_lambda + 216 (eval.c:3135) 91 org.gnu.AquamacsEmacs 0x0000000100109df3 Feval + 643 (eval.c:2406) 92 org.gnu.AquamacsEmacs 0x000000010010d31d Fand + 77 (eval.c:336) 93 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 94 org.gnu.AquamacsEmacs 0x000000010010d21b Fcond + 91 (eval.c:388) 95 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 96 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 97 org.gnu.AquamacsEmacs 0x000000010010d171 FletX + 321 (eval.c:1012) 98 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 99 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 100 org.gnu.AquamacsEmacs 0x000000010010a728 funcall_lambda + 680 (eval.c:3204) 101 org.gnu.AquamacsEmacs 0x000000010010a848 apply_lambda + 216 (eval.c:3135) 102 org.gnu.AquamacsEmacs 0x0000000100109df3 Feval + 643 (eval.c:2406) 103 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 104 org.gnu.AquamacsEmacs 0x000000010010cfcb Flet + 459 (eval.c:1068) 105 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 106 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 107 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 108 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 109 org.gnu.AquamacsEmacs 0x000000010010a728 funcall_lambda + 680 (eval.c:3204) 110 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 111 org.gnu.AquamacsEmacs 0x000000010010a23e Feval + 1742 (eval.c:2319) 112 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 113 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 114 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 115 org.gnu.AquamacsEmacs 0x000000010010d171 FletX + 321 (eval.c:1012) 116 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 117 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 118 org.gnu.AquamacsEmacs 0x000000010010a728 funcall_lambda + 680 (eval.c:3204) 119 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 120 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 121 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 122 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 123 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 124 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 125 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 126 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 127 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 128 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 129 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 130 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 131 org.gnu.AquamacsEmacs 0x000000010010a848 apply_lambda + 216 (eval.c:3135) 132 org.gnu.AquamacsEmacs 0x0000000100109df3 Feval + 643 (eval.c:2406) 133 org.gnu.AquamacsEmacs 0x000000010010cf18 Flet + 280 (eval.c:1052) 134 org.gnu.AquamacsEmacs 0x000000010010a1c1 Feval + 1617 (eval.c:2293) 135 org.gnu.AquamacsEmacs 0x000000010010a45f Fprogn + 47 (eval.c:415) 136 org.gnu.AquamacsEmacs 0x000000010010a728 funcall_lambda + 680 (eval.c:3204) 137 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 138 org.gnu.AquamacsEmacs 0x000000010014758e Fbyte_code + 6814 (bytecode.c:680) 139 org.gnu.AquamacsEmacs 0x000000010010a6cc funcall_lambda + 588 (eval.c:3211) 140 org.gnu.AquamacsEmacs 0x000000010010ab12 Ffuncall + 594 (eval.c:3081) 141 org.gnu.AquamacsEmacs 0x000000010010c8de apply1 + 78 (eval.c:2778) 142 org.gnu.AquamacsEmacs 0x0000000100106099 Fcall_interactively + 633 (callint.c:396) 143 org.gnu.AquamacsEmacs 0x000000010010ad5c Ffuncall + 1180 (eval.c:3030) 144 org.gnu.AquamacsEmacs 0x000000010010af06 call3 + 38 (eval.c:2856) 145 org.gnu.AquamacsEmacs 0x00000001000a4082 command_loop_1 + 1218 (keyboard.c:1912) 146 org.gnu.AquamacsEmacs 0x00000001001091e7 internal_condition_case + 327 (eval.c:1490) 147 org.gnu.AquamacsEmacs 0x000000010009b147 command_loop_2 + 55 (keyboard.c:1361) 148 org.gnu.AquamacsEmacs 0x00000001001092f0 internal_catch + 224 (eval.c:1226) 149 org.gnu.AquamacsEmacs 0x000000010009bbd6 command_loop + 182 (keyboard.c:1340) 150 org.gnu.AquamacsEmacs 0x000000010009c03f recursive_edit_1 + 159 (keyboard.c:954) 151 org.gnu.AquamacsEmacs 0x000000010009c1df Frecursive_edit + 287 (keyboard.c:1017) 152 org.gnu.AquamacsEmacs 0x00000001000917b7 main + 3447 (emacs.c:1836) 153 org.gnu.AquamacsEmacs 0x0000000100002164 start + 52 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x00007fff8653d4ea kevent + 10 1 libSystem.B.dylib 0x00007fff8653f3bd _dispatch_mgr_invoke + 154 2 libSystem.B.dylib 0x00007fff8653f094 _dispatch_queue_invoke + 185 3 libSystem.B.dylib 0x00007fff8653ebbe _dispatch_worker_thread2 + 252 4 libSystem.B.dylib 0x00007fff8653e4e8 _pthread_wqthread + 353 5 libSystem.B.dylib 0x00007fff8653e385 start_wqthread + 13 Thread 2: 0 libSystem.B.dylib 0x00007fff86568286 select$DARWIN_EXTSN + 10 1 com.apple.CoreFoundation 0x00007fff84fecef2 __CFSocketManager + 818 2 libSystem.B.dylib 0x00007fff8655d8b6 _pthread_start + 331 3 libSystem.B.dylib 0x00007fff8655d769 thread_start + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000000000006 rcx: 0x00007fff5fbf7038 rdx: 0x0000000000000000 rdi: 0x0000000000004225 rsi: 0x0000000000000006 rbp: 0x00007fff5fbf7070 rsp: 0x00007fff5fbf7038 r8: 0x0000000000000001 r9: 0x00000001163dfe00 r10: 0x00007fff8656e8ca r11: 0x0000000000000202 r12: 0x0000000000000006 r13: 0x00000001006295a8 r14: 0x0000000000000001 r15: 0x0000000000000001 rip: 0x00007fff86572886 rfl: 0x0000000000000202 cr2: 0x00007fff70c84058 In GNU Emacs 23.1.95.17 (x86_64-apple-darwin10.3.0, NS apple-appkit-1038.29) of 2010-04-18 on scarlett.local - Aquamacs Distribution 2.0preview6 Windowing system distributor `Apple', version 10.3.1038 configured using `configure '--with-ns'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 value of $XMODIFIERS: nil locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: C/l Minor modes in effect: diff-auto-refine-mode: t TeX-PDF-mode: t which-function-mode: t desktop-save-mode: t savehist-mode: t smart-frame-positioning-mode: t aquamacs-autoface-mode: t recentf-mode: t osx-key-mode: t tabbar-mwheel-mode: t tabbar-mode: t show-paren-mode: t delete-selection-mode: t pc-selection-mode: t cua-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: <mouse-movement> <drag-mouse-1> ⌘C <down-mouse-1> <mouse-1> ⌘V <return> ⇧T H I S SPC A D D <backspace> <backspace> <backspace> W O R K S SPC A R O U N D SPC A N SPC I S S U E SPC W H E R E SPC <down-mouse-1> <mouse-1> <help-echo> <ns-application-activated> W I N D O W SPC S <backspace> <backspace> S SPC A R E SPC <backspace> <backspace> <backspace> <backspace> O I O <backspace> <backspace> <backspace> P O P SPC U P SPC A N D SPC D O N ' T SPC G E T SPC D E L T E D SPC <backspace> <backspace> <backspace> <backspace> E T E D SPC W H E N SPC T H E SPC U S E R SPC I S SPC D O N E . ^C ^C <ns-application-activated> <wheel-down> <double-wheel-down> <triple-wheel-down> <triple-wheel-down> <triple-wheel-down> <wheel-down> <double-wheel-down> <triple-wheel-down> <triple-wheel-down> <triple-wheel-down> <down-mouse-1> <mouse-1> ^X ^E ^H V <return> <help-echo> <help-echo> <help-echo> <help-echo> <ns-application-activated> <switch-frame> <home> <ns-application-activated> ⌘W ⌘W <down-mouse-1> <mouse-1> ⌘W <ns-application-activated> <help-echo> ^X ^F A E . G <tab> S R <tab> X D <tab> <return> ⌘L 5 9 4 6 <return> <wheel-up> <ns-application-activated> <down-mouse-1> <mouse-movement> <drag-mouse-1> ⌘C <ns-application-activated> <wheel-up> <double-wheel-up> <triple-wheel-up> <triple-wheel-up> ^F ⌥X G R E P <return> ⇧F ⇧A ⇧C ⇧E _ ⇧F ⇧O ⇧R _ ⇧C ⇧H ⇧A ⇧R SPC | SPC G R E P SPC D E F I N E <return> <help-echo> <down-mouse-1> <mouse-1> ⌘W ⌥X <up> <return> <up> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> * SPC <return> <ns-application-activated> <help-echo> <down-mouse-1> <mouse-1> ^X ^F D I S P E <tab> <return> ⌘F ⇧F ⇧A ⇧C ⇧E _ ⇧F ⇧O ⇧R _ ⇧C ⇧H <help-echo> <down-mouse-1> <mouse-1> <menu-bar> <help-menu> <bug-diagnosis> <debug-on-error> <menu-bar> <help-menu> <bug-diagnosis> <debug-on-error> <menu-bar> <help-menu> <bug-diagnosis> <send-emacs -bug-report> Recent messages: Type "q" to quit. Unable to load color "dark cyan" Mark set [2 times] Unable to load color "dark cyan" [3 times] Grep finished with no matches found Unable to load color "dark cyan" Grep finished (matches found) Unable to load color "dark cyan" Debug on Error enabled globally Debug on Error disabled globally Load-path shadows: /Users/dr/Library/Preferences/Aquamacs Emacs/Recent Files hides /Users/dr/Library/Preferences/Aquamacs Emacs/Aquamacs Emacs2/Recent Files /Users/dr/Library/Preferences/Aquamacs Emacs/Preferences hides /Users/dr/Library/Preferences/Aquamacs Emacs/Aquamacs Emacs2/Preferences /Users/dr/Library/Preferences/Aquamacs Emacs/places hides /Users/dr/Library/Preferences/Aquamacs Emacs/Aquamacs Emacs2/places /Users/dr/Library/Preferences/Aquamacs Emacs/minibuffer-history hides /Users/dr/Library/Preferences/Aquamacs Emacs/Aquamacs Emacs2/minibuffer-history /Users/dr/Library/Preferences/Aquamacs Emacs/frame-positions hides /Users/dr/Library/Preferences/Aquamacs Emacs/Aquamacs Emacs2/frame-positions /Users/dr/Library/Preferences/Aquamacs Emacs/customizations hides /Users/dr/Library/Preferences/Aquamacs Emacs/Aquamacs Emacs2/customizations /Library/Application Support/Aquamacs Emacs/JDEE/site-start hides /Library/Application Support/Aquamacs Emacs/SLIME/site-start /Library/Application Support/Aquamacs Emacs/JDEE/cedet/speedbar/speedbar hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/speedbar /Library/Application Support/Aquamacs Emacs/JDEE/cedet/speedbar/sb-image hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/sb-image /Library/Application Support/Aquamacs Emacs/JDEE/cedet/common/ezimage hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/ezimage /Library/Application Support/Aquamacs Emacs/JDEE/cedet/speedbar/dframe hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/dframe /Library/Application Support/Aquamacs Emacs/JDEE/cedet/eieio/eieio hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/emacs-lisp/eieio /Library/Application Support/Aquamacs Emacs/JDEE/cedet/eieio/eieio-speedbar hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/emacs-lisp/eieio-speedbar /Library/Application Support/Aquamacs Emacs/JDEE/cedet/eieio/eieio-opt hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/emacs-lisp/eieio-opt /Library/Application Support/Aquamacs Emacs/JDEE/cedet/eieio/eieio-custom hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/emacs-lisp/eieio-custom /Library/Application Support/Aquamacs Emacs/JDEE/cedet/eieio/eieio-comp hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/emacs-lisp/eieio-comp /Library/Application Support/Aquamacs Emacs/JDEE/cedet/eieio/eieio-base hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/emacs-lisp/eieio-base /Library/Application Support/Aquamacs Emacs/JDEE/cedet/eieio/chart hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/emacs-lisp/chart /Library/Application Support/Aquamacs Emacs/JDEE/cedet/semantic/semantic hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/cedet/semantic /Library/Application Support/Aquamacs Emacs/JDEE/cedet/common/mode-local hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/cedet/mode-local /Library/Application Support/Aquamacs Emacs/JDEE/cedet/common/inversion hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/cedet/inversion /Library/Application Support/Aquamacs Emacs/JDEE/cedet/ede/ede hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/cedet/ede /Library/Application Support/Aquamacs Emacs/JDEE/cedet/common/cedet hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/cedet/cedet /Library/Application Support/Aquamacs Emacs/JDEE/cedet/common/cedet-files hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/cedet/cedet-files /Library/Application Support/Aquamacs Emacs/JDEE/site-start hides /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp/aquamacs/site-start Features: (shadow sort mail-extr message ecomplete rfc822 mml mml-sec password-cache mm-decode mm-bodies mm-encode mailabbrev nnheader gnus-util netrc gmm-utils mailheader canlock sha1 hex-util hashcash emacsbug grep compile comint pp log-edit ring pcvs-util add-log multi-isearch diff-mode vc vc-dispatcher url-http tls url-auth mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums url-gw url-cache url url-proxy url-privacy url-expand url-methods url-history url-cookie url-util url-parse url-vars mm-util mail-prsvr mailcap mail-utils preview prv-emacs tex-buf reftex-vcr reftex-dcr reftex-auc reftex reftex-vars bib-cite tex-fold noutline outline font-latex latex edmacro kmacro tex-style tex sh-script executable vc-git cc-mode cc-fonts cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs which-func imenu desktop slime-autoloads load-emacs-plugins aquamacs-mode-defaults auctex-config server tex-site smart-dnd aquamacs-aux savehist mouse-sel one-buffer-one-frame smart-frame-positioning drews_init color-theme-autoloads saveplace visual-line aquamacs-bug aquamacs-autoface-mode aquamacs-editing sendmail recentf tree-widget cus-edit osxkeys emulate-mac-keyboard-mode frame-cmds strings misc-fns thingatpt+ thingatpt frame-fns avoid aquamacs-mac-fontsets fit-frame aquamacs-frame-setup aquamacs-tabbar tabbar-window cl cl-19 tabbar easy-mmode cus-start cus-load load-emacs-pre-plugins aquamacs-site-start cocoa-compatibility filladapt aquamacs-redo check-for-updates aquamacs-menu osx_defaults aquamacs-tool-bar aquamacs mac-extra-functions aquamacs-tools aquamacs-macros parse-time timezone time-date paren delsel pc-select cua-base wid-edit regexp-opt advice advice-preload byte-opt bytecomp byte-compile debug help-fns help-mode view image-file disp-table tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win easymenu tool-bar dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button minibuffer faces cus-face files text-properties overlay md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process ns multi-tty emacs) Command line: (/Users/dr/ae.git/nextstep/Aquamacs.app/Contents/MacOS/Aquamacs) PATH: /opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/Current/bin:/opt/local/lib/postgresql82/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/texbin:/usr/X11/bin:/Users/dr/Applications:/Users/dr/Applications/bin:/Users/dr/Projects/openccg/bin:/usr/texbin/powerpc-apple-darwin-current:/usr/local/git/bin:/Developer/Platforms/iPhoneFOSS.platform/Developer/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin:/usr/local/texlive/2009/bin exec-path: (/opt/local/bin /opt/local/sbin /opt/local/bin /opt/local/sbin /opt/local/bin /opt/local/sbin /Library/Frameworks/Python.framework/Versions/Current/bin /opt/local/lib/postgresql82/bin /opt/local/bin /opt/local/sbin /usr/bin /bin /usr/sbin /sbin /usr/local/bin /usr/local/git/bin /usr/texbin /usr/X11/bin /Users/dr/Applications /Users/dr/Applications/bin /Users/dr/Projects/openccg/bin /usr/texbin/powerpc-apple-darwin-current /usr/local/git/bin /Developer/Platforms/iPhoneFOSS.platform/Developer/bin /usr/bin /bin /usr/sbin /sbin /Users/dr/ae.git/nextstep/Aquamacs.app/Contents/MacOS/bin /usr/local/texlive/2009/bin) ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <handler.5973.B.12716933351499.ack@debbugs.gnu.org>]
* bug#5973: Acknowledgement (Crash in get_next_display_element) [not found] ` <handler.5973.B.12716933351499.ack@debbugs.gnu.org> @ 2010-04-19 16:46 ` David Reitter 2010-04-19 17:31 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: David Reitter @ 2010-04-19 16:46 UTC (permalink / raw) To: 5973 In line what is done just below in the same function, I would suggest at least the following change diff --git a/src/xdisp.c b/src/xdisp.c index 91fd06e..4fc4f56 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -5930,6 +5930,8 @@ get_next_display_element (it) { struct face *face = FACE_FROM_ID (it->f, it->face_id); + if (face) /* is face id valid? */ + { if (it->what == IT_COMPOSITION && it->cmp_it.ch >= 0) { /* Automatic composition with glyph-string. */ @@ -5945,6 +5947,7 @@ get_next_display_element (it) it->face_id = FACE_FOR_CHAR (it->f, face, it->c, pos, it->string); } + } } #endif ^ permalink raw reply related [flat|nested] 19+ messages in thread
* bug#5973: Acknowledgement (Crash in get_next_display_element) 2010-04-19 16:46 ` bug#5973: Acknowledgement (Crash in get_next_display_element) David Reitter @ 2010-04-19 17:31 ` Eli Zaretskii 0 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2010-04-19 17:31 UTC (permalink / raw) To: David Reitter; +Cc: 5973 > From: David Reitter <david.reitter@gmail.com> > Date: Mon, 19 Apr 2010 12:46:26 -0400 > Cc: > > In line what is done just below in the same function, I would suggest at least the following change Thanks, but I don't think we should fix problems until we understand them. In general, it->face_id should index a face that is already realized at this point. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-19 16:08 bug#5973: Crash in get_next_display_element David Reitter [not found] ` <handler.5973.B.12716933351499.ack@debbugs.gnu.org> @ 2010-04-19 17:23 ` Eli Zaretskii 2010-04-19 17:40 ` David Reitter 1 sibling, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2010-04-19 17:23 UTC (permalink / raw) To: David Reitter; +Cc: 5973 > From: David Reitter <david.reitter@gmail.com> > Date: Mon, 19 Apr 2010 12:08:18 -0400 > Cc: > > I just had a crash. I can't pinpoint what triggered it. > > Line xdisp.c:5946 is this in the build that I was running: > > it->face_id = FACE_FOR_CHAR (it->f, face, it->c, pos, it->string); > > > FWIW, the build was done with > CPP=cc -E -no-cpp-precomp > CFLAGS=-g -O0 -Wdeclaration-after-statement -Wno-pointer-sign > > So one may possibly infer from the trace below that face_for_char() was NOT called by FACE_FOR_CHAR, and that the invalid pointer was somewhere in (FACE)->ascii_face->id (see dispextern.h:1693). > > Maybe FACE_FROM_ID returned a null pointer as it is documented to do if the face doesn't exist (?? frame? face got just deleted with frame??) and this bit of code doesn't check face. > > But that's speculation - I don't know the display code very well. Let's start by finding the immediate reason for the crash. Please show the contents of `face', the last argument to FACE_FOR_CHAR in the line that crashed. Also, what kind of signal was it that crashed the program? (The backtrace is in some form that I'm not familiar with, so maybe the information is already present there.) Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-19 17:23 ` bug#5973: Crash in get_next_display_element Eli Zaretskii @ 2010-04-19 17:40 ` David Reitter 2010-04-19 18:26 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: David Reitter @ 2010-04-19 17:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 5973 On Apr 19, 2010, at 1:23 PM, Eli Zaretskii wrote: > > Let's start by finding the immediate reason for the crash. Please > show the contents of `face', the last argument to FACE_FOR_CHAR in the > line that crashed. How do I do that? It didn't run in gdb, and I don't know how to reproduce the crash. I just did a search on a year worth of crash logs (47 crashes) and didn't find this specific crash again. > Also, what kind of signal was it that crashed the program? (The > backtrace is in some form that I'm not familiar with, so maybe the > information is already present there.) Yes: Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000110 > > Thanks, but I don't think we should fix problems until we understand > them. In general, it->face_id should index a face that is already > realized at this point. Is it possible that this code runs, somehow, after a face got deleted? That, per se, might be the real cause of the bug - but I can only speculate. As said, the macro is documented to return NULL in some cases, and the code in the same function (below) checks for that case (of course I don't know when such a case can happen). So independently of this particular crash it would be good style to "if (face)" there. Let me know if I can help in any way. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-19 17:40 ` David Reitter @ 2010-04-19 18:26 ` Eli Zaretskii 2010-04-19 18:39 ` David Reitter 2010-04-19 22:46 ` Juanma Barranquero 0 siblings, 2 replies; 19+ messages in thread From: Eli Zaretskii @ 2010-04-19 18:26 UTC (permalink / raw) To: David Reitter; +Cc: 5973 > From: David Reitter <david.reitter@gmail.com> > Date: Mon, 19 Apr 2010 13:40:18 -0400 > Cc: 5973@debbugs.gnu.org > > On Apr 19, 2010, at 1:23 PM, Eli Zaretskii wrote: > > > > Let's start by finding the immediate reason for the crash. Please > > show the contents of `face', the last argument to FACE_FOR_CHAR in the > > line that crashed. > > How do I do that? > It didn't run in gdb, and I don't know how to reproduce the crash. Do you have a core file? If so, then you can run GDB on it. If not, then I'm afraid we will need to wait for another instance of this crash. > > Also, what kind of signal was it that crashed the program? (The > > backtrace is in some form that I'm not familiar with, so maybe the > > information is already present there.) > > Yes: > > Exception Type: EXC_BAD_ACCESS (SIGABRT) > Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000110 This sounds like SIGSEGV, so I wonder why it says SIGABRT. > > Thanks, but I don't think we should fix problems until we understand > > them. In general, it->face_id should index a face that is already > > realized at this point. > > Is it possible that this code runs, somehow, after a face got deleted? That, per se, might be the real cause of the bug - but I can only speculate. I don't know. But this code exists there since Emacs 21.x, with only minor changes. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-19 18:26 ` Eli Zaretskii @ 2010-04-19 18:39 ` David Reitter 2010-04-19 18:43 ` Eli Zaretskii 2010-04-19 22:46 ` Juanma Barranquero 1 sibling, 1 reply; 19+ messages in thread From: David Reitter @ 2010-04-19 18:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 5973 On Apr 19, 2010, at 2:26 PM, Eli Zaretskii wrote: > > Do you have a core file? If so, then you can run GDB on it. > > If not, then I'm afraid we will need to wait for another instance of > this crash. I don't have a core dump. Too bad. Maybe I'll turn on core dumping for the next crash. I doubt I'll see the same crash again, as it seems to be rare. - D ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-19 18:39 ` David Reitter @ 2010-04-19 18:43 ` Eli Zaretskii 0 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2010-04-19 18:43 UTC (permalink / raw) To: David Reitter; +Cc: 5973 > From: David Reitter <david.reitter@gmail.com> > Date: Mon, 19 Apr 2010 14:39:30 -0400 > Cc: 5973@debbugs.gnu.org > > On Apr 19, 2010, at 2:26 PM, Eli Zaretskii wrote: > > > > Do you have a core file? If so, then you can run GDB on it. > > > > If not, then I'm afraid we will need to wait for another instance of > > this crash. > > I don't have a core dump. Too bad. > > Maybe I'll turn on core dumping for the next crash. Or just run under GDB all the time. It doesn't get in the way in any way, until there's a crash. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-19 18:26 ` Eli Zaretskii 2010-04-19 18:39 ` David Reitter @ 2010-04-19 22:46 ` Juanma Barranquero 2010-04-20 8:23 ` Eli Zaretskii 2010-04-20 10:21 ` Eli Zaretskii 1 sibling, 2 replies; 19+ messages in thread From: Juanma Barranquero @ 2010-04-19 22:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: David Reitter, 5973 On Mon, Apr 19, 2010 at 20:26, Eli Zaretskii <eliz@gnu.org> wrote: > If not, then I'm afraid we will need to wait for another instance of > this crash. I get a similar crash on Windows (trace attached). I can reproduce it reliably, but it depends on something in my .emacs, so I cannot give a recipe right now. Juanma Breakpoint 1, w32_abort () at w32fns.c:7349 7349 button = MessageBox (NULL, (gdb) bt #0 w32_abort () at w32fns.c:7349 #1 0x012be7c9 in temp_set_point_both (buffer=0x34b6e00, charpos=32, bytepos=33) at intervals.c:1944 #2 0x012772b4 in autocmp_chars (cft_element=50852182, charpos=29, bytepos=29, limit=31, win=0x350b400, face=0x4e8c100, string=49838082) at composite.c:1002 #3 0x01278591 in composition_reseat_it (cmp_it=0x88db74, charpos=29, bytepos=29, endpos=32, w=0x350b400, face=0x4e8c100, string=49838082) at composite.c:1147 #4 0x01069fcb in next_element_from_buffer (it=0x88d6f8) at xdisp.c:6834 #5 0x01066642 in get_next_display_element (it=0x88d6f8) at xdisp.c:5828 #6 0x0106a6ff in move_it_in_display_line_to (it=0x88d6f8, to_charpos=32, to_x=-1, op=MOVE_TO_POS) at xdisp.c:7087 #7 0x0106bca3 in move_it_to (it=0x88d6f8, to_charpos=32, to_x=-1, to_y=-1, to_vpos=-1, op=8) at xdisp.c:7588 #8 0x01071704 in resize_mini_window (w=0x350b400, exact_p=0) at xdisp.c:9083 #9 0x01070ec4 in display_echo_area_1 (a1=55620608, a2=49838082, a3=0, a4=0) at xdisp.c:8946 #10 0x0106fa35 in with_echo_area_buffer (w=0x350b400, which=0, fn=0x1070e9e <display_echo_area_1>, a1=55620608, a2=49838082, a3=0, a4=0) at xdisp.c:8733 #11 0x01070e6c in display_echo_area (w=0x350b400) at xdisp.c:8914 #12 0x01072a21 in echo_area_display (update_frame_p=1) at xdisp.c:9512 #13 0x0106e656 in message3_nolog (m=85027169, nbytes=32, multibyte=1) at xdisp.c:8409 #14 0x0106e135 in message3 (m=85027169, nbytes=32, multibyte=1) at xdisp.c:8344 #15 0x01224ccc in Fmessage (nargs=2, args=0x88e1c4) at editfns.c:3408 #16 0x0103c58e in Ffuncall (nargs=3, args=0x88e1c0) at eval.c:3005 #17 0x011ef7d8 in Fbyte_code (bytestr=82551569, vector=51162213, maxdepth=12) at bytecode.c:680 #18 0x0103d67c in funcall_lambda (fun=51162085, nargs=0, arg_vector=0x88e474) at eval.c:3211 #19 0x0103ce9c in Ffuncall (nargs=1, args=0x88e470) at eval.c:3070 #20 0x011ef7d8 in Fbyte_code (bytestr=81809201, vector=81013253, maxdepth=88) at bytecode.c:680 #21 0x0103d67c in funcall_lambda (fun=50937029, nargs=0, arg_vector=0x88e774) at eval.c:3211 #22 0x0103ce9c in Ffuncall (nargs=1, args=0x88e770) at eval.c:3070 #23 0x011ef7d8 in Fbyte_code (bytestr=81802801, vector=82790149, maxdepth=20) at bytecode.c:680 #24 0x0103d67c in funcall_lambda (fun=50937349, nargs=3, arg_vector=0x88ea34) at eval.c:3211 #25 0x0103ce9c in Ffuncall (nargs=4, args=0x88ea30) at eval.c:3070 #26 0x011ef7d8 in Fbyte_code (bytestr=81805217, vector=84959173, maxdepth=16) at bytecode.c:680 #27 0x0103d67c in funcall_lambda (fun=50938597, nargs=3, arg_vector=0x88ece4) at eval.c:3211 #28 0x0103ce9c in Ffuncall (nargs=4, args=0x88ece0) at eval.c:3070 #29 0x011ef7d8 in Fbyte_code (bytestr=81009409, vector=50466597, maxdepth=16) at bytecode.c:680 #30 0x0103d67c in funcall_lambda (fun=50464837, nargs=0, arg_vector=0x88ef94) at eval.c:3211 #31 0x0103ce9c in Ffuncall (nargs=1, args=0x88ef90) at eval.c:3070 #32 0x011ef7d8 in Fbyte_code (bytestr=81523921, vector=82526981, maxdepth=64) at bytecode.c:680 #33 0x0103d67c in funcall_lambda (fun=50940261, nargs=3, arg_vector=0x88f274) at eval.c:3211 #34 0x0103ce9c in Ffuncall (nargs=4, args=0x88f270) at eval.c:3070 #35 0x011ef7d8 in Fbyte_code (bytestr=81523921, vector=82526981, maxdepth=64) at bytecode.c:680 #36 0x0103d67c in funcall_lambda (fun=50940261, nargs=3, arg_vector=0x88f554) at eval.c:3211 #37 0x0103ce9c in Ffuncall (nargs=4, args=0x88f550) at eval.c:3070 #38 0x011ef7d8 in Fbyte_code (bytestr=81009361, vector=82654149, maxdepth=20) at bytecode.c:680 #39 0x0103d67c in funcall_lambda (fun=50466757, nargs=2, arg_vector=0x88f864) at eval.c:3211 #40 0x0103ce9c in Ffuncall (nargs=3, args=0x88f860) at eval.c:3070 #41 0x011f4c10 in Fcall_interactively (function=50004498, record_flag=49838082, keys=49859333) at callint.c:869 #42 0x0103ca53 in Ffuncall (nargs=4, args=0x88fb30) at eval.c:3030 #43 0x0103bf25 in call3 (fn=49990114, arg1=50004498, arg2=49838082, arg3=49838082) at eval.c:2850 #44 0x010222a9 in Fcommand_execute (cmd=50004498, record_flag=49838082, keys=49838082, special=49838082) at keyboard.c:10345 #45 0x01008862 in command_loop_1 () at keyboard.c:1756 #46 0x010389aa in internal_condition_case (bfun=0x10072be <command_loop_1>, handlers=49894618, hfun=0x10069e5 <cmd_error>) at eval.c:1490 #47 0x01006ebf in command_loop_2 () at keyboard.c:1356 #48 0x0103842c in internal_catch (tag=49893810, func=0x1006e9a <command_loop_2>, arg=49838082) at eval.c:1226 #49 0x01006e78 in command_loop () at keyboard.c:1335 #50 0x010060f0 in recursive_edit_1 () at keyboard.c:950 #51 0x0100660b in Frecursive_edit () at keyboard.c:1012 #52 0x01002a95 in main (argc=1, argv=0xbe2b58) at emacs.c:1784 Lisp Backtrace: "message" (0x88e1c4) "edebug-previous-result" (0x88e474) "edebug-display" (0x88e774) "edebug-debugger" (0x88ea34) "edebug-after" (0x88ece4) 0x3020845 PVEC_COMPILED "edebug-enter" (0x88f274) "edebug-enter" (0x88f554) "narrow-to-region" (0x88f864) "call-interactively" (0x88fb34) (gdb) ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-19 22:46 ` Juanma Barranquero @ 2010-04-20 8:23 ` Eli Zaretskii 2010-04-20 9:19 ` Juanma Barranquero 2010-04-20 10:21 ` Eli Zaretskii 1 sibling, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2010-04-20 8:23 UTC (permalink / raw) To: Juanma Barranquero; +Cc: david.reitter, 5973 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 20 Apr 2010 00:46:32 +0200 > Cc: David Reitter <david.reitter@gmail.com>, 5973@debbugs.gnu.org > > On Mon, Apr 19, 2010 at 20:26, Eli Zaretskii <eliz@gnu.org> wrote: > > > If not, then I'm afraid we will need to wait for another instance of > > this crash. > > I get a similar crash on Windows (trace attached). Why do you think it is similar? It crashes in a different place, and if in David's case there was a hypothesis that FACE_FROM_ID returned a null pointer, in your case I see that all face arguments are non-NULL. What am I missing? Btw, David's crash was in Emacs 23.1.95, so I'm pretty sure the bidi merge has nothing to do with it. Yours is with the trunk version, right? > I can reproduce it reliably, but it depends on something in my .emacs, > so I cannot give a recipe right now. Please do try to give a reproducible recipe. Btw, what were you doing when it crashed? The backtrace seems to tell that Emacs was displaying a message in the echo area (during an Edebug session?), and that there were characters in the message area that used compositions, is that right? If so, what was the text of the message? If the crash happens even with normal ASCII characters in the echo area, I'd prefer to see a backtrace of that variant. Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-20 8:23 ` Eli Zaretskii @ 2010-04-20 9:19 ` Juanma Barranquero 2010-04-20 9:56 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Juanma Barranquero @ 2010-04-20 9:19 UTC (permalink / raw) To: Bug-Gnu-Emacs; +Cc: david.reitter, 5973 Package: emacs Version: 24.0.50 > Why do you think it is similar? Just because get_next_display_element and move_it_in_display_line_to were involved. Which goes to show how much I know about redisplay :-) I'm filing a separate bug. > What am I missing? My ignorance, of course... > Yours is with the trunk version, right? Yes. > Btw, what were you doing when it crashed? The backtrace seems to tell > that Emacs was displaying a message in the echo area (during an Edebug > session?), and that there were characters in the message area that used > compositions, is that right? If so, what was the text of the message? I was debugging a simple defadvice to narrow-to-region. The "text" of the message is edebug trying to display END (the argument to n-t-r). I can reproduce the bug with just this advice: (defadvice narrow-to-region (before heisenbug activate) end) I instrument it with C-u C-M-x, then C-h N to show NEWS, select a few lines and C-x n n. I get a message "Loading c:/emacs/lisp/international/uni-category.el (source)...done" and then the crash. > If the crash happens even with normal ASCII characters in the echo > area, I'd prefer to see a backtrace of that variant. No, that's the only way I know to trigger it. Juanma ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-20 9:19 ` Juanma Barranquero @ 2010-04-20 9:56 ` Eli Zaretskii 2010-04-20 10:27 ` Juanma Barranquero 0 siblings, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2010-04-20 9:56 UTC (permalink / raw) To: Juanma Barranquero; +Cc: david.reitter, 5973 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 20 Apr 2010 11:19:44 +0200 > Cc: Eli Zaretskii <eliz@gnu.org>, david.reitter@gmail.com, 5973@debbugs.gnu.org > > I was debugging a simple defadvice to narrow-to-region. The "text" of > the message is edebug trying to display END (the argument to n-t-r). I > can reproduce the bug with just this advice: > > (defadvice narrow-to-region (before heisenbug activate) > end) > > I instrument it with C-u C-M-x Instrument what? the defadvice, or something else? > then C-h N to show NEWS, select a few lines and C-x n n. Which lines did you select? I think this is important, because when a form is evaluated, Edebug displays in the echo area a message showing the result of the evaluation, and if the result is a number, it tries to display it as a character. So the end of the region you select determines what character will Edebug try to display. > I get a message "Loading c:/emacs/lisp/international/uni-category.el > (source)...done" and then the crash. I don't see this message, perhaps because I used a different region. I see all kinds of characters displayed, depending on what region I select, but no crash. Here's one example Result: 784 (#o1420, #x310, ?̐) I'm guessing that the crash is somehow related to display of composite characters (hint: try "C-u C-x =" on the weirdo question mark above), which the bidi display does not handle correctly yet. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-20 9:56 ` Eli Zaretskii @ 2010-04-20 10:27 ` Juanma Barranquero 2010-04-20 12:31 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Juanma Barranquero @ 2010-04-20 10:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: david.reitter, 5973 On Tue, Apr 20, 2010 at 11:56, Eli Zaretskii <eliz@gnu.org> wrote: > Instrument what? the defadvice, or something else? The defadvice. In previous versions, the advice had more code, and when you stepped through it, it crashed when trying to display the value of END. With the shortened version, you don't get to step into anything. As soon as the instrumented advice triggers, blam! > Which lines did you select? I think this is important, because > when a form is evaluated, Edebug displays in the echo area a message > showing the result of the evaluation, and if the result is a number, > it tries to display it as a character. So the end of the region you > select determines what character will Edebug try to display. A few lines at the start of the file, usually about ten or twenty. AFAICS, the start of etc/NEWS does not contain any composable character, just straight ASCII. > I don't see this message, perhaps because I used a different region. I use `force-load-messages' set to t. Hmm. I got a reproducible recipe with -Q emacs -Q M-: (setq force-load-messages t) <RET> C-x C-f bug.el <RET> ;; the file containing just the defadvice C-u C-M-x C-h n ;; select line 22 C-x n n Juanma ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-20 10:27 ` Juanma Barranquero @ 2010-04-20 12:31 ` Eli Zaretskii 2010-04-20 13:36 ` Juanma Barranquero 2010-04-20 13:56 ` Juanma Barranquero 0 siblings, 2 replies; 19+ messages in thread From: Eli Zaretskii @ 2010-04-20 12:31 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 5973 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 20 Apr 2010 12:27:00 +0200 > Cc: david.reitter@gmail.com, 5973@debbugs.gnu.org > > AFAICS, the start of etc/NEWS does not contain any composable > character, just straight ASCII. The contents of NEWS have nothing to do with this, I think. The problematic characters do not come from NEWS, they come from Edebug trying to display a numeric result as a character. At least this is my current theory... > Hmm. I got a reproducible recipe with -Q > > emacs -Q > M-: (setq force-load-messages t) <RET> > C-x C-f bug.el <RET> ;; the file containing just the defadvice > C-u C-M-x > C-h n > ;; select line 22 > C-x n n Right, now I see it as well (except that, the 1st time I use C-x n n, I need to answer the question about it being disabled; the crash happens the next time I invoke C-x n n). So you can forget about all my requests regarding various values in the crashed frame. Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-20 12:31 ` Eli Zaretskii @ 2010-04-20 13:36 ` Juanma Barranquero 2010-04-20 13:56 ` Juanma Barranquero 1 sibling, 0 replies; 19+ messages in thread From: Juanma Barranquero @ 2010-04-20 13:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 5973 On Tue, Apr 20, 2010 at 14:31, Eli Zaretskii <eliz@gnu.org> wrote: > Right, now I see it as well (except that, the 1st time I use C-x n n, > I need to answer the question about it being disabled; Yes, of course. > the crash > happens the next time I invoke C-x n n). Curious. Not so in my case. I answer with <space> and the crash just happens. Juanma ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-20 12:31 ` Eli Zaretskii 2010-04-20 13:36 ` Juanma Barranquero @ 2010-04-20 13:56 ` Juanma Barranquero 1 sibling, 0 replies; 19+ messages in thread From: Juanma Barranquero @ 2010-04-20 13:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 5973 On Tue, Apr 20, 2010 at 14:31, Eli Zaretskii <eliz@gnu.org> wrote: > Right, now I see it as well (except that, the 1st time I use C-x n n, > I need to answer the question about it being disabled; the crash > happens the next time I invoke C-x n n). Filed as bug#5984. Juanma ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-19 22:46 ` Juanma Barranquero 2010-04-20 8:23 ` Eli Zaretskii @ 2010-04-20 10:21 ` Eli Zaretskii 2010-04-20 10:33 ` Juanma Barranquero 1 sibling, 1 reply; 19+ messages in thread From: Eli Zaretskii @ 2010-04-20 10:21 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 5973 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 20 Apr 2010 00:46:32 +0200 > Cc: David Reitter <david.reitter@gmail.com>, 5973@debbugs.gnu.org > > #1 0x012be7c9 in temp_set_point_both (buffer=0x34b6e00, charpos=32, > bytepos=33) at intervals.c:1944 This frame calls `abort' here: /* In a single-byte buffer, the two positions must be equal. */ if (BUF_ZV (buffer) == BUF_ZV_BYTE (buffer) && charpos != bytepos) abort (); It does that on the assumption that if the character and byte positions of the last character in the buffer's accessible area coincide, all the character and byte positions before that must also coincide. So please show what the following GDB commands print in frame #1: (gdb) p buffer->size (gdb) p *buffer->text->beg@34 (gdb) p buffer->text->zv (gdb) p buffer->text->zv_byte (gdb) p buffer->text->z (gdb) p buffer->text->z_byte (gdb) p buffer->text->pt (gdb) p buffer->text->pt_byte (gdb) p buffer->name (gdb) xstring TIA ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-20 10:21 ` Eli Zaretskii @ 2010-04-20 10:33 ` Juanma Barranquero 2010-04-20 12:23 ` Eli Zaretskii 0 siblings, 1 reply; 19+ messages in thread From: Juanma Barranquero @ 2010-04-20 10:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 5973 On Tue, Apr 20, 2010 at 12:21, Eli Zaretskii <eliz@gnu.org> wrote: > So please show what the following GDB commands print in frame #1: > > (gdb) p buffer->size > (gdb) p *buffer->text->beg@34 > (gdb) p buffer->text->zv > (gdb) p buffer->text->zv_byte > (gdb) p buffer->text->z > (gdb) p buffer->text->z_byte > (gdb) p buffer->text->pt > (gdb) p buffer->text->pt_byte > (gdb) p buffer->name > (gdb) xstring (gdb) frame 1 #1 0x012baadd in temp_set_point_both (buffer=0x34ba200, charpos=32, bytepos=33) at intervals.c:1944 1944 abort (); (gdb) p buffer->size $1 = 1073873021 (gdb) p *buffer->text->beg@34 $2 = "Loading c:/Devel/emacs/repo/debug/" (gdb) p buffer->text->zv There is no member named zv. (gdb) p buffer->text->zv_byte There is no member named zv_byte. (gdb) p buffer->text->z $3 = 85 (gdb) p buffer->text->z_byte $4 = 85 (gdb) p buffer->text->pt There is no member named pt. (gdb) p buffer->text->pt_byte There is no member named pt_byte. (gdb) p buffer->name $5 = 52161297 (gdb) xstring $6 = (struct Lisp_String *) 0x31beb10 " *Echo Area 0*" (gdb) Juanma ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#5973: Crash in get_next_display_element 2010-04-20 10:33 ` Juanma Barranquero @ 2010-04-20 12:23 ` Eli Zaretskii 0 siblings, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2010-04-20 12:23 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 5973 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 20 Apr 2010 12:33:27 +0200 > Cc: 5973@debbugs.gnu.org > > (gdb) p *buffer->text->beg@34 > $2 = "Loading c:/Devel/emacs/repo/debug/" How about this? (gdb) p *buffer->text->beg@86 > (gdb) p buffer->text->zv > There is no member named zv. > (gdb) p buffer->text->zv_byte > There is no member named zv_byte. > (gdb) p buffer->text->pt > There is no member named pt. > (gdb) p buffer->text->pt_byte > There is no member named pt_byte. Sorry, copy/paste mistakes. Please try these instead: (gdb) p buffer->zv (gdb) p buffer->zv_byte (gdb) p buffer->pt (gdb) p buffer->pt_byte Thanks. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-04-20 13:56 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-19 16:08 bug#5973: Crash in get_next_display_element David Reitter [not found] ` <handler.5973.B.12716933351499.ack@debbugs.gnu.org> 2010-04-19 16:46 ` bug#5973: Acknowledgement (Crash in get_next_display_element) David Reitter 2010-04-19 17:31 ` Eli Zaretskii 2010-04-19 17:23 ` bug#5973: Crash in get_next_display_element Eli Zaretskii 2010-04-19 17:40 ` David Reitter 2010-04-19 18:26 ` Eli Zaretskii 2010-04-19 18:39 ` David Reitter 2010-04-19 18:43 ` Eli Zaretskii 2010-04-19 22:46 ` Juanma Barranquero 2010-04-20 8:23 ` Eli Zaretskii 2010-04-20 9:19 ` Juanma Barranquero 2010-04-20 9:56 ` Eli Zaretskii 2010-04-20 10:27 ` Juanma Barranquero 2010-04-20 12:31 ` Eli Zaretskii 2010-04-20 13:36 ` Juanma Barranquero 2010-04-20 13:56 ` Juanma Barranquero 2010-04-20 10:21 ` Eli Zaretskii 2010-04-20 10:33 ` Juanma Barranquero 2010-04-20 12:23 ` Eli Zaretskii
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).