GNU bug report logs - #17817
24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)

Previous Next

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

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

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

From: Ken Brown <kbrown <at> cornell.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Fri, 20 Jun 2014 14:42:05 +0100

[Message part 1 (text/plain, inline)]

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 <at> 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))

[gdb.txt.xz (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Fri, 20 Jun 2014 17:21:51 +0300

> Date: Fri, 20 Jun 2014 14:42:05 +0100
> From: Ken Brown <kbrown <at> 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.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Fri, 20 Jun 2014 15:40:28 +0100

On 6/20/2014 3:21 PM, Eli Zaretskii wrote:
>> Date: Fri, 20 Jun 2014 14:42:05 +0100
>> From: Ken Brown <kbrown <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Fri, 20 Jun 2014 17:47:05 +0300

> Date: Fri, 20 Jun 2014 15:40:28 +0100
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: 17817 <at> 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?

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Fri, 20 Jun 2014 15:54:16 +0100

On 6/20/2014 3:47 PM, Eli Zaretskii wrote:
>> Date: Fri, 20 Jun 2014 15:40:28 +0100
>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: 17817 <at> 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.

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Fri, 20 Jun 2014 12:43:14 -0400

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 <at> cornell.edu>
>>> CC: 17817 <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Fri, 20 Jun 2014 21:29:57 +0300

> Date: Fri, 20 Jun 2014 12:43:14 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: 17817 <at> 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).

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Sat, 21 Jun 2014 15:14:24 -0400

On 6/20/2014 2:29 PM, Eli Zaretskii wrote:
>> Date: Fri, 20 Jun 2014 12:43:14 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: 17817 <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Sat, 21 Jun 2014 22:30:21 +0300

> Date: Sat, 21 Jun 2014 15:14:24 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: 17817 <at> 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?

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17817 <at> debbugs.gnu.org
Subject: Re: bug#17817: 24.3.91; Assertion failure in bidi.c (Cygwin-w32 build)
Date: Sat, 21 Jun 2014 15:36:44 -0400

On 6/21/2014 3:30 PM, Eli Zaretskii wrote:
>> Date: Sat, 21 Jun 2014 15:14:24 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: 17817 <at> 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 18438 <at> debbugs.gnu.org, aidalgol <at> amuri.net,
 17817 <at> debbugs.gnu.org
Subject: Re: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Sat, 26 Dec 2015 16:37:23 +0100

Ken Brown <kbrown <at> cornell.edu> writes:

> Jon (bug#18769) has already reported on the Cygwin list that he is no
> longer getting bogus assertion failures
> (https://cygwin.com/ml/cygwin/2014-10/msg00485.html).  So I'm
> optimistic.

I think the conclusion of the several threads in these bug reports is
that this was a Cygwin bug?  So I'm closing these bug reports.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 18438 <at> debbugs.gnu.org, aidalgol <at> amuri.net,
 17817 <at> debbugs.gnu.org
Subject: Re: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Sat, 26 Dec 2015 10:43:09 -0500

On 12/26/2015 10:37 AM, Lars Ingebrigtsen wrote:
> Ken Brown <kbrown <at> cornell.edu> writes:
>
>> Jon (bug#18769) has already reported on the Cygwin list that he is no
>> longer getting bogus assertion failures
>> (https://cygwin.com/ml/cygwin/2014-10/msg00485.html).  So I'm
>> optimistic.
>
> I think the conclusion of the several threads in these bug reports is
> that this was a Cygwin bug?  So I'm closing these bug reports.

That's right.  Thanks.

Ken

Previous Next

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