GNU bug report logs - #17688
24.3.90; segmentation fault in deselect_palette

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: gustav <at> iu.edu, 17688 <at> debbugs.gnu.org
Subject: Re: bug#17688: 24.3.90; segmentation fault in deselect_palette
Date: Thu, 05 Jun 2014 21:29:01 +0300

> Date: Thu, 05 Jun 2014 12:08:36 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: 17688 <at> debbugs.gnu.org
> 
> On 6/4/2014 11:58 AM, Eli Zaretskii wrote:
> >> (gdb) bt full
> >> #0  0x0000000100631d84 in deselect_palette (f=0x0, hdc=0x0)
> >>      at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:123
> >> No locals.
> >> #1  0x0000000100631e53 in release_frame_dc (f=0x0, hdc=0x0)
> >>      at /usr/src/debug/emacs-24.3.90-1/src/w32xfns.c:154
> >>          ret = 0
> >> #2  0x00000001006351f9 in uniscribe_encode_char (
> >>      font=0x101071d30 <bss_sbrk_buffer+6928560>, c=76)
> >>      at /usr/src/debug/emacs-24.3.90-1/src/w32uniscribe.c:585
> >>          context = 0x0
> >>          f = 0x0
> >>          old_font = 0x0
> >>          code = 15
> >>          ch = L"LC"
> >>          len = 1
> >>          items = 0x436980
> >>          nitems = 1
> >>          uniscribe_font = 0x101071d30 <bss_sbrk_buffer+6928560>
> >
> > This backtrace makes no sense: uniscribe_encode_char calls
> > release_frame_dc only if the variable 'context' has a non-NULL value
> > (and then 'f' should also be non-NULL).  But here we see that
> > release_frame_dc is called by uniscribe_encode_char when both
> > 'context' and 'f' are NULL, which cannot happen.  I was about to say
> > that this could be due to compiler optimizations that screw up the
> > backtrace, but then I saw that your Emacs binary was built with -O0.
> > So now I'm stumped how could this happen at all.
> 
> That's been the problem for several months.  People have reported 
> several crashes of the Cygwin-w32 build, always on 64-bit Cygwin, with 
> backtraces that "can't happen".  Can you think of any way to try to 
> track this down?

Tracking this might be hard, unless crashes with the same bogus
backtrace happen fairly frequently.

One thing that strikes me is that I see bss_sbrk_buffer in many places
in the backtrace.  Could it be that the static heap is too small, or
maybe some malloc/free/realloc call for addresses in the static heap
go haywire?

Don't forget the WFSO error message reported by Zdzislaw.  If some
other thread (evidently, from the Cygwin DLL) fails in some way, it
could indeed zero out some memory and cause these "impossible"
backtraces.  So I suggest to ask the Cygwin maintainers to investigate
these messages.

Previous Next

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