* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) @ 2014-06-20 13:42 Ken Brown 2014-06-20 14:21 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Ken Brown @ 2014-06-20 13:42 UTC (permalink / raw) To: 17817 [-- Attachment #1: Type: text/plain, Size: 3246 bytes --] I just got the following assertion failure: bidi.c:329: Emacs fatal error: assertion failed: UNKNOWN_BT <= type && type <= NEUTRAL_ON I wasn't doing anything at the time. I had been away from the computer for a couple days, tried to view an emacs window, and then noticed the assertion failure in the terminal from which I had started emacs under gdb. A full backtrace is attached. I still have the gdb session open. Ken In GNU Emacs 24.3.91.13 (x86_64-unknown-cygwin) of 2014-06-06 on moufang Repository revision: 117213 monnier@iro.umontreal.ca-20140606142539-5h50ienhp3mpz68z Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --with-w32 --enable-checking=yes,glyphs 'CFLAGS=-g3 -O0'' Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Dired by date Minor modes in effect: shell-dirtrack-mode: t show-paren-mode: t display-time-mode: t delete-selection-mode: t tooltip-mode: t electric-indent-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 auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t temp-buffer-resize-mode: t buffer-read-only: t column-number-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow gnus-util mail-extr emacsbug message cl-macs format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils shell pcomplete comint ansi-color ring dired-aux misearch multi-isearch server dired edmacro kmacro solar cal-dst planner-diary cl gv diary-lib diary-loaddefs planner-publish muse-xml planner advice help-fns cal-menu calendar cal-loaddefs sort muse-colors muse-latex muse-html muse-xml-common cus-edit muse-publish muse-project muse-protocols muse-regexps wid-edit cl-loaddefs cl-lib derived muse muse-nested-tags muse-mode gap-mode-autoloads info easymenu muse-autoloads package saveplace paren help-at-pt time delsel cus-start cus-load time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar 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 minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify w32 multi-tty emacs) Memory information: ((conses 16 163739 4162) (symbols 48 25708 0) (miscs 40 101 217) (strings 32 37923 4888) (string-bytes 1 1024471) (vectors 16 17983) (vector-slots 8 456533 2444) (floats 8 437 54) (intervals 56 577 9) (buffers 960 16)) [-- Attachment #2: gdb.txt.xz --] [-- Type: application/octet-stream, Size: 7652 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-20 13:42 bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) Ken Brown @ 2014-06-20 14:21 ` Eli Zaretskii 2014-06-20 14:40 ` Ken Brown 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2014-06-20 14:21 UTC (permalink / raw) To: Ken Brown; +Cc: 17817 > Date: Fri, 20 Jun 2014 14:42:05 +0100 > From: Ken Brown <kbrown@cornell.edu> > > I just got the following assertion failure: > > bidi.c:329: Emacs fatal error: assertion failed: UNKNOWN_BT <= type > && type <= NEUTRAL_ON Is this the same 64-bit Cygwin-w32 build that was reported lately to produce nonsensical backtraces? > #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:351 > No locals. > #1 0x00000001005ba95d in die ( > msg=0x100a2e538 <DEFAULT_REHASH_SIZE+64> "UNKNOWN_BT <= type && type <= NEUTRAL_ON", file=0x100a2e530 <DEFAULT_REHASH_SIZE+56> "bidi.c", line=329) > at alloc.c:6826 > No locals. > #2 0x00000001004fb4fe in bidi_check_type (type=STRONG_L) at bidi.c:329 > No locals. > #3 0x0000000100500630 in bidi_level_of_next_char (bidi_it=0x2267d8) > at bidi.c:2430 > type = STRONG_L > level = 0 > prev_level = 0 > next_for_neutral = { > bytepos = 0, > charpos = -1, > type = UNKNOWN_BT, > type_after_w1 = UNKNOWN_BT, > orig_type = UNKNOWN_BT > } > next_char_pos = 1 This makes no sense at all: STRONG_L is one of the bidi types defined by 'enum bidi_type_t' (see dispextern.h), and therefore its value _must_ be between UNKNOWN_BT (whose value is zero) and NEUTRAL_ON, the last tag in the enumeration type. Can you see the numerical value of 'type' in frame #2? Like this: (gdb) fr 2 (gdb) p type + 0 Also, using a similar technique, display the values of UNKNOWN_BT and of NEUTRAL_ON. Other than that, the backtrace you show is just a normal redisplay cycle. Nothing catches my eye. In particular, the crash was while the display engine was recomputing the mode-line display. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-20 14:21 ` Eli Zaretskii @ 2014-06-20 14:40 ` Ken Brown 2014-06-20 14:47 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Ken Brown @ 2014-06-20 14:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17817 On 6/20/2014 3:21 PM, Eli Zaretskii wrote: >> Date: Fri, 20 Jun 2014 14:42:05 +0100 >> From: Ken Brown <kbrown@cornell.edu> >> >> I just got the following assertion failure: >> >> bidi.c:329: Emacs fatal error: assertion failed: UNKNOWN_BT <= type >> && type <= NEUTRAL_ON > > Is this the same 64-bit Cygwin-w32 build that was reported lately to > produce nonsensical backtraces? Yes. >> #0 terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:351 >> No locals. >> #1 0x00000001005ba95d in die ( >> msg=0x100a2e538 <DEFAULT_REHASH_SIZE+64> "UNKNOWN_BT <= type && type <= NEUTRAL_ON", file=0x100a2e530 <DEFAULT_REHASH_SIZE+56> "bidi.c", line=329) >> at alloc.c:6826 >> No locals. >> #2 0x00000001004fb4fe in bidi_check_type (type=STRONG_L) at bidi.c:329 >> No locals. >> #3 0x0000000100500630 in bidi_level_of_next_char (bidi_it=0x2267d8) >> at bidi.c:2430 >> type = STRONG_L >> level = 0 >> prev_level = 0 >> next_for_neutral = { >> bytepos = 0, >> charpos = -1, >> type = UNKNOWN_BT, >> type_after_w1 = UNKNOWN_BT, >> orig_type = UNKNOWN_BT >> } >> next_char_pos = 1 > > This makes no sense at all: STRONG_L is one of the bidi types defined > by 'enum bidi_type_t' (see dispextern.h), and therefore its value > _must_ be between UNKNOWN_BT (whose value is zero) and NEUTRAL_ON, the > last tag in the enumeration type. > > Can you see the numerical value of 'type' in frame #2? Like this: > > (gdb) fr 2 > (gdb) p type + 0 > Also, using a similar technique, display the values of UNKNOWN_BT and > of NEUTRAL_ON. (gdb) p type + 0 $2 = 1 (gdb) p UNKNOWN_BT + 0 $3 = 0 (gdb) p NEUTRAL_ON + 0 $4 = 23 So, as you said, this is nonsense. Ken ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-20 14:40 ` Ken Brown @ 2014-06-20 14:47 ` Eli Zaretskii 2014-06-20 14:54 ` Ken Brown 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2014-06-20 14:47 UTC (permalink / raw) To: Ken Brown; +Cc: 17817 > Date: Fri, 20 Jun 2014 15:40:28 +0100 > From: Ken Brown <kbrown@cornell.edu> > CC: 17817@debbugs.gnu.org > > (gdb) p type + 0 > $2 = 1 > (gdb) p UNKNOWN_BT + 0 > $3 = 0 > (gdb) p NEUTRAL_ON + 0 > $4 = 23 > > So, as you said, this is nonsense. Yeah. But still, the machine insists the value was bad. Hmmm... Can you show the disassembly of bidi_check_type? ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-20 14:47 ` Eli Zaretskii @ 2014-06-20 14:54 ` Ken Brown 2014-06-20 16:43 ` Ken Brown 0 siblings, 1 reply; 10+ messages in thread From: Ken Brown @ 2014-06-20 14:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17817 On 6/20/2014 3:47 PM, Eli Zaretskii wrote: >> Date: Fri, 20 Jun 2014 15:40:28 +0100 >> From: Ken Brown <kbrown@cornell.edu> >> CC: 17817@debbugs.gnu.org >> >> (gdb) p type + 0 >> $2 = 1 >> (gdb) p UNKNOWN_BT + 0 >> $3 = 0 >> (gdb) p NEUTRAL_ON + 0 >> $4 = 23 >> >> So, as you said, this is nonsense. > > Yeah. But still, the machine insists the value was bad. Hmmm... > > Can you show the disassembly of bidi_check_type? (gdb) disas bidi_check_type Dump of assembler code for function bidi_check_type: 0x004d2837 <+0>: push %ebp 0x004d2838 <+1>: mov %esp,%ebp 0x004d283a <+3>: sub $0x18,%esp 0x004d283d <+6>: movzbl 0x9063f8,%eax 0x004d2844 <+13>: xor $0x1,%eax 0x004d2847 <+16>: test %al,%al 0x004d2849 <+18>: je 0x4d286d <bidi_check_type+54> 0x004d284b <+20>: cmpl $0x17,0x8(%ebp) 0x004d284f <+24>: jbe 0x4d286d <bidi_check_type+54> 0x004d2851 <+26>: movl $0x149,0x8(%esp) 0x004d2859 <+34>: movl $0x86cc70,0x4(%esp) 0x004d2861 <+42>: movl $0x86ccbc,(%esp) 0x004d2868 <+49>: call 0x56e818 <die> 0x004d286d <+54>: leave 0x004d286e <+55>: ret End of assembler dump. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-20 14:54 ` Ken Brown @ 2014-06-20 16:43 ` Ken Brown 2014-06-20 18:29 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Ken Brown @ 2014-06-20 16:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17817 On 6/20/2014 10:54 AM, Ken Brown wrote: > On 6/20/2014 3:47 PM, Eli Zaretskii wrote: >>> Date: Fri, 20 Jun 2014 15:40:28 +0100 >>> From: Ken Brown <kbrown@cornell.edu> >>> CC: 17817@debbugs.gnu.org >>> >>> (gdb) p type + 0 >>> $2 = 1 >>> (gdb) p UNKNOWN_BT + 0 >>> $3 = 0 >>> (gdb) p NEUTRAL_ON + 0 >>> $4 = 23 >>> >>> So, as you said, this is nonsense. >> >> Yeah. But still, the machine insists the value was bad. Hmmm... >> >> Can you show the disassembly of bidi_check_type? > > (gdb) disas bidi_check_type > Dump of assembler code for function bidi_check_type: > 0x004d2837 <+0>: push %ebp > 0x004d2838 <+1>: mov %esp,%ebp > 0x004d283a <+3>: sub $0x18,%esp > 0x004d283d <+6>: movzbl 0x9063f8,%eax > 0x004d2844 <+13>: xor $0x1,%eax > 0x004d2847 <+16>: test %al,%al > 0x004d2849 <+18>: je 0x4d286d <bidi_check_type+54> > 0x004d284b <+20>: cmpl $0x17,0x8(%ebp) > 0x004d284f <+24>: jbe 0x4d286d <bidi_check_type+54> > 0x004d2851 <+26>: movl $0x149,0x8(%esp) > 0x004d2859 <+34>: movl $0x86cc70,0x4(%esp) > 0x004d2861 <+42>: movl $0x86ccbc,(%esp) > 0x004d2868 <+49>: call 0x56e818 <die> > 0x004d286d <+54>: leave > 0x004d286e <+55>: ret > End of assembler dump. Sorry, that's from the 32-bit build. Here's the correct one: (gdb) disas bidi_check_type Dump of assembler code for function bidi_check_type: 0x00000001004fb4c3 <+0>: push %rbp 0x00000001004fb4c4 <+1>: mov %rsp,%rbp 0x00000001004fb4c7 <+4>: sub $0x20,%rsp 0x00000001004fb4cb <+8>: mov %ecx,0x10(%rbp) 0x00000001004fb4ce <+11>: mov 0x56402b(%rip),%rax # 0x100a5f500 <.refptr.suppress_checking> 0x00000001004fb4d5 <+18>: movzbl (%rax),%eax 0x00000001004fb4d8 <+21>: xor $0x1,%eax 0x00000001004fb4db <+24>: test %al,%al 0x00000001004fb4dd <+26>: je 0x1004fb4ff <bidi_check_type+60> 0x00000001004fb4df <+28>: cmpl $0x17,0x10(%rbp) 0x00000001004fb4e3 <+32>: jbe 0x1004fb4ff <bidi_check_type+60> 0x00000001004fb4e5 <+34>: mov $0x149,%r8d 0x00000001004fb4eb <+40>: lea 0x53303e(%rip),%rdx # 0x100a2e530 <DEFAULT_REHASH_SIZE+56> 0x00000001004fb4f2 <+47>: lea 0x53303f(%rip),%rcx # 0x100a2e538 <DEFAULT_REHASH_SIZE+64> 0x00000001004fb4f9 <+54>: callq 0x1005ba90b <die> => 0x00000001004fb4fe <+59>: nop 0x00000001004fb4ff <+60>: add $0x20,%rsp 0x00000001004fb503 <+64>: pop %rbp 0x00000001004fb504 <+65>: retq End of assembler dump. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-20 16:43 ` Ken Brown @ 2014-06-20 18:29 ` Eli Zaretskii 2014-06-21 19:14 ` Ken Brown 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2014-06-20 18:29 UTC (permalink / raw) To: Ken Brown; +Cc: 17817 > Date: Fri, 20 Jun 2014 12:43:14 -0400 > From: Ken Brown <kbrown@cornell.edu> > CC: 17817@debbugs.gnu.org > > (gdb) disas bidi_check_type > Dump of assembler code for function bidi_check_type: > 0x00000001004fb4c3 <+0>: push %rbp > 0x00000001004fb4c4 <+1>: mov %rsp,%rbp > 0x00000001004fb4c7 <+4>: sub $0x20,%rsp > 0x00000001004fb4cb <+8>: mov %ecx,0x10(%rbp) > 0x00000001004fb4ce <+11>: mov 0x56402b(%rip),%rax # 0x100a5f500 <.refptr.suppress_checking> > 0x00000001004fb4d5 <+18>: movzbl (%rax),%eax > 0x00000001004fb4d8 <+21>: xor $0x1,%eax > 0x00000001004fb4db <+24>: test %al,%al > 0x00000001004fb4dd <+26>: je 0x1004fb4ff <bidi_check_type+60> > 0x00000001004fb4df <+28>: cmpl $0x17,0x10(%rbp) > 0x00000001004fb4e3 <+32>: jbe 0x1004fb4ff <bidi_check_type+60> So the value compared to 23 (17 hex) is at address %rbp+0x10. What does this display: (gdb) p *(bidi_type_t *)($rbp+0x10) (or maybe you should use %rbp with 64-bit build, I don't know). ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-20 18:29 ` Eli Zaretskii @ 2014-06-21 19:14 ` Ken Brown 2014-06-21 19:30 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Ken Brown @ 2014-06-21 19:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17817 On 6/20/2014 2:29 PM, Eli Zaretskii wrote: >> Date: Fri, 20 Jun 2014 12:43:14 -0400 >> From: Ken Brown <kbrown@cornell.edu> >> CC: 17817@debbugs.gnu.org >> >> (gdb) disas bidi_check_type >> Dump of assembler code for function bidi_check_type: >> 0x00000001004fb4c3 <+0>: push %rbp >> 0x00000001004fb4c4 <+1>: mov %rsp,%rbp >> 0x00000001004fb4c7 <+4>: sub $0x20,%rsp >> 0x00000001004fb4cb <+8>: mov %ecx,0x10(%rbp) >> 0x00000001004fb4ce <+11>: mov 0x56402b(%rip),%rax # 0x100a5f500 <.refptr.suppress_checking> >> 0x00000001004fb4d5 <+18>: movzbl (%rax),%eax >> 0x00000001004fb4d8 <+21>: xor $0x1,%eax >> 0x00000001004fb4db <+24>: test %al,%al >> 0x00000001004fb4dd <+26>: je 0x1004fb4ff <bidi_check_type+60> >> 0x00000001004fb4df <+28>: cmpl $0x17,0x10(%rbp) >> 0x00000001004fb4e3 <+32>: jbe 0x1004fb4ff <bidi_check_type+60> > > So the value compared to 23 (17 hex) is at address %rbp+0x10. What > does this display: > > (gdb) p *(bidi_type_t *)($rbp+0x10) > > (or maybe you should use %rbp with 64-bit build, I don't know). I'm away from the computer where this crash occurred and won't have access to it for the next few days. In the meantime, the recent issue that we discussed on the Cygwin list made me wonder if there's some interaction with Glib that's causing these weird crashes. Even though that particular bug only occurred in the 32-bit case, I'm still suspicious. I think I'll start using --with-file-notification=no for a while, to see if that cuts down on the crash reports. Ken ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-21 19:14 ` Ken Brown @ 2014-06-21 19:30 ` Eli Zaretskii 2014-06-21 19:36 ` Ken Brown 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2014-06-21 19:30 UTC (permalink / raw) To: Ken Brown; +Cc: 17817 > Date: Sat, 21 Jun 2014 15:14:24 -0400 > From: Ken Brown <kbrown@cornell.edu> > CC: 17817@debbugs.gnu.org > > I think I'll start using --with-file-notification=no for a while, to see > if that cuts down on the crash reports. But isn't Glib also pulled in when Emacs is built with GTK? IOW, is --with-file-notification=no enough to remove Glib out of the equation? ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) 2014-06-21 19:30 ` Eli Zaretskii @ 2014-06-21 19:36 ` Ken Brown 0 siblings, 0 replies; 10+ messages in thread From: Ken Brown @ 2014-06-21 19:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 17817 On 6/21/2014 3:30 PM, Eli Zaretskii wrote: >> Date: Sat, 21 Jun 2014 15:14:24 -0400 >> From: Ken Brown <kbrown@cornell.edu> >> CC: 17817@debbugs.gnu.org >> >> I think I'll start using --with-file-notification=no for a while, to see >> if that cuts down on the crash reports. > > But isn't Glib also pulled in when Emacs is built with GTK? > > IOW, is --with-file-notification=no enough to remove Glib out of the > equation? You're right, but at least that will remove Glib from the Cygwin-w32 build. If it improves things, then I'll know it's worth spending some time debugging Glib. Ken ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-06-21 19:36 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-06-20 13:42 bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build) Ken Brown 2014-06-20 14:21 ` Eli Zaretskii 2014-06-20 14:40 ` Ken Brown 2014-06-20 14:47 ` Eli Zaretskii 2014-06-20 14:54 ` Ken Brown 2014-06-20 16:43 ` Ken Brown 2014-06-20 18:29 ` Eli Zaretskii 2014-06-21 19:14 ` Ken Brown 2014-06-21 19:30 ` Eli Zaretskii 2014-06-21 19:36 ` Ken Brown
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).