* 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).