bug#17753: Cygwin emacs-X11 core dump

bug#17753: Cygwin emacs-X11 core dump

[markus.hoenicka]

Hi,

I had to upgrade my box at work from Windows XP to Windows 7. The
latter runs the 64 bit version of Cygwin, whereas the former ran the
32 bit version. I've never experienced any Emacs crashes of the 32 bit
version in years. Since upgrading I noticed approx. one crash per
day. As suggested on the Cygwin list [1], I've upgraded to a test
release of Emacs. The crash frequency is now close to once in two
weeks. As I started to collect crash data only about two weeks ago, it
is too early to search for patterns or for ways to reproduce the
crashes. This is also why I can't offer backtraces after starting
Emacs with the -Q switch. I hope that someone can make sense of the
backtrace data anyway.

I'll be happy to provide further information and run tests if needed.

regards,
Markus

System information
Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1
uname -a output:
CYGWIN_NT-6.1 SBHC123 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 Cygwin

Installed Emacs packages:
emacs                                 24.3.90-1
emacs-debuginfo                       24.3.90-1
emacs-el                              24.3.90-1
emacs-X11                             24.3.90-1

In GNU Emacs 24.3.90.1 (x86_64-unknown-cygwin, GTK+ Version 3.10.7)
of 2014-05-03 on fiona
Windowing system distributor `The Cygwin/X Project', version 11.0.11501000
Configured using:
`configure
--srcdir=/home/kbrown/src/cygemacs/emacs-24.3.90-1.x86_64/src/emacs-24.3.90
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/emacs --htmldir=/usr/share/doc/emacs/html -C
--without-gconf --without-gsettings 'CFLAGS=-ggdb -O2 -pipe
-Wimplicit-function-declaration -O0
-fdebug-prefix-map=/home/kbrown/src/cygemacs/emacs-24.3.90-1.x86_64/build=/usr/src/debug/emacs-24.3.90-1
-fdebug-prefix-map=/home/kbrown/src/cygemacs/emacs-24.3.90-1.x86_64/src/emacs-24.3.90=/usr/src/debug/emacs-24.3.90-1'
CPPFLAGS= LDFLAGS=-Wl,--stack,0x400000'

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-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-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Features:
(shadow mail-extr emacsbug message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mail-utils wrolo-menu lmenu noutline
outline help-mode mule-util cal-move warnings erc-list erc-menu erc-join
erc-ring erc-networks erc-pcomplete pcomplete comint ansi-color ring
erc-track erc-match erc-button erc-fill erc-stamp erc-netsplit
erc-goodies erc erc-backend erc-compat format-spec auth-source eieio
byte-opt bytecomp byte-compile cconv eieio-core gnus-util mm-util
mail-prsvr password-cache thingatpt pp muse-backlink planner-cyclic
diary-lib diary-loaddefs planner-publish muse-xml planner advice
help-fns sort muse-colors muse-html muse-xml-common muse-publish
muse-project muse-protocols info muse-regexps muse muse-nested-tags
muse-mode wrolo htz cal-julian cal-menu calendar cal-loaddefs hmail
hversion hfyview cl-macs gv htmlfontify cus-edit cus-start cus-load
wid-edit cl cl-loaddefs cl-lib refdb-output-mode derived refdb-mode
easy-mmode easymenu server time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd 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 dynamic-setting font-render-setting move-toolbar
gtk x-toolkit x multi-tty emacs)

How to reproduce
This is the tricky part as mentioned above. On the occasion recorded
below I was simply typing text.

Backtraces

(gdb) bt full
#0  0x0000003300001fa4 in ?? ()
No symbol table info available.
#1  0x0000000100a49832 in bss_sbrk_buffer ()
No symbol table info available.
#2  0x000000000042ccf0 in ?? ()
No symbol table info available.
#3  0x0000000000000004 in ?? ()
No symbol table info available.
#4  0x0000000101013c48 in bss_sbrk_buffer ()
No symbol table info available.
#5  0x0000000000425170 in ?? ()
No symbol table info available.
#6  0x000000010052b64d in CHAR_TABLE_REF (
    ct=<error reading variable: Cannot access memory at address 0x4251a000000010>,
    ct@entry=<error reading variable: Cannot access memory at address 0x4251a000000008>,
    idx=<error reading variable: Cannot access memory at address 0x4251a000000018>) at /usr/src/debug/emacs-24.3.90-1/src/lisp.h:1468
No locals.
(gdb) xbacktrace
Undefined command: "xbacktrace".  Try "help".


[1] https://cygwin.com/ml/cygwin/2014-05/msg00047.html

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Mon, 9 Jun 2014 23:55:32 +0200
> From: markus.hoenicka@mhoenicka.de
> 
> As I started to collect crash data only about two weeks ago, it
> is too early to search for patterns or for ways to reproduce the
> crashes. This is also why I can't offer backtraces after starting
> Emacs with the -Q switch. I hope that someone can make sense of the
> backtrace data anyway.

Thanks.  Your backtrace looks strange: was that binary stripped or
something?  Why does the backtrace end at CHAR_TABLE_REF, which is a
very internal function?  Why the "??" in the backtrace?

Are you sure you were in the right thread when you collected the
backtrace?

> I'll be happy to provide further information and run tests if needed.

A this point, we need as many informative backtraces as you can
provide.

(Btw, the other Cygwin-64 related crashes were in the w32 build, not a
GTK build of the Cygwin Emacs.)

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-06-11 04:51, schrieb Eli Zaretskii:
>> Date: Mon, 9 Jun 2014 23:55:32 +0200
>> From: markus.hoenicka@mhoenicka.de
>> 
>> As I started to collect crash data only about two weeks ago, it
>> is too early to search for patterns or for ways to reproduce the
>> crashes. This is also why I can't offer backtraces after starting
>> Emacs with the -Q switch. I hope that someone can make sense of the
>> backtrace data anyway.
> 
> Thanks.  Your backtrace looks strange: was that binary stripped or
> something?  Why does the backtrace end at CHAR_TABLE_REF, which is a
> very internal function?  Why the "??" in the backtrace?
> 
> Are you sure you were in the right thread when you collected the
> backtrace?
> 

No, I'm not sure at all. How do I find out? When I start gdb, I see the 
following:

$ gdb /usr/bin/emacs-X11.exe emacs-X11.exe.core
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
[... copyright blurb ...]
Reading symbols from /usr/bin/emacs-X11.exe...Reading symbols from 
/usr/lib/debug/usr/bin/emacs-X11.exe.dbg...done.
done.

warning: core file may not match specified executable file.
[New Thread 0x6d8]
[New Thread 0x64c]
[New Thread 0xda0]
[New Thread 0xf34]
[New Thread 0x8dc]
[New Thread 0xc20]
[New Thread 0x8fc]
[New Thread 0xb48]
[New Thread 0xe14]
#0  0x0000003300001fa4 in ?? ()

This is where I type "bt" or "bt full".

>> I'll be happy to provide further information and run tests if needed.
> 
> A this point, we need as many informative backtraces as you can
> provide.
> 
> (Btw, the other Cygwin-64 related crashes were in the w32 build, not a
> GTK build of the Cygwin Emacs.)

Yes, I'm aware of that. This is why I felt compelled to report crash 
data from emacs-X11.exe as well.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Wed, 11 Jun 2014 08:16:39 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: 17753@debbugs.gnu.org
> 
> > Are you sure you were in the right thread when you collected the
> > backtrace?
> > 
> 
> No, I'm not sure at all. How do I find out?

"info threads" will display all the threads.  "thread apply all bt"
will produce a backtrace for every thread.

bug#17753: Cygwin emacs-X11 core dump

[markus.hoenicka]

Eli Zaretskii writes:
 > > Date: Wed, 11 Jun 2014 08:16:39 +0200
 > > From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
 > > Cc: 17753@debbugs.gnu.org
 > > 
 > > > Are you sure you were in the right thread when you collected the
 > > > backtrace?
 > > > 
 > > 
 > > No, I'm not sure at all. How do I find out?
 > 
 > "info threads" will display all the threads.  "thread apply all bt"
 > will produce a backtrace for every thread.

Ok, here goes:

(gdb) info threads
  Id   Target Id         Frame
  9    Thread 0xe14      0x0004003300001f80 in ?? ()
  8    Thread 0xb48      0x9e84003300001f80 in ?? ()
  7    Thread 0x8fc      0x0005003300001f80 in ?? ()
  6    Thread 0xc20      0x0005003300001f80 in ?? ()
  5    Thread 0x8dc      0x0000003300001f80 in ?? ()
  4    Thread 0xf34      0x0000003300001f80 in ?? ()
  3    Thread 0xda0      0x0000003300001f80 in ?? ()
  2    Thread 0x64c      0x0000003300001f80 in ?? ()
* 1    Thread 0x6d8      0x0000003300001fa4 in ?? ()
(gdb) thread apply all bt

Thread 9 (Thread 0xe14):
#0  0x0004003300001f80 in ?? ()
#1  0x0000000000000000 in ?? ()

Thread 8 (Thread 0xb48):
#0  0x9e84003300001f80 in ?? ()
#1  0x000007fefd5410dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x8fc):
#0  0x0005003300001f80 in ?? ()
#1  0x000007fefd5410dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 6 (Thread 0xc20):
#0  0x0005003300001f80 in ?? ()
#1  0x000007fefd5410dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x8dc):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd5411a2 in ?? ()
---Type <return> to continue, or q <return> to quit---
#2  0x00000000035caba8 in ?? ()
#3  0x0000000600042280 in ?? ()
#4  0x0000000000000003 in ?? ()
#5  0x00000001802de988 in ?? ()
#6  0x00000000000000c6 in ?? ()
#7  0x000000018010bc01 in ?? ()
#8  0x0000000000000048 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 4 (Thread 0xf34):
#0  0x0000003300001f80 in ?? ()
Cannot access memory at address 0xffffc458

(gdb) thread apply 3 bt

Thread 3 (Thread 0xda0):
#0  0x0000003300001f80 in ?? ()
#1  0x00000000774fb037 in ?? ()
#2  0x0000000000000002 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) thread apply 2 bt

Thread 2 (Thread 0x64c):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd541a7a in ?? ()
#2  0x000000000042ce00 in ?? ()
#3  0x0000000100629773 in run_timers ()
    at /usr/src/debug/emacs-24.3.90-1/src/atimer.c:364
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread apply 1 bt

Thread 1 (Thread 0x6d8):
#0  0x0000003300001fa4 in ?? ()
#1  0x0000000100a49832 in bss_sbrk_buffer ()
#2  0x000000000042ccf0 in ?? ()
#3  0x0000000000000004 in ?? ()
#4  0x0000000101013c48 in bss_sbrk_buffer ()
#5  0x0000000000425170 in ?? ()
#6  0x000000010052b64d in CHAR_TABLE_REF (
    ct=<error reading variable: Cannot access memory at address 0x4251a000000010>,
    ct@entry=<error reading variable: Cannot access memory at address 0x4251a000000008>,
    idx=<error reading variable: Cannot access memory at address 0x4251a000000018>) at /usr/src/debug/emacs-24.3.90-1/src/lisp.h:1468


As for thread 2 I'd like to mention that there were several hints on
the Cygwin list that 64 bit Emacs has a timer-related problem, see
e.g. the thread around this post:

https://cygwin.com/ml/cygwin/2014-05/msg00419.html

In brief, I've noticed several error messages in a previous version of
64 bit Cygwin Emacs that did not cause Emacs to crash but indicated
timer-related malfunctions anyway:

Args out of range: [t 21335 39727 373923 0.5 blink-cursor-timer-function nil nil 100000], 4


Invalid function: #[(timer) "^H >^H

    ^[\211^203^Q^@Ã^H	    \"^Q^K\203^Z^@Ã^H

\"^R^L\206^_^@^K*\207" [timer timer-list timer-idle-list cell2 cell1 delq] 4 2245674]


timer-relative-time: Wrong type argument: vectorp, [t1 time high low micro pico nil 3 0 2 ...]

I've never noticed any of these messages on the other 64 bit platforms
that I use Emacs on, i.e. FreeBSD 10 and Debian testing.

Hope this helps
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 6/10/2014 10:51 PM, Eli Zaretskii wrote:
> Thanks.  Your backtrace looks strange: was that binary stripped or
> something?

The debugging symbols were stripped to an external file, 
/usr/lib/debug/usr/bin/emacs-X11.exe.dbg.  Markus's followup message 
indicates that the symbols were indeed read from that file.  But gdb 
also said, "warning: core file may not match specified executable file." 
  I don't know what that's all about.  I've never tried to debug a core 
file (as opposed to a running process) on Cygwin, so I have no insight 
into what could be going one.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Wed, 11 Jun 2014 08:28:36 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: 17753@debbugs.gnu.org
> 
> The debugging symbols were stripped to an external file, 
> /usr/lib/debug/usr/bin/emacs-X11.exe.dbg.  Markus's followup message 
> indicates that the symbols were indeed read from that file.  But gdb 
> also said, "warning: core file may not match specified executable file." 
>   I don't know what that's all about.  I've never tried to debug a core 
> file (as opposed to a running process) on Cygwin, so I have no insight 
> into what could be going one.

Me neither, so perhaps ask on the Cygwin list.  I did see such
messages on GNU/Linux, and could generally disregard them then.

bug#17753: Cygwin emacs-X11 core dump

[markus.hoenicka]

Hi again,

today I witnessed the second coredump of Cygwin emacs-x11.exe (64
bit). The setup is the same as reported previously in this thread. The
backtraces have some striking similarities:

(gdb) info threads
  Id   Target Id         Frame
  9    Thread 0xd70      0x0004003300001f80 in ?? ()
  8    Thread 0xee8      0x9e84003300001f80 in ?? ()
  7    Thread 0x498      0x0005003300001f80 in ?? ()
  6    Thread 0x85c      0x0005003300001f80 in ?? ()
  5    Thread 0xe34      0x0000003300001f80 in ?? ()
  4    Thread 0xd9c      0x0000003300001f80 in ?? ()
  3    Thread 0x184      0x0000003300001f80 in ?? ()
  2    Thread 0x2d8      0x0000003300001f80 in ?? ()
* 1    Thread 0x2e8      0x0000003300001fa4 in ?? ()

(gdb) thread apply all bt

Thread 9 (Thread 0xd70):
#0  0x0004003300001f80 in ?? ()
#1  0x0000000000000000 in ?? ()

Thread 8 (Thread 0xee8):
#0  0x9e84003300001f80 in ?? ()
#1  0x000007fefd0c10dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x498):
#0  0x0005003300001f80 in ?? ()
#1  0x000007fefd0c10dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 6 (Thread 0x85c):
#0  0x0005003300001f80 in ?? ()
#1  0x000007fefd0c10dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 5 (Thread 0xe34):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd0c1203 in ?? ()
#2  0x00000000033aaba8 in ?? ()
#3  0x0000000600042280 in ?? ()
#4  0x0000000000000003 in ?? ()
#5  0x00000001802de988 in ?? ()
#6  0xfffffffffffe7960 in ?? ()
#7  0x00000000033aab10 in ?? ()
#8  0x0000000000000048 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 4 (Thread 0xd9c):
#0  0x0000003300001f80 in ?? ()
Cannot access memory at address 0xffffc458
(gdb) thread apply 3 bt

Thread 3 (Thread 0x184):
#0  0x0000003300001f80 in ?? ()
#1  0x000000007705b037 in ?? ()
#2  0x0000000000000002 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) thread apply 2 bt

Thread 2 (Thread 0x2d8):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd0c1a7a in ?? ()
#2  0x000000000042ce00 in ?? ()
#3  0x0000000100629773 in run_timers ()
    at /usr/src/debug/emacs-24.3.90-1/src/atimer.c:364
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread apply 1 bt

Thread 1 (Thread 0x2e8):
#0  0x0000003300001fa4 in ?? ()
#1  0x0000000000427870 in ?? ()
#2  0x0000000000427218 in ?? ()
#3  0x00000000004271a0 in ?? ()
#4  0x0000000100a49832 in bss_sbrk_buffer ()
#5  0x0000000000363000 in ?? ()
#6  0x0000000077058f34 in ?? ()
#7  0x0000000000430000 in ?? ()
#8  0x000000010097a5c0 in ?? ()
#9  0xffffffff0000e118 in ?? ()
#10 0x00000000005e6e30 in ?? ()
#11 0x000000060230e8a1 in ?? ()
#12 0xffffffffffffffff in ?? ()
#13 0x0000000000000000 in ?? ()

Thread 1 looks a bit different to me this time, but the remaining
threads look like copies of the first crash.

This time the crash occurred while I was publishing my planner pages
to xhtml.

I'm aware that you won't be able to do much unless I provide a recipe
to reproduce the bug. This looks impossible to me. The second crash
occurred roughly 4 weeks after the first one. I run Cygwin Emacs
roughly 10 h a day, so I experience one crash in like 200 h. Also, as
I have to use Emacs productively at my dayjob, I won't be able to run
emacs-x11 -Q for weeks in order to see if any of my customizations
interfere.

Please let me know if I can pull any additional knowledge from these
coredumps.


regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 7/4/2014 5:21 PM, markus.hoenicka@mhoenicka.de wrote:
> I'm aware that you won't be able to do much unless I provide a recipe
> to reproduce the bug. This looks impossible to me. The second crash
> occurred roughly 4 weeks after the first one. I run Cygwin Emacs
> roughly 10 h a day, so I experience one crash in like 200 h. Also, as
> I have to use Emacs productively at my dayjob, I won't be able to run
> emacs-x11 -Q for weeks in order to see if any of my customizations
> interfere.
>
> Please let me know if I can pull any additional knowledge from these
> coredumps.

I don't see anything that we can get from this, but please keep 
reporting the crashes.  Maybe we'll eventually get a backtrace that 
makes sense or a recipe for producing the crash.

Ken

bug#17753: Cygwin emacs-X11 core dump

[markus.hoenicka]

Ken Brown writes:
 > On 7/4/2014 5:21 PM, markus.hoenicka@mhoenicka.de wrote:
 > > I'm aware that you won't be able to do much unless I provide a recipe
 > > to reproduce the bug. This looks impossible to me. The second crash
 > > occurred roughly 4 weeks after the first one. I run Cygwin Emacs
 > > roughly 10 h a day, so I experience one crash in like 200 h. Also, as
 > > I have to use Emacs productively at my dayjob, I won't be able to run
 > > emacs-x11 -Q for weeks in order to see if any of my customizations
 > > interfere.
 > >
 > > Please let me know if I can pull any additional knowledge from these
 > > coredumps.
 > 
 > I don't see anything that we can get from this, but please keep 
 > reporting the crashes.  Maybe we'll eventually get a backtrace that 
 > makes sense or a recipe for producing the crash.
 > 
 > Ken

Ok. My Emacs suffered from a bad hair day today - two crashes in a
row. Crash #1 happened while I was marking a region, I pressed the
down arrow key repeatedly when Emacs died. Crash #2 happened after I
published my planner pages to xhtml, the output page was written
ok. Crash #1 resulted in the familiar backtrace. Crash #2 was
different but I'm afraid the backtrace is even less informative.

regards,
Markus

Crash #1
(gdb) info threads
  Id   Target Id         Frame
  9    Thread 0x264      0x0004003300001f80 in ?? ()
  8    Thread 0x1090     0x9e84003300001f80 in ?? ()
  7    Thread 0x1174     0x0005003300001f80 in ?? ()
  6    Thread 0x116c     0x0005003300001f80 in ?? ()
  5    Thread 0x1168     0x0000003300001f80 in ?? ()
  4    Thread 0x1164     0x0000003300001f80 in ?? ()
  3    Thread 0x1160     0x0000003300001f80 in ?? ()
  2    Thread 0x115c     0x0000003300001f80 in ?? ()
* 1    Thread 0x1124     0x0000003300001fa4 in ?? ()
(gdb) thread apply all bt

Thread 9 (Thread 0x264):
#0  0x0004003300001f80 in ?? ()
#1  0x0000000000000000 in ?? ()

Thread 8 (Thread 0x1090):
#0  0x9e84003300001f80 in ?? ()
#1  0x000007fefd0610dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x1174):
#0  0x0005003300001f80 in ?? ()
#1  0x000007fefd0610dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 6 (Thread 0x116c):
#0  0x0005003300001f80 in ?? ()
#1  0x000007fefd0610dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x1168):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd061203 in ?? ()
#2  0x000000000310aba8 in ?? ()
#3  0x0000000600042280 in ?? ()
#4  0x0000000000000003 in ?? ()
#5  0x00000001802de988 in ?? ()
#6  0xfffffffffffe7960 in ?? ()
#7  0x000000000310ab10 in ?? ()
#8  0x0000000000000048 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x1164):
#0  0x0000003300001f80 in ?? ()
Cannot access memory at address 0xffffc458

(gdb) thread apply 3 bt

Thread 3 (Thread 0x1160):
#0  0x0000003300001f80 in ?? ()
#1  0x0000000076f7b037 in ?? ()
#2  0x0000000000000002 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) thread apply 2 bt

Thread 2 (Thread 0x115c):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd061a7a in ?? ()
#2  0x000000000042ce00 in ?? ()
#3  0x0000000100629773 in run_timers ()
    at /usr/src/debug/emacs-24.3.90-1/src/atimer.c:364
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread apply 1 bt

Thread 1 (Thread 0x1124):
#0  0x0000003300001fa4 in ?? ()
#1  0x0000000000430000 in ?? ()
#2  0x000000010097a38c in ?? ()
#3  0xffffffff0000e118 in ?? ()
#4  0x00000000005a6e30 in ?? ()
#5  0x0000000000424760 in ?? ()
#6  0x000000010052c737 in set_string_intervals (
    s=<error reading variable: Cannot access memory at address 0x42a84000000010>,
    s@entry=<error reading variable: Cannot access memory at address 0x42a84000000008>,
    i=<error reading variable: Cannot access memory at address 0x42a84000000018>) at /usr/src/debug/emacs-24.3.90-1/src/lisp.h:3278


Crash #2
(gdb) info threads
  Id   Target Id         Frame
  9    Thread 0x538      0x0004003300001f80 in ?? ()
  8    Thread 0x17e8     0x2948003300001f80 in ?? ()
  7    Thread 0x15d4     0x0000003300001f80 in ?? ()
  6    Thread 0xca4      0x0000003300001f80 in ?? ()
  5    Thread 0x388      0x0000003300001f80 in ?? ()
  4    Thread 0x1314     0x0000003300001f80 in ?? ()
  3    Thread 0x172c     0x0000003300001f80 in ?? ()
  2    Thread 0xbc0      0x0000003300001f80 in ?? ()
* 1    Thread 0x1454     0x0000003300001fa4 in ?? ()
(gdb) thread apply all bt

Thread 9 (Thread 0x538):
#0  0x0004003300001f80 in ?? ()
#1  0x0000000000000000 in ?? ()

Thread 8 (Thread 0x17e8):
#0  0x2948003300001f80 in ?? ()
#1  0x000007fefd0610dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x15d4):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd0610dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 6 (Thread 0xca4):
#0  0x0000003300001f80 in ?? ()
#1  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x388):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd061203 in ?? ()
#2  0x000000000357aba8 in ?? ()
#3  0x0000000600042280 in ?? ()
#4  0x0000000000000003 in ?? ()
#5  0x00000001802de618 in ?? ()
#6  0xfffffffffffe7960 in ?? ()
#7  0x000000000357ab10 in ?? ()
#8  0x0000000000000048 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x1314):
#0  0x0000003300001f80 in ?? ()
Cannot access memory at address 0xffffc458
(gdb) thread apply 3 bt

Thread 3 (Thread 0x172c):
#0  0x0000003300001f80 in ?? ()
#1  0x0000000076f7b037 in ?? ()
#2  0x0000000000000002 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) thread apply 2 bt

Thread 2 (Thread 0xbc0):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefd061a7a in ?? ()
#2  0x000000000042ce00 in ?? ()
#3  0x000000018006f5c0 in ?? ()
#4  0x00000001802dc938 in ?? ()
#5  0x0000000000000000 in ?? ()
(gdb) thread apply 1 bt

Thread 1 (Thread 0x1454):
#0  0x0000003300001fa4 in ?? ()
#1  0x000007fefd061203 in ?? ()
#2  0x0000000000425308 in ?? ()
#3  0x00000000004253c0 in ?? ()
#4  0x0000000000425428 in ?? ()
#5  0x0000000000000001 in ?? ()
#6  0xffffffffffffd8f0 in ?? ()
#7  0x0000000000425270 in ?? ()
#8  0x0000000000000048 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x0000000000000000 in ?? ()

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 7/7/2014 5:31 PM, markus.hoenicka@mhoenicka.de wrote:
> Ok. My Emacs suffered from a bad hair day today - two crashes in a
> row. Crash #1 happened while I was marking a region, I pressed the
> down arrow key repeatedly when Emacs died. Crash #2 happened after I
> published my planner pages to xhtml, the output page was written

A bug in the Cygwin DLL (64-bit only) was just discovered and fixed. 
The bug could have prevented stack space from being committed after the 
initial commit.  Could you try the latest snapshot from 
https://cygwin.com/snapshots/ and see if these strange crashes stop?  I 
realize that you may have to run emacs for several weeks before you can 
be confident.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-07-09 15:57, schrieb Ken Brown:
> On 7/7/2014 5:31 PM, markus.hoenicka@mhoenicka.de wrote:
>> Ok. My Emacs suffered from a bad hair day today - two crashes in a
>> row. Crash #1 happened while I was marking a region, I pressed the
>> down arrow key repeatedly when Emacs died. Crash #2 happened after I
>> published my planner pages to xhtml, the output page was written
> 
> A bug in the Cygwin DLL (64-bit only) was just discovered and fixed.
> The bug could have prevented stack space from being committed after
> the initial commit.  Could you try the latest snapshot from
> https://cygwin.com/snapshots/ and see if these strange crashes stop?
> I realize that you may have to run emacs for several weeks before you
> can be confident.
> 
> Ken

Hi,

I installed the cygwin1.dll snapshot. I'll let you know what happens.

The 200 h MTBF estimate might just have been a streak of luck: I 
reported two crashes in a row on July 7, and another one occurred on 
July 8 but I didn't get round to report that one yet. We might actually 
find out sooner than in a couple of weeks if the snapshot does *not* fix 
the problem. If it does, it'll take a little longer to be confident as 
you already mentioned.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

[I'm sending this through webmail, so please excuse that I was not able 
to keep the context of this thread]

Hi,

following Ken's suggestion I started running Cygwin's emacs-X11 from gdb 
a couple of weeks ago. Today Emacs finally crashed, and gdb seems to 
reveal some more information than the previous core dumps. Please let me 
know if the stuff below is of any help. The crash occurred while I was 
moving down a planner-mode buffer using the page down key.

I tried to save a core file for future analysis, but gdb wouldn't let 
me, causing the following error:

(gdb) generate-core-file
warning: cannot close "core.5044": Invalid operation
Can't create a corefile

Is that a known Cygwin limitation? In any case, I'll try to keep gdb 
open for a while. I'll be happy to run additional gdb commands as you 
see fit.

regards,
Markus

Program received signal SIGSEGV, Segmentation fault.
0x00000005e20450f0 in cygfontconfig-1!FcObjectLookupOtherTypeById ()
    from /usr/bin/cygfontconfig-1.dll
(gdb) info threads
   Id   Target Id         Frame
   9    Thread 5044.0x1024 0x00000000777012fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
   8    Thread 5044.0x1330 0x00000000777012fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
   6    Thread 5044.0x1350 0x00000000777015fa in ntdll!ZwDelayExecution 
()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
   5    Thread 5044.0x132c 0x00000000777012fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
   4    Thread 5044.0x134c 0x000000007770186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/system32/ntdll.dll
   3    Thread 5044.0x1008 0x000000007770186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/system32/ntdll.dll
   2    Thread 5044.0x13f4 0x000000007770131a in ntdll!ZwReadFile ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
* 1    Thread 5044.0x13ac 0x00000005e20450f0 in 
cygfontconfig-1!FcObjectLookupOtherTypeById () from 
/usr/bin/cygfontconfig-1.dll
(gdb) thread apply all bt

Thread 9 (Thread 5044.0x1024):
#0  0x00000000777012fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x000007fefd6d10dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()

Thread 8 (Thread 5044.0x1330):
#0  0x00000000777012fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x000007fefd6d10dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()

Thread 6 (Thread 5044.0x1350):
#0  0x00000000777015fa in ntdll!ZwDelayExecution ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x000007fefd6d1203 in SleepEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000000319aba8 in ?? ()
#3  0x0000000600061f00 in ?? ()
#4  0x0000000000000003 in ?? ()
#5  0x00000001802e8148 in ?? () from /usr/bin/cygwin1.dll
#6  0xfffffffffffe7960 in ?? ()
#7  0x000000000319ab10 in ?? ()
#8  0x0000000000000048 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 5 (Thread 5044.0x132c):
#0  0x00000000777012fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x000007fefd6d10dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()

Thread 4 (Thread 5044.0x134c):
#0  0x000000007770186a in ntdll!ZwWaitForMultipleObjects ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x000007fefd6d1430 in KERNELBASE!GetCurrentProcess ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()

Thread 3 (Thread 5044.0x1008):
#0  0x000000007770186a in ntdll!ZwWaitForMultipleObjects ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x00000000776cb037 in ntdll!TpIsTimerSet ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2  0x0000000000000002 in ?? ()
#3  0x0000000000000000 in ?? ()

Thread 2 (Thread 5044.0x13f4):
#0  0x000000007770131a in ntdll!ZwReadFile ()
    from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1  0x000007fefd6d1a7a in ReadFile ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000000042ce00 in ?? ()
#3  0x0000000100587330 in schedule_atimer ()
     at /usr/src/debug/emacs-24.3.93-1/src/atimer.c:337
#4  0x00000001802df9f8 in ?? () from /usr/bin/cygwin1.dll
#5  0x0000000000000000 in ?? ()

Thread 1 (Thread 5044.0x13ac):
#0  0x00000005e20450f0 in cygfontconfig-1!FcObjectLookupOtherTypeById ()
    from /usr/bin/cygfontconfig-1.dll
#1  0x00000005e20458ed in cygfontconfig-1!FcPatternObjectFindElt ()
    from /usr/bin/cygfontconfig-1.dll
#2  0x0000000000000001 in ?? ()
#3  0x0000000000000003 in ?? ()
#4  0x0000000000423c90 in ?? ()
#5  0x00000006034f3e45 in ?? ()
#6  0x0000000000000000 in ?? ()


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Wed, 17 Sep 2014 11:45:19 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: 17753@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
> Thread 2 (Thread 5044.0x13f4):
> #0  0x000000007770131a in ntdll!ZwReadFile ()
>     from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #1  0x000007fefd6d1a7a in ReadFile ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #2  0x000000000042ce00 in ?? ()
> #3  0x0000000100587330 in schedule_atimer ()
>      at /usr/src/debug/emacs-24.3.93-1/src/atimer.c:337
> #4  0x00000001802df9f8 in ?? () from /usr/bin/cygwin1.dll
> #5  0x0000000000000000 in ?? ()
> 
> Thread 1 (Thread 5044.0x13ac):
> #0  0x00000005e20450f0 in cygfontconfig-1!FcObjectLookupOtherTypeById ()
>     from /usr/bin/cygfontconfig-1.dll
> #1  0x00000005e20458ed in cygfontconfig-1!FcPatternObjectFindElt ()
>     from /usr/bin/cygfontconfig-1.dll
> #2  0x0000000000000001 in ?? ()
> #3  0x0000000000000003 in ?? ()
> #4  0x0000000000423c90 in ?? ()
> #5  0x00000006034f3e45 in ?? ()
> #6  0x0000000000000000 in ?? ()

It looks like your GDB is still unable to read the symbolic debug info
for some reason.

Anyway, one thing that strikes me (and is consistent across all your
reports until now) is that atimer.c functions are run from a separate
thread, not the main thread (which is Thread 1).  Ken, is this normal
in the Cygwin-w32 build?

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Wed, 17 Sep 2014 13:16:43 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 17753@debbugs.gnu.org
> 
> Anyway, one thing that strikes me (and is consistent across all your
> reports until now) is that atimer.c functions are run from a separate
> thread, not the main thread (which is Thread 1).  Ken, is this normal
> in the Cygwin-w32 build?

Actually, this is not a Cygwin-w32 build, this is a Cygwin-X11 build,
isn't it?  In which case I think the fact that atimers run from a
different thread is even more strange.

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-09-17 12:52, schrieb Eli Zaretskii:
>> Date: Wed, 17 Sep 2014 13:16:43 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 17753@debbugs.gnu.org
>> 
>> Anyway, one thing that strikes me (and is consistent across all your
>> reports until now) is that atimer.c functions are run from a separate
>> thread, not the main thread (which is Thread 1).  Ken, is this normal
>> in the Cygwin-w32 build?
> 
> Actually, this is not a Cygwin-w32 build, this is a Cygwin-X11 build,
> isn't it?  In which case I think the fact that atimers run from a
> different thread is even more strange.

Yes, this is emacs-X11.exe, not the w32 build.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 9/17/2014 6:16 AM, Eli Zaretskii wrote:
> Anyway, one thing that strikes me (and is consistent across all your
> reports until now) is that atimer.c functions are run from a separate
> thread, not the main thread (which is Thread 1).  Ken, is this normal
> in the Cygwin-w32 build?

Timer functions in general are run in the main thread.  I don't think 
the backtrace of Thread 2 can be trusted.  Something weird is going on 
in Thread 2 in both the Cygwin-w32 build and the Cygwin-X11 build.  And 
it happens only on 64-bit Cygwin (which is where we've been seeing these 
strange crashes).

Here's a sample gdb session using the Cygwin-w32 build on 64-bit Cygwin 
(but I see the same thing with the Cygwin-X11 build):

$ gdb /usr/bin/emacs-w32.exe
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
[...]
(gdb) b run_timers
Breakpoint 1 at 0x10064785c: file 
/usr/src/debug/emacs-24.3.93-4/src/atimer.c, line 342.
(gdb) r -Q
Starting program: /usr/bin/emacs-w32.exe -Q
[New Thread 2072.0x1140]
[New Thread 2072.0x25ec]
[New Thread 2072.0x764]
[New Thread 2072.0x22d4]
[New Thread 2072.0x1c08]

Breakpoint 1, run_timers () at 
/usr/src/debug/emacs-24.3.93-4/src/atimer.c:342
342     {
(gdb) thread apply all bt

Thread 5 (Thread 2072.0x1c08):
#0  0x0000000076eb9e6a in USER32!SfmDxSetSwapChainStats ()
    from /c/Windows/system32/USER32.dll
#1  0x0000000076eb9e9e in USER32!GetMessageW ()
    from /c/Windows/system32/USER32.dll
#2  0x0000000000000000 in ?? ()

Thread 4 (Thread 2072.0x22d4):
#0  0x0000000076ff12fa in ntdll!ZwWaitForSingleObject ()
    from /c/Windows/system32/ntdll.dll
#1  0x000007fefce510dc in WaitForSingleObjectEx ()
    from /c/Windows/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()

Thread 3 (Thread 2072.0x764):
#0  0x0000000076ff186a in ntdll!ZwWaitForMultipleObjects ()
    from /c/Windows/system32/ntdll.dll
#1  0x0000000076fbb037 in ntdll!TpIsTimerSet ()
    from /c/Windows/system32/ntdll.dll
#2  0x0000000000000000 in ?? ()

Thread 2 (Thread 2072.0x25ec):
#0  0x0000000076ff131a in ntdll!ZwReadFile () from 
/c/Windows/system32/ntdll.dll
#1  0x000007fefce51a7a in ReadFile () from 
/c/Windows/system32/KERNELBASE.dll
#2  0x000000000042ce00 in ?? ()
#3  0x0000000100647983 in run_timers ()
     at /usr/src/debug/emacs-24.3.93-4/src/atimer.c:364
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 2072.0x1140):
#0  run_timers () at /usr/src/debug/emacs-24.3.93-4/src/atimer.c:342
#1  0x00000001006479b4 in do_pending_atimers ()
     at /usr/src/debug/emacs-24.3.93-4/src/atimer.c:385
#2  0x000000010053fb87 in process_pending_signals ()
     at /usr/src/debug/emacs-24.3.93-4/src/keyboard.c:7105
#3  0x00000001005b3c53 in Fmake_list (length=0, init=4306501682)
     at /usr/src/debug/emacs-24.3.93-4/src/alloc.c:2644
#4  0x00000001005e4e85 in concat (nargs=1, args=0x429650,
     target_type=Lisp_Cons, last_special=false)
     at /usr/src/debug/emacs-24.3.93-4/src/fns.c:588
#5  0x00000001005e4868 in Fcopy_sequence (arg=25770952502)
     at /usr/src/debug/emacs-24.3.93-4/src/fns.c:456
#6  0x000000010053a111 in timer_check ()
     at /usr/src/debug/emacs-24.3.93-4/src/keyboard.c:4568
[...]

You can see the expected timer functions running in the main thread, but 
I have no idea what's going on in Thread 2.  Is run_timers really being 
called there, or is that just an artifact of a corrupt stack?

Repeating the same steps in 32-bit Cygwin, gives the following:

$ gdb /usr/bin/emacs-w32.exe
GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special)
[...]
(gdb) b run_timers
Breakpoint 1 at 0x5e625e: file 
/usr/src/debug/emacs-24.3.93-4/src/atimer.c, line 343.
(gdb) r -Q
Starting program: /usr/bin/emacs-w32.exe -Q
[New Thread 3284.0x25d0]
[New Thread 3284.0x2088]
[New Thread 3284.0x27a0]
[New Thread 3284.0x216c]
[New Thread 3284.0x9d0]

Breakpoint 1, run_timers () at 
/usr/src/debug/emacs-24.3.93-4/src/atimer.c:343
343       struct timespec now = current_timespec ();
(gdb) thread apply all bt

Thread 5 (Thread 3284.0x9d0):
#0  0x769778d7 in USER32!DispatchMessageW () from 
/c/Windows/syswow64/USER32.dll
#1  0x005ffd9c in w32_msg_pump (msg_buf=0x3c0acd8)
     at /usr/src/debug/emacs-24.3.93-4/src/w32fns.c:2450
#2  0x005fffdf in w32_msg_worker@4 (arg=0x0)
     at /usr/src/debug/emacs-24.3.93-4/src/w32fns.c:2676
#3  0x61005eb4 in _cygtls::call2(unsigned long (*)(void*, void*), void*, 
void*)@16 (this=<optimized out>, func=func@entry=0x5fff3f 
<w32_msg_worker@4>,
     arg=0x3c0ac70, arg@entry=0x0, buf=buf@entry=0x3c0cdc4)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x61006026 in _cygtls::call (func=0x5fff3f <w32_msg_worker@4>, arg=0x0)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x6107d6c8 in threadfunc_fe (arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/init.cc:30
#6  0x76bf338a in KERNEL32!BaseThreadInitThunk ()
    from /c/Windows/syswow64/kernel32.dll
#7  0x771b9f72 in ntdll!RtlInitializeExceptionChain ()
    from /c/Windows/system32/ntdll.dll
#8  0x771b9f45 in ntdll!RtlInitializeExceptionChain ()
    from /c/Windows/system32/ntdll.dll
#9  0x00000000 in ?? ()

Thread 4 (Thread 3284.0x216c):
#0  0x7719f8d1 in ntdll!ZwWaitForSingleObject ()
    from /c/Windows/system32/ntdll.dll
#1  0x7719f8d1 in ntdll!ZwWaitForSingleObject ()
    from /c/Windows/system32/ntdll.dll
#2  0x756814ab in WaitForSingleObjectEx ()
    from /c/Windows/syswow64/KERNELBASE.dll
#3  0x00000318 in ?? ()
#4  0x00000000 in ?? ()

Thread 3 (Thread 3284.0x27a0):
#0  0x771a015d in ntdll!ZwWaitForMultipleObjects ()
    from /c/Windows/system32/ntdll.dll
#1  0x771a015d in ntdll!ZwWaitForMultipleObjects ()
    from /c/Windows/system32/ntdll.dll
#2  0x771d2f91 in ntdll!RtlMoveMemory () from /c/Windows/system32/ntdll.dll
#3  0x00000001 in ?? ()
#4  0x00000001 in ?? ()
#5  0x00000000 in ?? ()

Thread 2 (Thread 3284.0x2088):
#0  0x7719f905 in ntdll!ZwReadFile () from /c/Windows/system32/ntdll.dll
#1  0x7719f905 in ntdll!ZwReadFile () from /c/Windows/system32/ntdll.dll
#2  0x7567dd62 in ReadFile () from /c/Windows/syswow64/KERNELBASE.dll
#3  0x00000094 in ?? ()
#4  0x00000000 in ?? ()

Thread 1 (Thread 3284.0x25d0):
#0  run_timers () at /usr/src/debug/emacs-24.3.93-4/src/atimer.c:343
#1  0x005e634c in do_pending_atimers ()
     at /usr/src/debug/emacs-24.3.93-4/src/atimer.c:385
#2  0x0050d946 in process_pending_signals ()
     at /usr/src/debug/emacs-24.3.93-4/src/keyboard.c:7105
#3  0x0056c13e in Fmake_list (length=0, init=9555994)
     at /usr/src/debug/emacs-24.3.93-4/src/alloc.c:2644
#4  0x00594cba in concat (nargs=1, args=0x28a030, target_type=Lisp_Cons,
     last_special=false) at /usr/src/debug/emacs-24.3.93-4/src/fns.c:588
#5  0x005947cf in Fcopy_sequence (arg=-2146299490)
     at /usr/src/debug/emacs-24.3.93-4/src/fns.c:456
#6  0x00508e9f in timer_check ()
     at /usr/src/debug/emacs-24.3.93-4/src/keyboard.c:4571

Notice that Thread 2 doesn't look much different than Threads 3 and 4; 
in particular, it doesn't show that strange call to run_timers.

I think I should take this to the Cygwin list, unless you have other 
suggestions of things to look at.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Wed, 17 Sep 2014 11:17:24 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: 17753@debbugs.gnu.org
> 
> On 9/17/2014 6:16 AM, Eli Zaretskii wrote:
> > Anyway, one thing that strikes me (and is consistent across all your
> > reports until now) is that atimer.c functions are run from a separate
> > thread, not the main thread (which is Thread 1).  Ken, is this normal
> > in the Cygwin-w32 build?
> 
> Timer functions in general are run in the main thread.

That's what I'd expect.

> I don't think the backtrace of Thread 2 can be trusted.

But if you look at all the backtraces posted in this bug, they all
tell the same story: thread 2 seems to run run_timers.  So before we
decide this is bogus data, I think we should explore the possibility
that GDB really tells the truth here.

> You can see the expected timer functions running in the main thread, but 
> I have no idea what's going on in Thread 2.  Is run_timers really being 
> called there, or is that just an artifact of a corrupt stack?

Hard to say.  But note that do_pending_atimers calls block_atimers
before it calls run_timers, and block_atimers calls pthread_sigmask.
Could this do something weird to the threads, like switch to another
thread?

> I think I should take this to the Cygwin list, unless you have other 
> suggestions of things to look at.

Discussing this on the Cygwin list is probably the best place.

Thanks.

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-09-17 19:06, Eli Zaretskii was heard to say:
>> Date: Wed, 17 Sep 2014 11:17:24 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: 17753@debbugs.gnu.org
>> 
>> On 9/17/2014 6:16 AM, Eli Zaretskii wrote:
>> > Anyway, one thing that strikes me (and is consistent across all your
>> > reports until now) is that atimer.c functions are run from a separate
>> > thread, not the main thread (which is Thread 1).  Ken, is this normal
>> > in the Cygwin-w32 build?
>> 
>> Timer functions in general are run in the main thread.
> 
> That's what I'd expect.
> 
>> I don't think the backtrace of Thread 2 can be trusted.
> 
> But if you look at all the backtraces posted in this bug, they all
> tell the same story: thread 2 seems to run run_timers.  So before we
> decide this is bogus data, I think we should explore the possibility
> that GDB really tells the truth here.
> 
>> You can see the expected timer functions running in the main thread, 
>> but
>> I have no idea what's going on in Thread 2.  Is run_timers really 
>> being
>> called there, or is that just an artifact of a corrupt stack?
> 
> Hard to say.  But note that do_pending_atimers calls block_atimers
> before it calls run_timers, and block_atimers calls pthread_sigmask.
> Could this do something weird to the threads, like switch to another
> thread?
> 
>> I think I should take this to the Cygwin list, unless you have other
>> suggestions of things to look at.
> 
> Discussing this on the Cygwin list is probably the best place.
> 
> Thanks.

Hi again,

please note that I have installed a new test release of Emacs as 
announced here:

https://cygwin.com/ml/cygwin-announce/2014-09/msg00018.html

This release uses Cygwin's malloc instead of Emacs built-in malloc. I 
have no idea whether this might affect the kind of bug I have been 
struggling with for months now. In any case, it crashed again today.

Emacs and package version info:

$ cygcheck -f /usr/bin/emacs-X11
emacs-X11-24.3.93-3

markus.hoenicka@SBHC123 ~
$ emacs -version
GNU Emacs 24.3.93.1


gdb output:

GLib (gthread-posix.c): Unexpected error from C library during 
'pthread_mutex_lock': No error.  Aborting.

Program received signal SIGABRT, Aborted.
0x000000000042e2a8 in ?? ()
(gdb) info thread
   Id   Target Id         Frame
   9    Thread 2900.0x628 0x00000000772712fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   8    Thread 2900.0xa94 0x00000000772712fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   6    Thread 2900.0xf40 0x00000000772715fa in ntdll!ZwDelayExecution ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   5    Thread 2900.0xd40 0x00000000772712fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 2900.0xf10 0x000000007727186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 2900.0xe8c 0x000000007727186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   2    Thread 2900.0xd58 0x000007fefd42940d in RaiseException ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
* 1    Thread 2900.0xdac 0x000000000042e2a8 in ?? ()
(gdb) thread apply all bt

Thread 9 (Thread 2900.0x628):
#0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd4210dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub (
     arg=arg@entry=0x1801d0500 <threads+352>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2 (this=0x443ce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0500 
<threads+352>,
     buf=buf@entry=0x443cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 8 (Thread 2900.0xa94):
#0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd4210dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub (
     arg=arg@entry=0x1801d04a8 <threads+264>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2 (this=0x403ce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d04a8 
<threads+264>,
     buf=buf@entry=0x403cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 6 (Thread 2900.0xf40):
---Type <return> to continue, or q <return> to quit---
#0  0x00000000772715fa in ntdll!ZwDelayExecution ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd421203 in SleepEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018010d970 in thread_pipe (arg=0x600061fe0)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690
#3  0x0000000180044fc5 in cygthread::callfunc (
     this=this@entry=0x1801d03f8 <threads+88>,
     issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub (
     arg=arg@entry=0x1801d03f8 <threads+88>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2 (this=0x343ce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03f8 
<threads+88>,
     buf=buf@entry=0x343cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 5 (Thread 2900.0xd40):
#0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd4210dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub (
     arg=arg@entry=0x1801d0450 <threads+176>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2 (this=0x383ce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0450 
<threads+176>,
     buf=buf@entry=0x383cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 4 (Thread 2900.0xf10):
#0  0x000000007727186a in ntdll!ZwWaitForMultipleObjects ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd421430 in KERNELBASE!GetCurrentProcess ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 2900.0xe8c):
#0  0x000000007727186a in ntdll!ZwWaitForMultipleObjects ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007723b037 in ntdll!TpIsTimerSet ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 2900.0xd58):
#0  0x000007fefd42940d in RaiseException ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#1  0x000007fefd43aa0d in OutputDebugStringA ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018007119e in _cygtls::signal_debugger 
(this=this@entry=0x42ce00,
     si=...) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/exceptions.cc:1505
#3  0x000000018007132e in sigpacket::process (
     this=this@entry=0x1801e3260 <sigq+1056>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/exceptions.cc:1364
#4  0x0000000180119952 in wait_sig ()
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/sigproc.cc:1320
#5  0x0000000180044fc5 in cygthread::callfunc (
     this=this@entry=0x1801d03a0 <threads>,
     issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#6  0x000000018004552a in cygthread::stub (arg=arg@entry=0x1801d03a0 
<threads>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#7  0x000000018004619b in _cygtls::call2 (this=0x21bce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03a0 
<threads>,
     buf=buf@entry=0x21bcd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#8  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#9  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#10 0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 2900.0xdac):
#0  0x000000000042e2a8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt 
stack?)


regards,
Markus



-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 9/22/2014 3:14 AM, Markus Hoenicka wrote:
> $ cygcheck -f /usr/bin/emacs-X11
> emacs-X11-24.3.93-3

And do you have the matching version of emacs-debuginfo installed?  The 
lack of information in the backtrace of Thread 1 makes me think that you 
might not.

> GLib (gthread-posix.c): Unexpected error from C library during
> 'pthread_mutex_lock': No error.  Aborting.

I would also suggest that you install glib2.0-debuginfo, to see if we 
can get more information about this Glib abort if it happens again. 
Finally, please make sure that you're using the latest versions of gdb 
and Glib (there were new releases of both last week).

Thanks.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-09-22 15:32, Ken Brown was heard to say:
> On 9/22/2014 3:14 AM, Markus Hoenicka wrote:
>> $ cygcheck -f /usr/bin/emacs-X11
>> emacs-X11-24.3.93-3
> 
> And do you have the matching version of emacs-debuginfo installed?
> The lack of information in the backtrace of Thread 1 makes me think
> that you might not.
> 

I think I do:

$ cygcheck -f /usr/lib/debug/usr/bin/emacs-X11.exe.dbg
emacs-debuginfo-24.3.93-3

Also, gdb does not complain about a version mismatch, although the path 
to the symbols looks a little strange to me (note the // in the middle):

$ gdb /usr/bin/emacs-X11
GNU gdb (GDB) 7.8
[...]
Reading symbols from /usr/bin/emacs-X11...Reading symbols from 
/usr/lib/debug//usr/bin/emacs-X11.exe.dbg...done.
done.


>> GLib (gthread-posix.c): Unexpected error from C library during
>> 'pthread_mutex_lock': No error.  Aborting.
> 
> I would also suggest that you install glib2.0-debuginfo, to see if we
> can get more information about this Glib abort if it happens again.
> Finally, please make sure that you're using the latest versions of gdb
> and Glib (there were new releases of both last week).
> 
> Thanks.
> 
> Ken

I'll see to it. I'm not sure whether Glib is relevant here. I had a 
second crash barely 15 min after the first one which I did not get round 
to report yet (see below). This one does not seem to point to Glib.

regards,
Markus

Fatal error 6: Aborted
Program received signal SIGABRT, Aborted.
terminate_due_to_signal (sig=0, backtrace_limit=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:381
381       exit (1);
(gdb) info threads
   Id   Target Id         Frame
   9    Thread 4188.0x460 0x00000000772712fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   8    Thread 4188.0xc68 0x00000000772712fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   6    Thread 4188.0xa84 0x00000000772712fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   5    Thread 4188.0xd18 0x00000000772715fa in ntdll!ZwDelayExecution ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 4188.0x1194 0x000000007727186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 4188.0x1074 0x000000007727186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   2    Thread 4188.0xcc  0x000007fefd42940d in RaiseException ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
* 1    Thread 4188.0x1164 terminate_due_to_signal (sig=0,
     backtrace_limit=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:381
(gdb) thread apply all bt

Thread 9 (Thread 4188.0x460):
#0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd4210dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub (
     arg=arg@entry=0x1801d0500 <threads+352>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2 (this=0x425ce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0500 
<threads+352>,
     buf=buf@entry=0x425cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 8 (Thread 4188.0xc68):
#0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd4210dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub (
     arg=arg@entry=0x1801d04a8 <threads+264>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2 (this=0x3e5ce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d04a8 
<threads+264>,
     buf=buf@entry=0x3e5cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 6 (Thread 4188.0xa84):
#0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd4210dc in WaitForSingleObjectEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018013db94 in timer_thread (x=0x365a9d8)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/timer.cc:145
#3  0x0000000180044fc5 in cygthread::callfunc (
     this=this@entry=0x1801d0450 <threads+176>,
     issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub (
     arg=arg@entry=0x1801d0450 <threads+176>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2 (this=0x365ce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0450 
<threads+176>,
     buf=buf@entry=0x365cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 5 (Thread 4188.0xd18):
#0  0x00000000772715fa in ntdll!ZwDelayExecution ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd421203 in SleepEx ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018010d970 in thread_pipe (arg=0x600061fe0)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690
#3  0x0000000180044fc5 in cygthread::callfunc (
     this=this@entry=0x1801d03f8 <threads+88>,
     issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub (
     arg=arg@entry=0x1801d03f8 <threads+88>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2 (this=0x325ce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03f8 
<threads+88>,
     buf=buf@entry=0x325cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 4 (Thread 4188.0x1194):
#0  0x000000007727186a in ntdll!ZwWaitForMultipleObjects ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd421430 in KERNELBASE!GetCurrentProcess ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 4188.0x1074):
#0  0x000000007727186a in ntdll!ZwWaitForMultipleObjects ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007723b037 in ntdll!TpIsTimerSet ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 4188.0xcc):
#0  0x000007fefd42940d in RaiseException ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#1  0x000007fefd43aa0d in OutputDebugStringA ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll

#2  0x000000018007119e in _cygtls::signal_debugger 
(this=this@entry=0x42ce00,
     si=...) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/exceptions.cc:1505
#3  0x000000018007132e in sigpacket::process (
     this=this@entry=0x1801e3260 <sigq+1056>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/exceptions.cc:1364
#4  0x0000000180119952 in wait_sig ()
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/sigproc.cc:1320
#5  0x0000000180044fc5 in cygthread::callfunc (
     this=this@entry=0x1801d03a0 <threads>,
     issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#6  0x000000018004552a in cygthread::stub (arg=arg@entry=0x1801d03a0 
<threads>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#7  0x000000018004619b in _cygtls::call2 (this=0x23bce00,
     func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03a0 
<threads>,
     buf=buf@entry=0x23bcd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#8  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
     arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#9  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
    from /cygdrive/c/WINDOWS/system32/kernel32.dll
#10 0x000000007724c541 in ntdll!RtlUserThreadStart ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 4188.0x1164):
#0  terminate_due_to_signal (sig=0, backtrace_limit=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:381
#1  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Mon, 22 Sep 2014 16:04:41 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, 17753@debbugs.gnu.org
> 
> At 2014-09-22 15:32, Ken Brown was heard to say:
> > On 9/22/2014 3:14 AM, Markus Hoenicka wrote:
> >> $ cygcheck -f /usr/bin/emacs-X11
> >> emacs-X11-24.3.93-3
> > 
> > And do you have the matching version of emacs-debuginfo installed?
> > The lack of information in the backtrace of Thread 1 makes me think
> > that you might not.
> > 
> 
> I think I do:
> 
> $ cygcheck -f /usr/lib/debug/usr/bin/emacs-X11.exe.dbg
> emacs-debuginfo-24.3.93-3
> 
> Also, gdb does not complain about a version mismatch, although the path 
> to the symbols looks a little strange to me (note the // in the middle):
> 
> $ gdb /usr/bin/emacs-X11
> GNU gdb (GDB) 7.8
> [...]
> Reading symbols from /usr/bin/emacs-X11...Reading symbols from 
> /usr/lib/debug//usr/bin/emacs-X11.exe.dbg...done.
> done.

Then something weird is going on here, because the backtrace you
posted omits all the Emacs parts, and leaves only the Cygwin internal
symbols.  Once it gets to the first frame where Emacs code was
supposed to be executed, it bails out claiming the stack is corrupt.

> Fatal error 6: Aborted
> Program received signal SIGABRT, Aborted.
> terminate_due_to_signal (sig=0, backtrace_limit=<optimized out>)
>      at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:381
> 381       exit (1);
> (gdb) info threads
>    Id   Target Id         Frame
>    9    Thread 4188.0x460 0x00000000772712fa in 
> ntdll!ZwWaitForSingleObject ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
>    8    Thread 4188.0xc68 0x00000000772712fa in 
> ntdll!ZwWaitForSingleObject ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
>    6    Thread 4188.0xa84 0x00000000772712fa in 
> ntdll!ZwWaitForSingleObject ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
>    5    Thread 4188.0xd18 0x00000000772715fa in ntdll!ZwDelayExecution ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
>    4    Thread 4188.0x1194 0x000000007727186a in 
> ntdll!ZwWaitForMultipleObjects
>      () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
>    3    Thread 4188.0x1074 0x000000007727186a in 
> ntdll!ZwWaitForMultipleObjects
>      () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
>    2    Thread 4188.0xcc  0x000007fefd42940d in RaiseException ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> * 1    Thread 4188.0x1164 terminate_due_to_signal (sig=0,
>      backtrace_limit=<optimized out>)
>      at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:381
> (gdb) thread apply all bt
> 
> Thread 9 (Thread 4188.0x460):
> #0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #1  0x000007fefd4210dc in WaitForSingleObjectEx ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #2  0x0000000180045561 in cygthread::stub (
>      arg=arg@entry=0x1801d0500 <threads+352>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
> #3  0x000000018004619b in _cygtls::call2 (this=0x425ce00,
>      func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0500 
> <threads+352>,
>      buf=buf@entry=0x425cd50)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
> #4  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
>      arg=<optimized out>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
> #5  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
>     from /cygdrive/c/WINDOWS/system32/kernel32.dll
> #6  0x000000007724c541 in ntdll!RtlUserThreadStart ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #7  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Thread 8 (Thread 4188.0xc68):
> #0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #1  0x000007fefd4210dc in WaitForSingleObjectEx ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #2  0x0000000180045561 in cygthread::stub (
>      arg=arg@entry=0x1801d04a8 <threads+264>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
> #3  0x000000018004619b in _cygtls::call2 (this=0x3e5ce00,
>      func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d04a8 
> <threads+264>,
>      buf=buf@entry=0x3e5cd50)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
> #4  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
>      arg=<optimized out>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
> #5  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
>     from /cygdrive/c/WINDOWS/system32/kernel32.dll
> #6  0x000000007724c541 in ntdll!RtlUserThreadStart ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #7  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Thread 6 (Thread 4188.0xa84):
> #0  0x00000000772712fa in ntdll!ZwWaitForSingleObject ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #1  0x000007fefd4210dc in WaitForSingleObjectEx ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #2  0x000000018013db94 in timer_thread (x=0x365a9d8)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/timer.cc:145
> #3  0x0000000180044fc5 in cygthread::callfunc (
>      this=this@entry=0x1801d0450 <threads+176>,
>      issimplestub=issimplestub@entry=false)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
> #4  0x000000018004552a in cygthread::stub (
>      arg=arg@entry=0x1801d0450 <threads+176>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
> #5  0x000000018004619b in _cygtls::call2 (this=0x365ce00,
>      func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0450 
> <threads+176>,
>      buf=buf@entry=0x365cd50)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
> #6  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
>      arg=<optimized out>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
> #7  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
>     from /cygdrive/c/WINDOWS/system32/kernel32.dll
> #8  0x000000007724c541 in ntdll!RtlUserThreadStart ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #9  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Thread 5 (Thread 4188.0xd18):
> #0  0x00000000772715fa in ntdll!ZwDelayExecution ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #1  0x000007fefd421203 in SleepEx ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #2  0x000000018010d970 in thread_pipe (arg=0x600061fe0)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690
> #3  0x0000000180044fc5 in cygthread::callfunc (
>      this=this@entry=0x1801d03f8 <threads+88>,
>      issimplestub=issimplestub@entry=false)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
> #4  0x000000018004552a in cygthread::stub (
>      arg=arg@entry=0x1801d03f8 <threads+88>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
> #5  0x000000018004619b in _cygtls::call2 (this=0x325ce00,
>      func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03f8 
> <threads+88>,
>      buf=buf@entry=0x325cd50)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
> #6  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
>      arg=<optimized out>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
> #7  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
>     from /cygdrive/c/WINDOWS/system32/kernel32.dll
> #8  0x000000007724c541 in ntdll!RtlUserThreadStart ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #9  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Thread 4 (Thread 4188.0x1194):
> #0  0x000000007727186a in ntdll!ZwWaitForMultipleObjects ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #1  0x000007fefd421430 in KERNELBASE!GetCurrentProcess ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #2  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Thread 3 (Thread 4188.0x1074):
> #0  0x000000007727186a in ntdll!ZwWaitForMultipleObjects ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #1  0x000000007723b037 in ntdll!TpIsTimerSet ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #2  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
>     from /cygdrive/c/WINDOWS/system32/kernel32.dll
> #3  0x000000007724c541 in ntdll!RtlUserThreadStart ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #4  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Thread 2 (Thread 4188.0xcc):
> #0  0x000007fefd42940d in RaiseException ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> #1  0x000007fefd43aa0d in OutputDebugStringA ()
>     from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
> 
> #2  0x000000018007119e in _cygtls::signal_debugger 
> (this=this@entry=0x42ce00,
>      si=...) at 
> /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/exceptions.cc:1505
> #3  0x000000018007132e in sigpacket::process (
>      this=this@entry=0x1801e3260 <sigq+1056>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/exceptions.cc:1364
> #4  0x0000000180119952 in wait_sig ()
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/sigproc.cc:1320
> #5  0x0000000180044fc5 in cygthread::callfunc (
>      this=this@entry=0x1801d03a0 <threads>,
>      issimplestub=issimplestub@entry=false)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
> #6  0x000000018004552a in cygthread::stub (arg=arg@entry=0x1801d03a0 
> <threads>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
> #7  0x000000018004619b in _cygtls::call2 (this=0x23bce00,
>      func=0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03a0 
> <threads>,
>      buf=buf@entry=0x23bcd50)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
> #8  0x00000001800462f4 in _cygtls::call (func=<optimized out>,
>      arg=<optimized out>)
>      at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
> #9  0x00000000770159ed in KERNEL32!BaseThreadInitThunk ()
>     from /cygdrive/c/WINDOWS/system32/kernel32.dll
> #10 0x000000007724c541 in ntdll!RtlUserThreadStart ()
>     from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
> #11 0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Thread 1 (Thread 4188.0x1164):
> #0  terminate_due_to_signal (sig=0, backtrace_limit=<optimized out>)
>      at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:381
> #1  0x0000000000000000 in ?? ()
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Could it be that the program switched to some alternate stack?  In
that case, I could understand why it cannot walk the stack below
system levels.

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-09-17 19:06, Eli Zaretskii was heard to say:

>> I think I should take this to the Cygwin list, unless you have other
>> suggestions of things to look at.
> 
> Discussing this on the Cygwin list is probably the best place.
> 

Hi,

Ken posted a problem description to the Cygwin list, but to the best of 
my knowledge nothing came of it. Today Emacs crashed again from within 
gdb. This is gdb 7.8.2 which has a problem fixed that had resulted in 
strange core dumps on Cygwin. The backtrace of this most recent crash 
seems to be the most verbose to date, maybe this one sheds some light on 
what is going wrong. Let me know if you need any additional information.

regards,
Markus

(gdb) info threads
   Id   Target Id         Frame
   9    Thread 4580.0x12b8 0x00000000779512fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   8    Thread 4580.0x1234 0x00000000779512fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   7    Thread 4580.0x1230 0x000000007795134a in 
ntdll!ZwRemoveIoCompletion ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   6    Thread 4580.0x1228 0x00000000779515fa in ntdll!ZwDelayExecution 
()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   5    Thread 4580.0x122c 0x00000000779512fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 4580.0x1224 0x000000007795186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 4580.0x1214 0x000000007795186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   2    Thread 4580.0x1208 0x000000007795131a in ntdll!ZwReadFile ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
* 1    Thread 4580.0x11e8 0x00000003ff120d78 in dbus_watch_handle ()
    from /usr/bin/cygdbus-1-3.dll
(gdb) thread apply all bt

Thread 9 (Thread 4580.0x12b8):
#0  0x00000000779512fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefdb810dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0500 <threads+352>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x413ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0500 <threads+352>, 
buf=buf@entry=0x413cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000777f59ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007792c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 8 (Thread 4580.0x1234):
#0  0x00000000779512fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefdb810dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d04a8 <threads+264>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x3d3ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d04a8 <threads+264>, 
buf=buf@entry=0x3d3cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000777f59ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007792c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 7 (Thread 4580.0x1230):
#0  0x000000007795134a in ntdll!ZwRemoveIoCompletion ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd035971 in  () at 
/cygdrive/c/WINDOWS/System32/mswsock.dll
#2  0x0000000000000000 in  ()

Thread 6 (Thread 4580.0x1228):
#0  0x00000000779515fa in ntdll!ZwDelayExecution ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefdb81203 in SleepEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018010d970 in thread_pipe(void*) (arg=0x60005dea0)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690
#3  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03f8 <threads+88>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03f8 <threads+88>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x313ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03f8 <threads+88>, 
buf=buf@entry=0x313cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000777f59ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007792c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in  ()

Thread 5 (Thread 4580.0x122c):
#0  0x00000000779512fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefdb810dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0450 <threads+176>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x353ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0450 <threads+176>, 
buf=buf@entry=0x353cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000777f59ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007792c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 4 (Thread 4580.0x1224):
#0  0x000000007795186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefdb81430 in KERNELBASE!GetCurrentProcess ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in  ()

Thread 3 (Thread 4580.0x1214):
#0  0x000000007795186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007791b037 in ntdll!TpIsTimerSet ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00000000777f59ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x000000007792c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in  ()

Thread 2 (Thread 4580.0x1208):
#0  0x000000007795131a in ntdll!ZwReadFile ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefdb81a7a in ReadFile ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x00000000777f0a19 in ReadFile ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x00000001801197c2 in wait_sig(void*) ()
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/sigproc.cc:1239
#4  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03a0 <threads>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#5  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03a0 <threads>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#6  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x227ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03a0 <threads>, 
buf=buf@entry=0x227cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#7  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#8  0x00000000777f59ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#9  0x000000007792c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#10 0x0000000000000000 in  ()

Thread 1 (Thread 4580.0x11e8):
#0  0x00000003ff120d78 in dbus_watch_handle () at 
/usr/bin/cygdbus-1-3.dll
#1  0x00000003ff105799 in dbus_bus_remove_match () at 
/usr/bin/cygdbus-1-3.dll
#2  0x00000003ff106580 in dbus_connection_get_dispatch_status ()
     at /usr/bin/cygdbus-1-3.dll
#3  0x00000003ff5f17d3 in 
cygatspi-0!atspi_key_listener_sync_type_get_type ()
     at /usr/bin/cygatspi-0.dll
#4  0x00000003fe7bd3fe in g_main_context_prepare 
(context=context@entry=0x600109540, priority=priority@entry=0x429908)
     at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3340
#5  0x00000003fe7bdc32 in g_main_context_iterate 
(context=context@entry=0x600109540, block=block@entry=0, 
dispatch=dispatch@entry=0, self=<optimized out>)
     at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3693
#6  0x00000003fe7bddb8 in g_main_context_pending (context=0x600109540)
     at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3739
#7  0x00000001005b2760 in xg_select (fds_lim=<optimized out>, 
rfds=rfds@entry=0x429fa0, wfds=wfds@entry=0x429fb0, efds=efds@entry=0x0, 
timeout=timeout@entry=0x429fc0, sigmask=sigmask@entry=0x0)
     at /usr/src/debug/emacs-24.3.93-3/src/xgselect.c:149
#8  0x000000010057eb95 in wait_reading_process_output 
(time_limit=<optimized out>, nsecs=0, read_kbd=read_kbd@entry=-1, 
do_display=do_display@entry=true, wait_for_cell=4304695346, 
wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0) at 
/usr/src/debug/emacs-24.3.93-3/src/process.c:4603
#9  0x000000010040a24a in sit_for (timeout=<optimized out>, 
reading=reading@entry=true, display_option=display_option@entry=1)
     at /usr/src/debug/emacs-24.3.93-3/src/dispnew.c:5854
#10 0x00000001004dbd27 in read_char (commandflag=1, 
map=map@entry=25783870774, prev_event=4304695346, 
used_mouse_menu=used_mouse_menu@entry=0x42a5db, 
end_time=end_time@entry=0x0) at 
/usr/src/debug/emacs-24.3.93-3/src/keyboard.c:2809
#11 0x00000001004dd01e in read_key_sequence 
(keybuf=keybuf@entry=0x42a720, prompt=4304695346, 
dont_downcase_last=dont_downcase_last@entry=false, 
can_return_switch_frame=can_return_switch_frame@entry=true, 
fix_current_buffer=fix_current_buffer@entry=true, 
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:9088
#12 0x00000001004dede4 in command_loop_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1452
#13 0x000000010053f37d in internal_condition_case 
(bfun=bfun@entry=0x1004debc0 <command_loop_1>, handlers=<optimized out>, 
hfun=hfun@entry=0x1004d54a0 <cmd_error>) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:1354
#14 0x00000001004d09ea in command_loop_2 
(ignore=ignore@entry=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1177
#15 0x000000010053f27c in internal_catch (tag=4304765794, 
func=func@entry=0x1004d09c0 <command_loop_2>, arg=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:1118
#16 0x00000001004d5094 in recursive_edit_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1156
#17 0x00000001004d5094 in recursive_edit_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:777
#18 0x00000001004d53b6 in Frecursive_edit ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:848
#19 0x00000001005c46d9 in main (argc=<optimized out>, argv=<optimized 
out>)
     at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:1647


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 10/7/2014 3:02 AM, Markus Hoenicka wrote:
> #0  0x00000003ff120d78 in dbus_watch_handle () at /usr/bin/cygdbus-1-3.dll
> #1  0x00000003ff105799 in dbus_bus_remove_match () at
> /usr/bin/cygdbus-1-3.dll
> #2  0x00000003ff106580 in dbus_connection_get_dispatch_status ()
>      at /usr/bin/cygdbus-1-3.dll
> #3  0x00000003ff5f17d3 in
> cygatspi-0!atspi_key_listener_sync_type_get_type ()
>      at /usr/bin/cygatspi-0.dll
> #4  0x00000003fe7bd3fe in g_main_context_prepare
> (context=context@entry=0x600109540, priority=priority@entry=0x429908)
>      at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3340
> #5  0x00000003fe7bdc32 in g_main_context_iterate
> (context=context@entry=0x600109540, block=block@entry=0,
> dispatch=dispatch@entry=0, self=<optimized out>)
>      at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3693
> #6  0x00000003fe7bddb8 in g_main_context_pending (context=0x600109540)
>      at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3739
> #7  0x00000001005b2760 in xg_select (fds_lim=<optimized out>,
> rfds=rfds@entry=0x429fa0, wfds=wfds@entry=0x429fb0, efds=efds@entry=0x0,
> timeout=timeout@entry=0x429fc0, sigmask=sigmask@entry=0x0)
>      at /usr/src/debug/emacs-24.3.93-3/src/xgselect.c:149

It's nice to finally see what looks like a reasonable backtrace.  To get 
more information about frames 0--3, you'll need to install some more 
debuginfo packages:  at-spi2-atk-debuginfo, at-spi2-core-debuginfo, and 
dbus-debuginfo.  I don't know if it's possible at this point to get gdb 
to read the debug information for cygdbus-1-3.dll and cygatspi-0.dll 
(once you install the debuginfo packages) or if you have to wait for the 
next crash.  I'm sure Eli knows.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Tue, 07 Oct 2014 10:56:45 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: 17753@debbugs.gnu.org
> 
> I don't know if it's possible at this point to get gdb to read the
> debug information for cygdbus-1-3.dll and cygatspi-0.dll (once you
> install the debuginfo packages) or if you have to wait for the next
> crash.  I'm sure Eli knows.

You can always type the addresses by hand and get the file and line
number, like this:

 (gdb) list *0x00000003ff120d78

Since this is an optimized build, you won't get anything more detailed
anyway.

Btw, is this a crash or an abort?  What was the signal that caused
this?  (GDB should have displayed that info before the backtrace.)

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-10-07 17:05, schrieb Eli Zaretskii:
>> Date: Tue, 07 Oct 2014 10:56:45 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: 17753@debbugs.gnu.org
>> 
>> I don't know if it's possible at this point to get gdb to read the
>> debug information for cygdbus-1-3.dll and cygatspi-0.dll (once you
>> install the debuginfo packages) or if you have to wait for the next
>> crash.  I'm sure Eli knows.
> 
> You can always type the addresses by hand and get the file and line
> number, like this:
> 
>  (gdb) list *0x00000003ff120d78
> 
> Since this is an optimized build, you won't get anything more detailed
> anyway.
> 
> Btw, is this a crash or an abort?  What was the signal that caused
> this?  (GDB should have displayed that info before the backtrace.)

I'm afraid I didn't record this information. I'll do better next time.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Tue, 07 Oct 2014 18:05:58 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: Ken Brown <kbrown@cornell.edu>, 17753@debbugs.gnu.org
> 
> > You can always type the addresses by hand and get the file and line
> > number, like this:
> > 
> >  (gdb) list *0x00000003ff120d78
> > 
> > Since this is an optimized build, you won't get anything more detailed
> > anyway.
> > 
> > Btw, is this a crash or an abort?  What was the signal that caused
> > this?  (GDB should have displayed that info before the backtrace.)
> 
> I'm afraid I didn't record this information.

It's recorded in the bug tracker:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17753#77

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-10-07 19:04, schrieb Eli Zaretskii:
>> Date: Tue, 07 Oct 2014 18:05:58 +0200
>> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
>> Cc: Ken Brown <kbrown@cornell.edu>, 17753@debbugs.gnu.org
>> 
>> > You can always type the addresses by hand and get the file and line
>> > number, like this:
>> >
>> >  (gdb) list *0x00000003ff120d78
>> >
>> > Since this is an optimized build, you won't get anything more detailed
>> > anyway.
>> >
>> > Btw, is this a crash or an abort?  What was the signal that caused
>> > this?  (GDB should have displayed that info before the backtrace.)
>> 
>> I'm afraid I didn't record this information.
> 
> It's recorded in the bug tracker:
> 
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17753#77

Yes, I still do have that piece of gdb's output. I apparently forgot to 
copy the preceding message saying either it's an abort or a crash. I'll 
make sure I have this information handy next time it crashes.

Thanks anyway for looking into this.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-10-07 19:04, schrieb Eli Zaretskii:
>> Date: Tue, 07 Oct 2014 18:05:58 +0200
>> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
>> Cc: Ken Brown <kbrown@cornell.edu>, 17753@debbugs.gnu.org
>> 
>> > You can always type the addresses by hand and get the file and line
>> > number, like this:
>> >
>> >  (gdb) list *0x00000003ff120d78
>> >
>> > Since this is an optimized build, you won't get anything more detailed
>> > anyway.
>> >
>> > Btw, is this a crash or an abort?  What was the signal that caused
>> > this?  (GDB should have displayed that info before the backtrace.)
>> 
>> I'm afraid I didn't record this information.
> 

This time with gdb's crash message. FWIW, I was hitting the backspace 
key to erase some characters from an XML document in a nXML buffer.

Program received signal SIGSEGV, Segmentation fault.
face_for_char (f=0x100f45c48 <bss_sbrk_buffer+6331368>, 
face=face@entry=0x0,
     c=101, pos=17134, object=object@entry=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/fontset.c:917
917         return face->ascii_face->id;
(gdb) info threads
   Id   Target Id         Frame
   9    Thread 3788.0x114 0x00000000770b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   8    Thread 3788.0xe3c 0x00000000770b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   6    Thread 3788.0x178 0x00000000770b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   5    Thread 3788.0xe84 0x00000000770b15fa in ntdll!ZwDelayExecution ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 3788.0xb0  0x00000000770b186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 3788.0x2ac 0x00000000770b186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   2    Thread 3788.0xe30 0x00000000770b131a in ntdll!ZwReadFile ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
* 1    Thread 3788.0xb28 face_for_char (
     f=0x100f45c48 <bss_sbrk_buffer+6331368>, face=face@entry=0x0, c=101,
     pos=17134, object=object@entry=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/fontset.c:917
Thread 9 (Thread 3788.0x114):
#0  0x00000000770b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd2e10dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0500 <threads+352>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x423ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0500 <threads+352>, 
buf=buf@entry=0x423cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x0000000076e559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007708c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 8 (Thread 3788.0xe3c):
#0  0x00000000770b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd2e10dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d04a8 <threads+264>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x3e3ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d04a8 <threads+264>, 
buf=buf@entry=0x3e3cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x0000000076e559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007708c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 6 (Thread 3788.0x178):
#0  0x00000000770b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd2e10dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0450 <threads+176>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x363ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0450 <threads+176>, 
buf=buf@entry=0x363cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x0000000076e559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007708c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 5 (Thread 3788.0xe84):
#0  0x00000000770b15fa in ntdll!ZwDelayExecution ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd2e1203 in SleepEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018010d970 in thread_pipe(void*) (arg=0x600061fe0)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690
#3  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03f8
  <threads+88>, issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03f8 <threads+88>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x323ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03f8 <threads+88>, 
buf=buf@entry=0x323cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x0000000076e559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007708c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in  ()

Thread 4 (Thread 3788.0xb0):
#0  0x00000000770b186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd2e1430 in KERNELBASE!GetCurrentProcess ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in  ()

Thread 3 (Thread 3788.0x2ac):
#0  0x00000000770b186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007707b037 in ntdll!TpIsTimerSet ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x0000000076e559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x000000007708c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in  ()

Thread 2 (Thread 3788.0xe30):
#0  0x00000000770b131a in ntdll!ZwReadFile ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd2e1a7a in ReadFile ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000076e50a19 in ReadFile ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x00000001801197c2 in wait_sig(void*) ()
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/sigproc.cc:1239
#4  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03a0 <threads>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#5  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03a0 <threads>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#6  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x226ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03a0 <threads>, 
buf=buf@entry=0x226cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#7  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#8  0x0000000076e559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#9  0x000000007708c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#10 0x0000000000000000 in  ()

Thread 1 (Thread 3788.0xb28):
#0  0x00000001005a1673 in face_for_char (f=0x100f45c48 
<bss_sbrk_buffer+6331368>, face=face@entry=0x0, c=101, pos=17134, 
object=object@entry=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/fontset.c:917
#1  0x0000000100428c1a in get_next_display_element 
(it=it@entry=0x425c30)
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:7139
#2  0x000000010042773b in move_it_in_display_line_to 
(it=it@entry=0x425c30, to_c
harpos=to_charpos@entry=17614, to_x=to_x@entry=-1, 
op=op@entry=MOVE_TO_POS)
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:8786
#3  0x000000010042dfdc in move_it_to (it=it@entry=0x425c30, 
to_charpos=to_charpos@entry=17614, to_x=to_x@entry=-1, 
to_y=to_y@entry=-1, to_vpos=to_vpos@entry=-1, op=op@entry=8) at 
/usr/src/debug/emacs-24.3.93-3/src/xdisp.c:9226
#4  0x0000000100431c67 in start_display (it=it@entry=0x425c30, 
w=w@entry=0x100f46c48 <bss_sbrk_buffer+6335464>, pos=...)
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:3115
#5  0x0000000100432966 in try_window (window=window@entry=4310985805, 
pos=..., flags=flags@entry=1) at 
/usr/src/debug/emacs-24.3.93-3/src/xdisp.c:16868
#6  0x00000001004487d4 in redisplay_window 
(window=window@entry=4310985805, 
just_this_one_p=just_this_one_p@entry=false)
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:16352
#7  0x000000010044a956 in redisplay_window_0 
(window=window@entry=4310985805)
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:14287
#8  0x000000010053f4b7 in internal_condition_case_1 
(bfun=bfun@entry=0x10044a930 <redisplay_window_0>, arg=4310985805, 
handlers=<optimized out>, hfun=hfun@entry=0x100413ff0 
<redisplay_window_error>)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:1378
#9  0x000000010041937a in redisplay_windows (window=4310985805)
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:14267
#10 0x000000010043767a in redisplay_internal ()
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:13866
#11 0x0000000100439775 in redisplay ()
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:13153
#12 0x00000001004db425 in read_char (commandflag=1, 
map=map@entry=25798127830, prev_event=4304695346, 
used_mouse_menu=used_mouse_menu@entry=0x42a5db, 
end_time=end_time@entry=0x0) at 
/usr/src/debug/emacs-24.3.93-3/src/keyboard.c:2570
#13 0x00000001004dd01e in read_key_sequence 
(keybuf=keybuf@entry=0x42a720, prompt=4304695346, 
dont_downcase_last=dont_downcase_last@entry=false, 
can_return_switch_frame=can_return_switch_frame@entry=true, 
fix_current_buffer=fix_current_buffer@entry=true, 
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:9088
#14 0x00000001004dede4 in command_loop_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1452
#15 0x000000010053f37d in internal_condition_case 
(bfun=bfun@entry=0x1004debc0 <command_loop_1>, handlers=<optimized out>, 
hfun=hfun@entry=0x1004d54a0 <cmd_error>) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:1354
#16 0x00000001004d09ea in command_loop_2 
(ignore=ignore@entry=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1177
#17 0x000000010053f27c in internal_catch (tag=4304765794, 
func=func@entry=0x1004d09c0 <command_loop_2>, arg=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:1118
#18 0x00000001004d5094 in recursive_edit_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1156
#19 0x00000001004d5094 in recursive_edit_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:777
#20 0x00000001004d53b6 in Frecursive_edit ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:848
#21 0x00000001005c46d9 in main (argc=<optimized out>, argv=<optimized 
out>)
     at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:1647



-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Thu, 09 Oct 2014 10:17:47 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: kbrown@cornell.edu, 17753@debbugs.gnu.org
> 
> This time with gdb's crash message. FWIW, I was hitting the backspace 
> key to erase some characters from an XML document in a nXML buffer.
> 
> Program received signal SIGSEGV, Segmentation fault.
> face_for_char (f=0x100f45c48 <bss_sbrk_buffer+6331368>, 
> face=face@entry=0x0,
>      c=101, pos=17134, object=object@entry=4304695346)
>      at /usr/src/debug/emacs-24.3.93-3/src/fontset.c:917
> 917         return face->ascii_face->id;

Why do you think it's the same problem?  It looks very different to
me, judging by the backtrace.

> #0  0x00000001005a1673 in face_for_char (f=0x100f45c48 
> <bss_sbrk_buffer+6331368>, face=face@entry=0x0, c=101, pos=17134, 
> object=object@entry=4304695346)
>      at /usr/src/debug/emacs-24.3.93-3/src/fontset.c:917
> #1  0x0000000100428c1a in get_next_display_element 
> (it=it@entry=0x425c30)
>      at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:7139

What do the following GDB commands produce?

 (gdb) thread 1
 (gdb) frame 1
 (gdb) print it->what
 (gdb) print it->face_id
 (gdb) print FRAME_FACE_CACHE (it->f)->used
 (gdb) print face

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-10-09 10:56, schrieb Eli Zaretskii:
>> Date: Thu, 09 Oct 2014 10:17:47 +0200
>> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
>> Cc: kbrown@cornell.edu, 17753@debbugs.gnu.org
>> 
>> This time with gdb's crash message. FWIW, I was hitting the backspace
>> key to erase some characters from an XML document in a nXML buffer.
>> 
>> Program received signal SIGSEGV, Segmentation fault.
>> face_for_char (f=0x100f45c48 <bss_sbrk_buffer+6331368>,
>> face=face@entry=0x0,
>>      c=101, pos=17134, object=object@entry=4304695346)
>>      at /usr/src/debug/emacs-24.3.93-3/src/fontset.c:917
>> 917         return face->ascii_face->id;
> 
> Why do you think it's the same problem?  It looks very different to
> me, judging by the backtrace.
> 

I should have been more verbose in my message. I didn't mean to imply 
this is the same problem. The backtrace which I sent today is of a new 
crash different from the ones I was talking about yesterday (it's an 
all-time high btw. Three crashes within 24 h). And yes, the backtraces 
do look different even to the untrained eye.

>> #0  0x00000001005a1673 in face_for_char (f=0x100f45c48
>> <bss_sbrk_buffer+6331368>, face=face@entry=0x0, c=101, pos=17134,
>> object=object@entry=4304695346)
>>      at /usr/src/debug/emacs-24.3.93-3/src/fontset.c:917
>> #1  0x0000000100428c1a in get_next_display_element
>> (it=it@entry=0x425c30)
>>      at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:7139
> 
> What do the following GDB commands produce?
> 
>  (gdb) thread 1
>  (gdb) frame 1
>  (gdb) print it->what
>  (gdb) print it->face_id
>  (gdb) print FRAME_FACE_CACHE (it->f)->used
>  (gdb) print face

(gdb) thread 1
[Switching to thread 1 (Thread 3788.0xb28)]
#0  face_for_char (f=0x100f45c48 <bss_sbrk_buffer+6331368>,
     face=face@entry=0x0, c=101, pos=17134, 
object=object@entry=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/fontset.c:917
917         return face->ascii_face->id;
(gdb) frame 1
#1  0x0000000100428c1a in get_next_display_element 
(it=it@entry=0x425c30)
     at /usr/src/debug/emacs-24.3.93-3/src/xdisp.c:7139
7139              it->face_id = FACE_FOR_CHAR (it->f, face, c, pos, 
it->string);
(gdb) print it->what
$1 = IT_CHARACTER
(gdb) print it->face_id
$2 = 11
(gdb) print FRAME_FACE_CACHE (it->f)->used
No symbol "FRAME_FACE_CACHE" in current context.
(gdb) print face
$3 = (struct face *) 0x0


regards,
Markus
-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Thu, 09 Oct 2014 11:08:32 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: kbrown@cornell.edu, 17753@debbugs.gnu.org
> 
> (gdb) print FRAME_FACE_CACHE (it->f)->used
> No symbol "FRAME_FACE_CACHE" in current context.

Please do this instead:

  (gdb) print (it->f)->face_cache->used

Thanks.

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-10-09 12:35, schrieb Eli Zaretskii:
>> Date: Thu, 09 Oct 2014 11:08:32 +0200
>> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
>> Cc: kbrown@cornell.edu, 17753@debbugs.gnu.org
>> 
>> (gdb) print FRAME_FACE_CACHE (it->f)->used
>> No symbol "FRAME_FACE_CACHE" in current context.
> 
> Please do this instead:
> 
>   (gdb) print (it->f)->face_cache->used
> 
> Thanks.

Here you go:

(gdb) print (it->f)->face_cache->used
$4 = 31


regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Thu, 09 Oct 2014 12:44:44 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: kbrown@cornell.edu, 17753@debbugs.gnu.org
> 
> (gdb) print (it->f)->face_cache->used
> $4 = 31

??? That's unexpected.  What about this one:

  (gdb) print (it->f)->face_cache->faces_by_id[it->face_id]

(The above is the expansion of the call to the FACE_FROM_ID macro,
which, judging by your backtrace, yielded a NULL pointer.)

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-10-09 13:22, schrieb Eli Zaretskii:
>> Date: Thu, 09 Oct 2014 12:44:44 +0200
>> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
>> Cc: kbrown@cornell.edu, 17753@debbugs.gnu.org
>> 
>> (gdb) print (it->f)->face_cache->used
>> $4 = 31
> 
> ??? That's unexpected.  What about this one:
> 
>   (gdb) print (it->f)->face_cache->faces_by_id[it->face_id]
> 
> (The above is the expansion of the call to the FACE_FROM_ID macro,
> which, judging by your backtrace, yielded a NULL pointer.)

This one yields:

(gdb) print (it->f)->face_cache->faces_by_id[it->face_id]
$5 = (struct face *) 0x60128bad0


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Thu, 09 Oct 2014 13:47:34 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: kbrown@cornell.edu, 17753@debbugs.gnu.org
> 
> Am 2014-10-09 13:22, schrieb Eli Zaretskii:
> >> Date: Thu, 09 Oct 2014 12:44:44 +0200
> >> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> >> Cc: kbrown@cornell.edu, 17753@debbugs.gnu.org
> >> 
> >> (gdb) print (it->f)->face_cache->used
> >> $4 = 31
> > 
> > ??? That's unexpected.  What about this one:
> > 
> >   (gdb) print (it->f)->face_cache->faces_by_id[it->face_id]
> > 
> > (The above is the expansion of the call to the FACE_FROM_ID macro,
> > which, judging by your backtrace, yielded a NULL pointer.)
> 
> This one yields:
> 
> (gdb) print (it->f)->face_cache->faces_by_id[it->face_id]
> $5 = (struct face *) 0x60128bad0

So maybe this crash _is_ for the same reason that caused the other
crashes in this bug report.  Observe what the relevant portion of
get_next_display_element (the function in frame #1 of your backtrace)
does:

  if ((it->what == IT_CHARACTER || it->what == IT_COMPOSITION)
      && it->multibyte_p
      && success_p
      && FRAME_WINDOW_P (it->f))
    {
      struct face *face = FACE_FROM_ID (it->f, it->face_id);

      if (it->what == IT_COMPOSITION && it->cmp_it.ch >= 0)
	{
	  /* Automatic composition with glyph-string.   */
	  Lisp_Object gstring = composition_gstring_from_id (it->cmp_it.id);

	  it->face_id = face_for_font (it->f, LGSTRING_FONT (gstring), face);
	}
      else
	{
	  ptrdiff_t pos = (it->s ? -1
		     : STRINGP (it->string) ? IT_STRING_CHARPOS (*it)
		     : IT_CHARPOS (*it));
	  int c;

	  if (it->what == IT_CHARACTER)
	    c = it->char_to_display;
	  else
	    {
	      struct composition *cmp = composition_table[it->cmp_it.id];
	      int i;

	      c = ' ';
	      for (i = 0; i < cmp->glyph_len; i++)
		/* TAB in a composition means display glyphs with
		   padding space on the left or right.  */
		if ((c = COMPOSITION_GLYPH (cmp, i)) != '\t')
		  break;
	    }
	  it->face_id = FACE_FOR_CHAR (it->f, face, c, pos, it->string);

The last line is the one that called face_for_char with the 'face'
argument a NULL pointer.  But the value of 'face' was computed by this
line:

      struct face *face = FACE_FROM_ID (it->f, it->face_id);

which, if you repeat it in GDB, yields a non-NULL pointer.  So how
could it become a NULL pointer when the code was executed??  Am I
missing something here?

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

Markus,

The suggestion has come up in a different bug report 
(http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438#160) that emacs 
might need a larger stack.  Please issue the following command (as 
administrator, while emacs is not running) and see if the crashes stop:

   peflags -x0x800000 /usr/bin/emacs-X11.exe

Thanks.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-10-11 17:31, schrieb Ken Brown:
> Markus,
> 
> The suggestion has come up in a different bug report
> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438#160) that emacs
> might need a larger stack.  Please issue the following command (as
> administrator, while emacs is not running) and see if the crashes
> stop:
> 
>   peflags -x0x800000 /usr/bin/emacs-X11.exe
> 
> Thanks.
> 
> Ken

Hi,

I'll be out of office for a week, but I'll sure give it a try as soon as 
I'm back at my desk.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-10-11 17:31, Ken Brown was heard to say:
> Markus,
> 
> The suggestion has come up in a different bug report
> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438#160) that emacs
> might need a larger stack.  Please issue the following command (as
> administrator, while emacs is not running) and see if the crashes
> stop:
> 
>   peflags -x0x800000 /usr/bin/emacs-X11.exe
> 
> Thanks.
> 
> Ken

no joy, unfortunately. I did as advised, but it barely took one hour 
back in office when Emacs crashed again. This time there is no useful 
information from the thread which apparently caused the crash. Could 
that be a consequence of the new stack size? Would it make sense to 
revert? If so, how?

regards,
Markus

$ gdb /usr/bin/emacs-X11
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/emacs-X11...Reading symbols from 
/usr/lib/debug//usr/bin/emacs-X11.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/emacs-X11
[New Thread 1256.0x6e8]
[New Thread 1256.0xf98]
[New Thread 1256.0xfb0]
[New Thread 1256.0xed0]
[New Thread 1256.0xfa8]
[New Thread 1256.0xf14]
[New Thread 1256.0x304]
[New Thread 1256.0xdf8]
[New Thread 1256.0xea0]
[New Thread 1256.0xfb8]
[New Thread 1256.0x1140]
[Thread 1256.0xfb8 exited with code 0]
[Thread 1256.0x1140 exited with code 0]
[Thread 1256.0x304 exited with code 0]

Program received signal SIGABRT, Aborted.
0x000000000082e2a8 in ?? ()
(gdb) info threads
   Id   Target Id         Frame
   9    Thread 1256.0xea0 0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   8    Thread 1256.0xdf8 0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   6    Thread 1256.0xf14 0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   5    Thread 1256.0xfa8 0x00000000774b15fa in ntdll!ZwDelayExecution ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 1256.0xed0 0x00000000774b186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 1256.0xfb0 0x00000000774b186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   2    Thread 1256.0xf98 0x000007fefd62940d in RaiseException ()
    from /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
* 1    Thread 1256.0x6e8 0x000000000082e2a8 in ?? ()
(gdb) thread apply all bt

Thread 9 (Thread 1256.0xea0):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0500 <threads+352>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x620ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0500 <threads+352>, 
buf=buf@entry=0x620cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 8 (Thread 1256.0xdf8):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d04a8 <threads+264>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x5a0ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d04a8 <threads+264>, 
buf=buf@entry=0x5a0cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 6 (Thread 1256.0xf14):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03f8 <threads+88>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x420ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03f8 <threads+88>, 
buf=buf@entry=0x420cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 5 (Thread 1256.0xfa8):
#0  0x00000000774b15fa in ntdll!ZwDelayExecution ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd621203 in SleepEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018010d970 in thread_pipe(void*) (arg=0x60005dea0)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690
#3  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d0450
  <threads+176>, issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0450 <threads+176>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x4a0ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0450 <threads+176>, 
buf=buf@entry=0x4a0cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in  ()

Thread 4 (Thread 1256.0xed0):
#0  0x00000000774b186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd621430 in KERNELBASE!GetCurrentProcess ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in  ()

Thread 3 (Thread 1256.0xfb0):
#0  0x00000000774b186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007747b037 in ntdll!TpIsTimerSet ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in  ()

Thread 2 (Thread 1256.0xf98):
#0  0x000007fefd62940d in RaiseException ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#1  0x000007fefd63aa0d in OutputDebugStringA ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018007119e in _cygtls::signal_debugger(siginfo_t&) 
(this=this@entry=0x82ce00, si=...)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/exceptions.cc:1505
#3  0x000000018007132e in sigpacket::process() 
(this=this@entry=0x1801e3260 <sigq+1056>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/exceptions.cc:1364
#4  0x0000000180119952 in wait_sig(void*) ()
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/sigproc.cc:1320
#5  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03a0 <threads>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#6  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03a0 <threads>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#7  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x2a1ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03a0 <threads>, 
buf=buf@entry=0x2a1cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#8  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#9  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#10 0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#11 0x0000000000000000 in  ()

Thread 1 (Thread 1256.0x6e8):
#0  0x000000000082e2a8 in  ()

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 10/20/2014 6:59 AM, Markus Hoenicka wrote:
> At 2014-10-11 17:31, Ken Brown was heard to say:
>> Markus,
>>
>> The suggestion has come up in a different bug report
>> (http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438#160) that emacs
>> might need a larger stack.  Please issue the following command (as
>> administrator, while emacs is not running) and see if the crashes
>> stop:
>>
>>   peflags -x0x800000 /usr/bin/emacs-X11.exe
>>
>> Thanks.
>>
>> Ken
>
> no joy, unfortunately. I did as advised, but it barely took one hour back in
> office when Emacs crashed again. This time there is no useful information from
> the thread which apparently caused the crash. Could that be a consequence of the
> new stack size? Would it make sense to revert? If so, how?

I'm not aware of any reason that increasing the stack size should make things 
worse.  But I don't understand these crashes anyway, so who knows?  If you want 
to experiment, you can restore the previous stack size with the command

   peflags -x0x400000 /usr/bin/emacs-X11.exe

(My builds for the x86_64 Cygwin distribution have been using a 4MB stack size 
for over a year.)

Ken

bug#17753: Cygwin emacs-X11 core dump

[martin rudalics]

 > I'm not aware of any reason that increasing the stack size should make things worse.

You could try to artificially make the stack size smaller on your
system.  Then you should be either able to trigger similar crashes on
your system or exclude the possibility that the stack size has any
influence.

martin

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 10/20/2014 8:04 AM, martin rudalics wrote:
>  > I'm not aware of any reason that increasing the stack size should make things
> worse.
>
> You could try to artificially make the stack size smaller on your
> system.  Then you should be either able to trigger similar crashes on
> your system or exclude the possibility that the stack size has any
> influence.

Good idea.  Thanks.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-10-20 13:29 Ken Brown was heard to say:
> I'm not aware of any reason that increasing the stack size should make
> things worse.  But I don't understand these crashes anyway, so who
> knows?  If you want to experiment, you can restore the previous stack
> size with the command
> 
>   peflags -x0x400000 /usr/bin/emacs-X11.exe
> 
> (My builds for the x86_64 Cygwin distribution have been using a 4MB
> stack size for over a year.)
> 
> Ken

Hi,

I've followed Martin's suggestion to decrease the stack size. I can't 
comment yet if it makes crashes more frequent, but in any case I got 
another nice crash this afternoon. This crash happened while publishing 
my planner pages to xhtml. As my planner project has grown pretty large, 
I am used to running into a problem when the index page is about to 
being created. This requires extensive regexps, and I used to see an 
error saying something along the lines "stack overflow in regexp 
matcher" [1]. However, this never caused Emacs to crash. With a smaller 
stack this seems to cause a segmentation fault as shown below. I don't 
know if it is worth exploring this path. Most crashes were not triggered 
by planner publishing, although I cannot exclude that I issued the 
command in all sessions that would crash eventually. I'll try another 
couple of days to see whether crashes get more frequent. Otherwise I'll 
revert to larger stack sizes again.

regards,
Markus

[1] 
http://nongnu.13855.n7.nabble.com/stack-overflow-in-regexp-matcher-td173623.html

$ peflags -x0x100000 /usr/bin/emacs-X11.exe
$ gdb /usr/bin/emacs-X11
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/emacs-X11...Reading symbols from 
/usr/lib/debug//usr/bin/emacs-X11.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/emacs-X11
[New Thread 6096.0x174c]
[New Thread 6096.0x8b0]
[New Thread 6096.0x11f0]
[New Thread 6096.0x1664]
[New Thread 6096.0x13e4]
[New Thread 6096.0x1544]
[New Thread 6096.0x14a8]
[New Thread 6096.0x115c]
[New Thread 6096.0xb0]
[New Thread 6096.0x1284]
[New Thread 6096.0x10ec]
[Thread 6096.0x10ec exited with code 0]
[Thread 6096.0x1284 exited with code 0]
[Thread 6096.0x14a8 exited with code 0]

Program received signal SIGSEGV, Segmentation fault.
___chkstk_ms () at 
/usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S:146
146     /usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S: No such 
file or directory.
(gdb) info threads
   Id   Target Id         Frame
   9    Thread 6096.0xb0  0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   8    Thread 6096.0x115c 0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   6    Thread 6096.0x1544 0x00000000774b15fa in ntdll!ZwDelayExecution 
()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   5    Thread 6096.0x13e4 0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 6096.0x1664 0x00000000774b186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 6096.0x11f0 0x00000000774b186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   2    Thread 6096.0x8b0 0x00000000774b131a in ntdll!ZwReadFile ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
* 1    Thread 6096.0x174c ___chkstk_ms ()
     at /usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S:146
Thread 9 (Thread 6096.0xb0):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0500 <threads+352>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x28ace00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0500 <threads+352>, 
buf=buf@entry=0x28acd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 8 (Thread 6096.0x115c):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d04a8 <threads+264>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x27ace00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d04a8 <threads+264>, 
buf=buf@entry=0x27acd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 6 (Thread 6096.0x1544):
#0  0x00000000774b15fa in ntdll!ZwDelayExecution ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd621203 in SleepEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018010d970 in thread_pipe(void*) (arg=0x60005df00)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690
#3  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03f8 <threads+88>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03f8 <threads+88>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x221ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03f8 <threads+88>, 
buf=buf@entry=0x221cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in  ()

Thread 5 (Thread 6096.0x13e4):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018013db94 in timer_thread(void*) (x=0x245a9d8)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/timer.cc:145
#3  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d0450 <threads+176>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0450 <threads+176>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x245ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0450 <threads+176>, 
buf=buf@entry=0x245cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in  ()

Thread 4 (Thread 6096.0x1664):
#0  0x00000000774b186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd621430 in KERNELBASE!GetCurrentProcess ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in  ()

Thread 3 (Thread 6096.0x11f0):
#0  0x00000000774b186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007747b037 in ntdll!TpIsTimerSet ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in  ()

Thread 2 (Thread 6096.0x8b0):
#0  0x00000000774b131a in ntdll!ZwReadFile ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd621a7a in ReadFile ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000077250a19 in ReadFile ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x00000001801197c2 in wait_sig(void*) ()
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/sigproc.cc:1239
#4  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03a0 <threads>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#5  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03a0 <threads>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#6  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x2ece00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03a0 <threads>, 
buf=buf@entry=0x2ecd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#7  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#8  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#9  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#10 0x0000000000000000 in  ()

Thread 1 (Thread 6096.0x174c):
#0  0x00000001005c2906 in ___chkstk_ms ()
     at /usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S:146
#1  0x00000001005191da in re_match_2_internal 
(bufp=bufp@entry=0x1009318e0 <searchbufs+2912>, string1=0x100947032 
<bss_sbrk_buffer+45010> "",
     string1@entry=0x6ffeb3b0028 
"<ul>\n<li>[[20080604Schmid]]</li>\n<li>[[20080606Puehler]]</li>\n<li>[[20080606Schrammel]]</li>\n<li>[[20080611VS4d]]</li>\n<li>[[20080612VS4d]]</li>\n<li>[[20080613LaborSeminar]]</li>\n<li>[[20080616Meeting"..., 
size1=1211788, size1@entry=37410, string2=0x0,
     string2@entry=0x6ffeb3b9547 "\n\n\n2016.06 | [[2016.06.01][.01 
]]\n2015.08 | [[2015.08.31][.31 ]] [[2015.08.18][.18 ]]\n2015.02 | 
[[2015.02.11][.11 ]] [[2015.02.08][.08 ]] [[2015.02.01][.01 ]]\n2015.01 
| [[2015.01.30][.30 ]] [[2015.01."..., size2=71758, size2@entry=34348, 
pos=<optimized out>,
     pos@entry=37412, regs=<optimized out>,
     regs@entry=0x100930d60 <search_regs>, stop=<optimized out>,
     stop@entry=71758) at /usr/src/debug/emacs-24.3.93-3/src/regex.c:5802
#2  0x000000010051edf1 in re_search_2 (bufp=bufp@entry=0x100516777 
<search_command+343>, str1=0x6ffeb3b0028 
"<ul>\n<li>[[20080604Schmid]]</li>\n<li>[[20080606Puehler]]</li>\n<li>[[20080606Schrammel]]</li>\n<li>[[20080611VS4d]]</li>\n<li>[[20080612VS4d]]</li>\n<li>[[20080613LaborSeminar]]</li>\n<li>[[20080616Meeting"..., 
str1@entry=0x6024d2c20 "E \003\006", size1=37410,
     size1@entry=25808415781, str2=0x6ffeb3b9547 "\n\n\n2016.06 | 
[[2016.06.01][.01 ]]\n2015.08 | [[2015.08.31][.31 ]] [[2015.08.18][.18 
]]\n2015.02 | [[2015.02.11][.11 ]] [[2015.02.08][.08 ]] 
[[2015.02.01][.01 ]]\n2015.01 | [[2015.01.30][.30 ]] [[2015.01."..., 
str2@entry=0x0, size2=34348,
     size2@entry=4304695394, startpos=37412,
     startpos@entry=0, range=34346, regs=0x100930d60 <search_regs>, 
stop=71758)
     at /usr/src/debug/emacs-24.3.93-3/src/regex.c:4441
#3  0x00000001005156ab in search_buffer 
(string=string@entry=25778416977, pos=<optimized out>, 
pos_byte=<optimized out>, lim=lim@entry=71759, 
lim_byte=lim_byte@entry=71759, n=n@entry=1, RE=RE@entry=1, 
trt=4304695346, inverse_trt=4304695346, posix=posix@entry=false) at 
/usr/src/debug/emacs-24.3.93-3/src/search.c:1268
#4  0x0000000100516777 in search_command (string=25778416977, 
bound=<optimized out>, noerror=4304695394, count=<optimized out>, 
direction=direction@entry=1, RE=RE@entry=1, posix=posix@entry=false)
     at /usr/src/debug/emacs-24.3.93-3/src/search.c:1061
#5  0x0000000100516981 in Fre_search_forward (regexp=<optimized out>, 
bound=<optimized out>, noerror=<optimized out>, count=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/search.c:2243
#6  0x0000000100540f16 in Ffuncall (nargs=<optimized out>, 
args=<optimized out>) at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2826
#7  0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1212640, args=0x4)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#8  0x00000001005409b3 in funcall_lambda (fun=25778253397, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x128350)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#9  0x0000000100540d4b in Ffuncall (nargs=3, args=0x128348)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#10 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1213248, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#11 0x00000001005409b3 in funcall_lambda (fun=25778254085, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x1285b0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#12 0x0000000100540d4b in Ffuncall (nargs=3, args=0x1285a8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#13 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1213856, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#14 0x00000001005409b3 in funcall_lambda (fun=25778628541, 
nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x1287e8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#15 0x0000000100540d4b in Ffuncall (nargs=nargs@entry=4, 
args=args@entry=0x1287e0) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#16 0x00000001005421f0 in Fapply (nargs=<optimized out>, args=0x128940)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2354
#17 0x0000000100540e25 in Ffuncall (nargs=<optimized out>, 
args=<optimized out>) at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2796
#18 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1214768, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#19 0x00000001005409b3 in funcall_lambda (fun=25778275893, 
nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x128b90)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#20 0x0000000100540d4b in Ffuncall (nargs=1, args=0x128b88)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#21 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1215360, args=0x1)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#22 0x00000001005409b3 in funcall_lambda (fun=25778253397, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x128df0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#23 0x0000000100540d4b in Ffuncall (nargs=3, args=0x128de8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#24 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1215968, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#25 0x00000001005409b3 in funcall_lambda (fun=25778254085, 
nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x129050)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#26 0x0000000100540d4b in Ffuncall (nargs=5, args=0x129048)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#27 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1216576, args=0x5)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#28 0x00000001005409b3 in funcall_lambda (fun=25778254429, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x1292d0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#29 0x0000000100540d4b in Ffuncall (nargs=3, args=0x1292c8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#30 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1217216, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#31 0x0000000100577eb5 in Fbyte_code (bytestr=<optimized out>, 
vector=<optimized out>, maxdepth=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:482
#32 0x00000001005403e1 in eval_sub (form=form@entry=1)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2191
#33 0x0000000100543899 in internal_lisp_condition_case (var=<optimized 
out>, bodyform=1, handlers=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:1323
#34 0x0000000100575d6b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1217976, args=0x8f)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:1162
#35 0x00000001005409b3 in funcall_lambda (fun=25778274117, 
nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x129820)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#36 0x0000000100540d4b in Ffuncall (nargs=5, args=0x129818)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#37 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1218576, args=0x5)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#38 0x00000001005409b3 in funcall_lambda (fun=25778626765, 
nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x129a60)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#39 0x0000000100540d4b in Ffuncall (nargs=5, args=0x129a58)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#40 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1219152, args=0x5)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#41 0x00000001005409b3 in funcall_lambda (fun=4308463549, 
nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x129cb0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#42 0x0000000100540d4b in Ffuncall (nargs=4, args=0x129ca8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#43 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1219744, args=0x4)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#44 0x00000001005409b3 in funcall_lambda (fun=4308467029, 
nargs=nargs@entry=3, a
rg_vector=arg_vector@entry=0x129ef0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#45 0x0000000100540d4b in Ffuncall (nargs=4, args=0x129ee8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#46 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1220328, args=0x4)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#47 0x00000001005409b3 in funcall_lambda (fun=4308467293, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x12a128)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#48 0x0000000100540d4b in Ffuncall (nargs=nargs@entry=3, 
args=args@entry=0x12a120) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#49 0x00000001005421f0 in Fapply (nargs=nargs@entry=2, 
args=args@entry=0x12a1e0) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:2354
#50 0x00000001005423f3 in apply1 (fn=25778102130,
     fn@entry=1, arg=arg@entry=25805502694)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2588
#51 0x000000010053cde7 in Fcall_interactively (function=1, 
record_flag=1221352, keys=0) at 
/usr/src/debug/emacs-24.3.93-3/src/callint.c:378
#52 0x0000000100540f2a in Ffuncall (nargs=<optimized out>, 
args=<optimized out>) at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2822
#53 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4100, nargs=1221640, args=0x4)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#54 0x0000000100540a48 in funcall_lambda (fun=4301989645, 
nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x12a678)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2983
#55 0x0000000100540d4b in Ffuncall (nargs=nargs@entry=2, 
args=args@entry=0x12a670) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#56 0x000000010054109d in call1 (fn=<optimized out>, arg1=<optimized 
out>)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2614
#57 0x00000001004def7e in command_loop_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1559
#58 0x000000010053f37d in internal_condition_case 
(bfun=bfun@entry=0x1004debc0 <command_loop_1>, handlers=<optimized out>, 
hfun=hfun@entry=0x1004d54a0 <cmd_error>) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:1354
#59 0x00000001004d09ea in command_loop_2 
(ignore=ignore@entry=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1177
#60 0x000000010053f27c in internal_catch (tag=4304765794, 
func=func@entry=0x1004d09c0 <command_loop_2>, arg=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:1118
#61 0x00000001004d5094 in recursive_edit_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1156
#62 0x00000001004d5094 in recursive_edit_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:777
#63 0x00000001004d53b6 in Frecursive_edit ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:848
#64 0x00000001005c46d9 in main (argc=<optimized out>, argv=<optimized 
out>)
     at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:1647

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-10-20 13:29 Ken Brown was heard to say:
> 
> I'm not aware of any reason that increasing the stack size should make
> things worse.  But I don't understand these crashes anyway, so who
> knows?  If you want to experiment, you can restore the previous stack
> size with the command
> 
>   peflags -x0x400000 /usr/bin/emacs-X11.exe
> 
> (My builds for the x86_64 Cygwin distribution have been using a 4MB
> stack size for over a year.)
> 
> Ken

I should have tried this first, but anyway: with a stack size of 1 MB 
there seems to be a reproducible way to crash emacs-X11.exe, although I 
can't tell if this is just an artifact unrelated to the problem that I 
reported initially. The segfault seems to be the same as previously 
reported, see the attached backtrace. Problem is, this is probably not a 
good testcase for reproducing this bug, as it may depend on the 
complexity of the planner project in question. Is it reasonable to think 
that publishing planner pages screws up the stack, but doesn't crash 
Emacs right away as long as the stack is large enough? I'll be happy to 
provide the planner project and all related .emacs entries if anyone 
wants to fiddle with them. However, I'll have to increase the stack size 
again over here in order to get some work done.

In a nutshell, this is apparently what it takes to reproduce the crash:

- install muse mode
- install planner mode
- create a planner project with quite a few pages (mine has approx. 2800 
pages)
- run C-x C-p to publish the pages to xhtml

regards,
Markus


$ gdb /usr/bin/emacs-X11
GNU gdb (GDB) 7.8
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/emacs-X11...Reading symbols from 
/usr/lib/debug//usr/bin/emacs-X11.exe.dbg...done.
done.
(gdb) run
Starting program: /usr/bin/emacs-X11
[New Thread 4112.0x1448]
[New Thread 4112.0x1144]
[New Thread 4112.0x169c]
[New Thread 4112.0x163c]
[New Thread 4112.0xb7c]
[New Thread 4112.0xd4c]
[New Thread 4112.0x1424]
[New Thread 4112.0x1778]
[New Thread 4112.0x10a8]
[New Thread 4112.0x14bc]
[New Thread 4112.0x1084]

Program received signal SIGSEGV, Segmentation fault.
___chkstk_ms () at 
/usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S:146
146     /usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S: No such 
file or directory.
(gdb) info threads
   Id   Target Id         Frame
   11   Thread 4112.0x1084 0x00000000774b2bba in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   10   Thread 4112.0x14bc 0x00000000774b2bba in 
ntdll!ZwWaitForWorkViaWorkerFactory () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   9    Thread 4112.0x10a8 0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   8    Thread 4112.0x1778 0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   7    Thread 4112.0x1424 0x00000000774b134a in 
ntdll!ZwRemoveIoCompletion ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   6    Thread 4112.0xd4c 0x00000000774b15fa in ntdll!ZwDelayExecution ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   5    Thread 4112.0xb7c 0x00000000774b12fa in 
ntdll!ZwWaitForSingleObject ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   4    Thread 4112.0x163c 0x00000000774b186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   3    Thread 4112.0x169c 0x00000000774b186a in 
ntdll!ZwWaitForMultipleObjects
     () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
   2    Thread 4112.0x1144 0x00000000774b131a in ntdll!ZwReadFile ()
    from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
* 1    Thread 4112.0x1448 ___chkstk_ms ()
     at /usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S:146
(gdb) thread apply all bt

Thread 11 (Thread 4112.0x1084):
#0  0x00000000774b2bba in ntdll!ZwWaitForWorkViaWorkerFactory ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007747fe3b in ntdll!RtlValidateHeap ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x0, func=0x0, arg=0x372e70, 
buf=buf@entry=0x2b4cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#3  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#4  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#5  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x0000000000000000 in  ()

Thread 10 (Thread 4112.0x14bc):
#0  0x00000000774b2bba in ntdll!ZwWaitForWorkViaWorkerFactory ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007747fe3b in ntdll!RtlValidateHeap ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x0, func=0x0, arg=0x372e70, 
buf=buf@entry=0x2a4cd50)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#3  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#4  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#5  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x0000000000000000 in  ()

Thread 9 (Thread 4112.0x10a8):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0500 <threads+352>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x294ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0500 <threads+352>, 
buf=buf@entry=0x294cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 8 (Thread 4112.0x1778):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000180045561 in cygthread::stub(void*) 
(arg=arg@entry=0x1801d04a8 <threads+264>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:114
#3  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x284ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d04a8 <threads+264>, 
buf=buf@entry=0x284cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#4  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#5  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#6  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x0000000000000000 in  ()

Thread 7 (Thread 4112.0x1424):
#0  0x00000000774b134a in ntdll!ZwRemoveIoCompletion ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefcb75971 in  () at 
/cygdrive/c/WINDOWS/System32/mswsock.dll
#2  0x0000000000000000 in  ()

Thread 6 (Thread 4112.0xd4c):
#0  0x00000000774b15fa in ntdll!ZwDelayExecution ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd621203 in SleepEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018010d970 in thread_pipe(void*) (arg=0x60005df10)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/select.cc:690
#3  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03f8 <threads+88>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03f8 <thr
eads+88>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x241ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03f8 <threads+88>, 
buf=buf@entry=0x241cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in  ()

Thread 5 (Thread 4112.0xb7c):
#0  0x00000000774b12fa in ntdll!ZwWaitForSingleObject ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd6210dc in WaitForSingleObjectEx ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x000000018013db94 in timer_thread(void*) (x=0x264a9d8)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/timer.cc:145
#3  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d0450 <threads+176>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#4  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d0450 <threads+176>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#5  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x264ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d0450 <threads+176>, 
buf=buf@entry=0x264cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#6  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#7  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#8  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in  ()

Thread 4 (Thread 4112.0x163c):
#0  0x00000000774b186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd621430 in KERNELBASE!GetCurrentProcess ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000000000000 in  ()

Thread 3 (Thread 4112.0x169c):
#0  0x00000000774b186a in ntdll!ZwWaitForMultipleObjects ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000000007747b037 in ntdll!TpIsTimerSet ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in  ()

Thread 2 (Thread 4112.0x1144):
#0  0x00000000774b131a in ntdll!ZwReadFile ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x000007fefd621a7a in ReadFile ()
     at /cygdrive/c/WINDOWS/system32/KERNELBASE.dll
#2  0x0000000077250a19 in ReadFile ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#3  0x00000001801197c2 in wait_sig(void*) ()
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/sigproc.cc:1239
#4  0x0000000180044fc5 in cygthread::callfunc(bool) 
(this=this@entry=0x1801d03a0 <threads>, 
issimplestub=issimplestub@entry=false)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:51
#5  0x000000018004552a in cygthread::stub(void*) 
(arg=arg@entry=0x1801d03a0 <threads>) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygthread.cc:93
#6  0x000000018004619b in _cygtls::call2(unsigned int (*)(void*, void*), 
void*, void*) (this=0x1c6ce00, func=
     0x1800454d0 <cygthread::stub(void*)>, arg=0x1801d03a0 <threads>, 
buf=buf@entry=0x1c6cd50) at 
/usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:100
#7  0x00000001800462f4 in _cygtls::call(unsigned int (*)(void*, void*), 
void*) (func=<optimized out>, arg=<optimized out>)
     at /usr/src/debug/cygwin-1.7.32-1/winsup/cygwin/cygtls.cc:30
#8  0x00000000772559ed in KERNEL32!BaseThreadInitThunk ()
     at /cygdrive/c/WINDOWS/system32/kernel32.dll
#9  0x000000007748c541 in ntdll!RtlUserThreadStart ()
     at /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#10 0x0000000000000000 in  ()

Thread 1 (Thread 4112.0x1448):
#0  0x00000001005c2906 in ___chkstk_ms ()
     at /usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S:146
#1  0x00000001005191da in re_match_2_internal 
(bufp=bufp@entry=0x100931340 <searchbufs+1472>, string1=0x100947032 
<bss_sbrk_buffer+45010> "",
     string1@entry=0x6fffed00028 
"<ul>\n<li>[[20080604Schmid]]</li>\n<li>[[20080606Puehler]]</li>\n<li>[[20080606Schrammel]]</li>\n<li>[[20080611VS4d]]</li>\n<li>[[20080612VS4d]]</li>\n<li>[[20080613LaborSeminar]]</li>\n<li>[[20080616Meeting"..., 
size1=1211788, size1@entry=37410, string2=0x0,
     string2@entry=0x6fffed09547 "\n\n\n2016.06 | [[2016.06.01][.01 
]]\n2015.08 | [[2015.08.31][.31 ]] [[2015.08.18][.18 ]]\n2015.02 | 
[[2015.02.11][.11 ]] [[2015.02.08][.08 ]] [[2015.02.01][.01 ]]\n2015.01 
| [[2015.01.30][.30 ]] [[2015.01."..., size2=71758, size2@entry=34348, 
pos=<optimized out>,
     pos@entry=37412, regs=<optimized out>,
     regs@entry=0x100930d60 <search_regs>, stop=<optimized out>,
     stop@entry=71758) at /usr/src/debug/emacs-24.3.93-3/src/regex.c:5802
#2  0x000000010051edf1 in re_search_2 (bufp=bufp@entry=0x100516777 
<search_command+343>, str1=0x6fffed00028 
"<ul>\n<li>[[20080604Schmid]]</li>\n<li>[[20080606Puehler]]</li>\n<li>[[20080606Schrammel]]</li>\n<li>[[20080611VS4d]]</li>\n<li>[[20080612VS4d]]</li>\n<li>[[20080613LaborSeminar]]</li>\n<li>[[20080616Meeting"..., 
str1@entry=0x600ed3d60 "E \003\006", size1=37410,
     size1@entry=25785351525, str2=0x6fffed09547 "\n\n\n2016.06 | 
[[2016.06.01][.01 ]]\n2015.08 | [[2015.08.31][.31 ]] [[2015.08.18][.18 
]]\n2015.02 | [[2015.02.11][.11 ]] [[2015.02.08][.08 ]] 
[[2015.02.01][.01 ]]\n2015.01 | [[2015.01.30][.30 ]] [[2015.01."..., 
str2@entry=0x0, size2=34348,
     size2@entry=4304695394, startpos=37412,
     startpos@entry=0, range=34346, regs=0x100930d60 <search_regs>, 
stop=71758)
     at /usr/src/debug/emacs-24.3.93-3/src/regex.c:4441
#3  0x00000001005156ab in search_buffer 
(string=string@entry=25778427505, pos=<optimized out>, 
pos_byte=<optimized out>, lim=lim@entry=71759, 
lim_byte=lim_byte@entry=71759, n=n@entry=1, RE=RE@entry=1, 
trt=4304695346, inverse_trt=4304695346, posix=posix@entry=false) at 
/usr/src/debug/emacs-24.3.93-3/src/search.c:1268
#4  0x0000000100516777 in search_command (string=25778427505, 
bound=<optimized out>, noerror=4304695394, count=<optimized out>, 
direction=direction@entry=1, RE=RE@entry=1, posix=posix@entry=false)
     at /usr/src/debug/emacs-24.3.93-3/src/search.c:1061
#5  0x0000000100516981 in Fre_search_forward (regexp=<optimized out>, 
bound=<optimized out>, noerror=<optimized out>, count=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/search.c:2243
#6  0x0000000100540f16 in Ffuncall (nargs=<optimized out>, 
args=<optimized out>) at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2826
#7  0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1212640, args=0x4)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#8  0x00000001005409b3 in funcall_lambda (fun=25778262613, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x128350)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#9  0x0000000100540d4b in Ffuncall (nargs=3, args=0x128348)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#10 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1213248, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#11 0x00000001005409b3 in funcall_lambda (fun=25778263301, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x1285b0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#12 0x0000000100540d4b in Ffuncall (nargs=3, args=0x1285a8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#13 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1213856, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#14 0x00000001005409b3 in funcall_lambda (fun=25778638989, 
nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x1287e8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#15 0x0000000100540d4b in Ffuncall (nargs=nargs@entry=4, 
args=args@entry=0x1287e0) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#16 0x00000001005421f0 in Fapply (nargs=<optimized out>, args=0x128940)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2354
#17 0x0000000100540e25 in Ffuncall (nargs=<optimized out>, 
args=<optimized out>) at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2796
#18 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1214768, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#19 0x00000001005409b3 in funcall_lambda (fun=25778285109, 
nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x128b90)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#20 0x0000000100540d4b in Ffuncall (nargs=1, args=0x128b88)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#21 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1215360, args=0x1)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#22 0x00000001005409b3 in funcall_lambda (fun=25778262613, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x128df0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#23 0x0000000100540d4b in Ffuncall (nargs=3, args=0x128de8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#24 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1215968, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#25 0x00000001005409b3 in funcall_lambda (fun=25778263301, 
nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x129050)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#26 0x0000000100540d4b in Ffuncall (nargs=5, args=0x129048)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#27 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1216576, args=0x5)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#28 0x00000001005409b3 in funcall_lambda (fun=25778263645, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x1292d0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#29 0x0000000100540d4b in Ffuncall (nargs=3, args=0x1292c8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#30 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1217216, args=0x3)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#31 0x0000000100577eb5 in Fbyte_code (bytestr=<optimized out>, 
vector=<optimized out>, maxdepth=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:482
#32 0x00000001005403e1 in eval_sub (form=form@entry=1)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2191
#33 0x0000000100543899 in internal_lisp_condition_case (var=<optimized 
out>, bodyform=1, handlers=<optimized out>)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:1323
#34 0x0000000100575d6b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1217976, args=0x8f)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:1162
#35 0x00000001005409b3 in funcall_lambda (fun=25778283333, 
nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x129820)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#36 0x0000000100540d4b in Ffuncall (nargs=5, args=0x129818)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#37 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1218576, args=0x5)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#38 0x00000001005409b3 in funcall_lambda (fun=25778637213, 
nargs=nargs@entry=4, arg_vector=arg_vector@entry=0x129a60)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#39 0x0000000100540d4b in Ffuncall (nargs=5, args=0x129a58)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#40 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1219152, args=0x5)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#41 0x00000001005409b3 in funcall_lambda (fun=4308463549, 
nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x129cb0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#42 0x0000000100540d4b in Ffuncall (nargs=4, args=0x129ca8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#43 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1219744, args=0x4)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#44 0x00000001005409b3 in funcall_lambda (fun=4308467029, 
nargs=nargs@entry=3, arg_vector=arg_vector@entry=0x129ef0)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#45 0x0000000100540d4b in Ffuncall (nargs=4, args=0x129ee8)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#46 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4304695346, nargs=1220328, args=0x4)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#47 0x00000001005409b3 in funcall_lambda (fun=4308467293, 
nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x12a128)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:3049
#48 0x0000000100540d4b in Ffuncall (nargs=nargs@entry=3, 
args=args@entry=0x12a120) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#49 0x00000001005421f0 in Fapply (nargs=nargs@entry=2, 
args=args@entry=0x12a1e0) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:2354
#50 0x00000001005423f3 in apply1 (fn=25778330498,
     fn@entry=1, arg=arg@entry=25785408454)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2588
#51 0x000000010053cde7 in Fcall_interactively (function=1, 
record_flag=1221352, keys=0) at 
/usr/src/debug/emacs-24.3.93-3/src/callint.c:378
#52 0x0000000100540f2a in Ffuncall (nargs=<optimized out>, 
args=<optimized out>) at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2822
#53 0x000000010057503b in exec_byte_code (bytestr=79680, vector=276816, 
maxdepth=79656, args_template=4100, nargs=1221640, args=0x4)
     at /usr/src/debug/emacs-24.3.93-3/src/bytecode.c:916
#54 0x0000000100540a48 in funcall_lambda (fun=4301989645, 
nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x12a678)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2983
#55 0x0000000100540d4b in Ffuncall (nargs=nargs@entry=2, 
args=args@entry=0x12a670) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:2876
#56 0x000000010054109d in call1 (fn=<optimized out>, arg1=<optimized 
out>)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:2614
#57 0x00000001004def7e in command_loop_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1559
#58 0x000000010053f37d in internal_condition_case 
(bfun=bfun@entry=0x1004debc0 <command_loop_1>, handlers=<optimized out>, 
hfun=hfun@entry=0x1004d54a0 <cmd_error>) at 
/usr/src/debug/emacs-24.3.93-3/src/eval.c:1354
#59 0x00000001004d09ea in command_loop_2 
(ignore=ignore@entry=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1177
#60 0x000000010053f27c in internal_catch (tag=4304765794, 
func=func@entry=0x1004d09c0 <command_loop_2>, arg=4304695346)
     at /usr/src/debug/emacs-24.3.93-3/src/eval.c:1118
#61 0x00000001004d5094 in recursive_edit_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:1156
#62 0x00000001004d5094 in recursive_edit_1 ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:777
#63 0x00000001004d53b6 in Frecursive_edit ()
     at /usr/src/debug/emacs-24.3.93-3/src/keyboard.c:848
#64 0x00000001005c46d9 in main (argc=<optimized out>, argv=<optimized 
out>)
     at /usr/src/debug/emacs-24.3.93-3/src/emacs.c:1647

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Mon, 20 Oct 2014 16:37:29 +0200
> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, 17753@debbugs.gnu.org
> 
> I should have tried this first, but anyway: with a stack size of 1 MB 
> there seems to be a reproducible way to crash emacs-X11.exe, although I 
> can't tell if this is just an artifact unrelated to the problem that I 
> reported initially. The segfault seems to be the same as previously 
> reported, see the attached backtrace.

This is a real stack overflow, so 1MB is evidently too low for Emacs.
(It could be that Emacs shouldn't crash in that case, but that's a
different bug, if you want to report it.)

> Thread 1 (Thread 4112.0x1448):
> #0  0x00000001005c2906 in ___chkstk_ms ()
>      at /usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S:146

Whenever you see ___chkstk_ms at the top of the backtrace, it's a
stack overflow.  That function is the one that checks for stack
overflow.

I think this "lower your stack" attempt is driving us from the real
problem, certainly with 1MB of stack.

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-10-20 17:24 Eli Zaretskii was heard to say:
>> Date: Mon, 20 Oct 2014 16:37:29 +0200
>> From: Markus Hoenicka <markus.hoenicka@mhoenicka.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 17753@debbugs.gnu.org
>> 
>> I should have tried this first, but anyway: with a stack size of 1 MB
>> there seems to be a reproducible way to crash emacs-X11.exe, although 
>> I
>> can't tell if this is just an artifact unrelated to the problem that I
>> reported initially. The segfault seems to be the same as previously
>> reported, see the attached backtrace.
> 
> This is a real stack overflow, so 1MB is evidently too low for Emacs.
> (It could be that Emacs shouldn't crash in that case, but that's a
> different bug, if you want to report it.)
> 
>> Thread 1 (Thread 4112.0x1448):
>> #0  0x00000001005c2906 in ___chkstk_ms ()
>>      at /usr/src/debug/gcc-4.8.3-3/libgcc/config/i386/cygwin.S:146
> 
> Whenever you see ___chkstk_ms at the top of the backtrace, it's a
> stack overflow.  That function is the one that checks for stack
> overflow.
> 
> I think this "lower your stack" attempt is driving us from the real
> problem, certainly with 1MB of stack.

Thanks for the explanation. I'll continue with 8MB of stack for the time 
being.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

Markus,

In case you didn't see this announcement

   https://cygwin.com/ml/cygwin/2014-10/msg00413.html

there's a chance that the crashes you've been getting are caused by a Cygwin bug 
that (we hope) is fixed in the latest test release of Cygwin.  Please give it a try.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-10-24 23:27 Ken Brown was heard to say:
> Markus,
> 
> In case you didn't see this announcement
> 
>   https://cygwin.com/ml/cygwin/2014-10/msg00413.html
> 
> there's a chance that the crashes you've been getting are caused by a
> Cygwin bug that (we hope) is fixed in the latest test release of
> Cygwin.  Please give it a try.
> 
> Ken

Ken,

thanks for the heads-up. I have noticed the announcement and planned to 
give it a try as soon as I'm back in office next week. BTW I've upgraded 
to Emacs 24.4 and experienced one crash since, so upgrading Emacs itself 
does not fix the problem. I'm quite excited about the new Cygwin test 
release as it seems to fix a problem which would nicely explain the 
spurious and non-reproducible nature of these crashes.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

At 2014-10-24 23:27 Ken Brown was heard to say:
> Markus,
> 
> In case you didn't see this announcement
> 
>   https://cygwin.com/ml/cygwin/2014-10/msg00413.html
> 
> there's a chance that the crashes you've been getting are caused by a
> Cygwin bug that (we hope) is fixed in the latest test release of
> Cygwin.  Please give it a try.
> 
> Ken

Hi,

this is just to close this thread properly. I've upgraded the Cygwin DLL 
as suggested in the message mentioned above. I haven't seen a crash 
since. So, to sum it up: this was not an Emacs bug, but a Cygwin bug 
triggered rarely by few programs. One of them happened to be Emacs.

Thanks to all who spent some thoughts on this issue, and consider me a 
happy camper again.

Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

tags 17753 notabug
thanks

Thanks for the feedback, Markus.  For the record, the Cygwin bug is fixed as of 
cygwin-1.7.33-1.  I'm closing the bug report.

Ken

bug#17753: Cygwin emacs-X11 core dump

[Eli Zaretskii]

> Date: Mon, 20 Oct 2014 07:29:40 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, 17753@debbugs.gnu.org
> 
> I'm not aware of any reason that increasing the stack size should make things 
> worse.

There is one reason I could think of: the amount of stack memory
reserved for each thread.  If the program whose PE header specifies a
8MB stack creates additional threads, by default each thread gets 8MB
of memory address space reserved for it (not allocated, just
reserved).  I've looked in the Cygwin sources, and the way threads are
created there is like that.

This could potentially cause trouble in a memory starved system,
because it might run out of address space.  This is, of course, highly
improbably on 64-bit systems, but can happen on 32-bit systems.

However, I don't think this is a serious danger, and we are talking
about 64-bit builds anyway.

bug#17753: Cygwin emacs-X11 core dump

[Markus Hoenicka]

Am 2014-10-07 16:56, schrieb Ken Brown:
> On 10/7/2014 3:02 AM, Markus Hoenicka wrote:
>> #0  0x00000003ff120d78 in dbus_watch_handle () at 
>> /usr/bin/cygdbus-1-3.dll
>> #1  0x00000003ff105799 in dbus_bus_remove_match () at
>> /usr/bin/cygdbus-1-3.dll
>> #2  0x00000003ff106580 in dbus_connection_get_dispatch_status ()
>>      at /usr/bin/cygdbus-1-3.dll
>> #3  0x00000003ff5f17d3 in
>> cygatspi-0!atspi_key_listener_sync_type_get_type ()
>>      at /usr/bin/cygatspi-0.dll
>> #4  0x00000003fe7bd3fe in g_main_context_prepare
>> (context=context@entry=0x600109540, priority=priority@entry=0x429908)
>>      at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3340
>> #5  0x00000003fe7bdc32 in g_main_context_iterate
>> (context=context@entry=0x600109540, block=block@entry=0,
>> dispatch=dispatch@entry=0, self=<optimized out>)
>>      at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3693
>> #6  0x00000003fe7bddb8 in g_main_context_pending (context=0x600109540)
>>      at /usr/src/debug/glib2.0-2.38.2-4/glib/gmain.c:3739
>> #7  0x00000001005b2760 in xg_select (fds_lim=<optimized out>,
>> rfds=rfds@entry=0x429fa0, wfds=wfds@entry=0x429fb0, 
>> efds=efds@entry=0x0,
>> timeout=timeout@entry=0x429fc0, sigmask=sigmask@entry=0x0)
>>      at /usr/src/debug/emacs-24.3.93-3/src/xgselect.c:149
> 
> It's nice to finally see what looks like a reasonable backtrace.  To
> get more information about frames 0--3, you'll need to install some
> more debuginfo packages:  at-spi2-atk-debuginfo,
> at-spi2-core-debuginfo, and dbus-debuginfo.  I don't know if it's
> possible at this point to get gdb to read the debug information for
> cygdbus-1-3.dll and cygatspi-0.dll (once you install the debuginfo
> packages) or if you have to wait for the next crash.  I'm sure Eli
> knows.
> 
> Ken

Hi,

I just installed these additional packages. As I had to close the gdb 
window anyway, I'll wait for the next crash. Actually there was another 
crash (kindof) this afternoon, before I got round to installing the 
debuginfo packages. The crashes seem to come in pairs, for whatever 
reason. In any case, this crash left gdb spinning one of my two CPUs at 
full speed before it printed any debug information. I pulled the plug on 
the gdb process after like 20 min as it did not seem to lead anywhere.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[markus.hoenicka]

Ken Brown writes:
 > A bug in the Cygwin DLL (64-bit only) was just discovered and fixed. 
 > The bug could have prevented stack space from being committed after the 
 > initial commit.  Could you try the latest snapshot from 
 > https://cygwin.com/snapshots/ and see if these strange crashes stop?  I 
 > realize that you may have to run emacs for several weeks before you can 
 > be confident.
 > 
 > Ken
 > 

Hi,

it took a while, but today Emacs crashed again, although I have been
running the snapshot from July 9 since you mentioned it might affect
the bug. Apparently, it doesn't. The backtrace is similar to the ones I
used to get with the stock cygwin1.dll. This time Emacs crashed during
startup, I didn't even have a chance to do anything before it
disappeared. Backtrace is attached below.

regards,
Markus

info threads
  Id   Target Id         Frame
  10   Thread 0x3c4      0xfaf3003300001f80 in ?? ()
  9    Thread 0x1254     0x0000003300001f80 in ?? ()
  8    Thread 0x12c0     0x9e84003300001f80 in ?? ()
  7    Thread 0x12f0     0x0005003300001f80 in ?? ()
  6    Thread 0x2e8      0x0005003300001f80 in ?? ()
  5    Thread 0xf38      0x0000003300001f80 in ?? ()
  4    Thread 0x119c     0x0000003300001f80 in ?? ()
  3    Thread 0x580      0x0000003300001f80 in ?? ()
  2    Thread 0x10d8     0x0000003300001f80 in ?? ()
* 1    Thread 0xff8      0x0000003300001fa4 in ?? ()

(gdb) thread apply all bt

Thread 10 (Thread 0x3c4):
#0  0xfaf3003300001f80 in ?? ()
#1  0x0000000000000000 in ?? ()

Thread 9 (Thread 0x1254):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefdaf10dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 8 (Thread 0x12c0):
#0  0x9e84003300001f80 in ?? ()
#1  0x000007fefdaf10dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 7 (Thread 0x12f0):
#0  0x0005003300001f80 in ?? ()
#1  0x000007fefcfc5971 in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 6 (Thread 0x2e8):
#0  0x0005003300001f80 in ?? ()
#1  0x000007fefdaf10dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 5 (Thread 0xf38):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefdaf1203 in ?? ()
#2  0x00000000033daba8 in ?? ()
#3  0x0000000600042280 in ?? ()
#4  0x0000000000000003 in ?? ()
#5  0x00000001802edc50 in ?? ()
#6  0xfffffffffffe7960 in ?? ()
#7  0x00000000033dab10 in ?? ()
#8  0x0000000000000048 in ?? ()
#9  0x0000000000000001 in ?? ()
#10 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x119c):
#0  0x0000003300001f80 in ?? ()
Cannot access memory at address 0xffffc458
(gdb) thread apply 3 bt

Thread 3 (Thread 0x580):
#0  0x0000003300001f80 in ?? ()
#1  0x000000007785b037 in ?? ()
#2  0x0000000000000000 in ?? ()
(gdb) thread apply 2 bt

Thread 2 (Thread 0x10d8):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefdaf1a7a in ?? ()
#2  0x000000000042ce00 in ?? ()
#3  0x0000000100629773 in run_timers ()
    at /usr/src/debug/emacs-24.3.90-1/src/atimer.c:364
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread apply 1 bt

Thread 1 (Thread 0xff8):
#0  0x0000003300001fa4 in ?? ()
#1  0x0000000000430000 in ?? ()
#2  0x0000000100970c78 in ?? ()
#3  0x000000000000e118 in ?? ()
#4  0x00000000005c6e30 in ?? ()
#5  0x0000000600cd502d in ?? ()
#6  0x0000000000000015 in ?? ()
#7  0x0000000600fdcbf4 in ?? ()
#8  0x0000000600cd502d in ?? ()
#9  0x0000000000426330 in ?? ()
#10 0x0000000600000005 in ?? ()
#11 0x0000000100970c78 in ?? ()
#12 0x0000000000000000 in ?? ()


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[markus.hoenicka]

Ken Brown writes:
 > A bug in the Cygwin DLL (64-bit only) was just discovered and fixed. 
 > The bug could have prevented stack space from being committed after the 
 > initial commit.  Could you try the latest snapshot from 
 > https://cygwin.com/snapshots/ and see if these strange crashes stop?  I 
 > realize that you may have to run emacs for several weeks before you can 
 > be confident.
 > 

Hi,

I don't know if the latest official Cygwin DLL contains any additional
bugfixes that are relevant for the Emacs crashes, but I've upgraded my
system anyway, using the latest Cygwin DLL and Emacs as of Aug
4th. Emacs crashed on the very same day, but not once during the next
two days. The core dumps look as useless as ever, although slightly
different compared to before the upgrade:

(gdb) thread apply all bt

Thread 6 (Thread 0x14dc):
#0  0x0004003300001f80 in ?? ()
#1  0x0000000000000000 in ?? ()

Thread 5 (Thread 0x57c):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefda010dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 4 (Thread 0x1300):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefda010dc in ?? ()
#2  0x0000000000000000 in ?? ()

Thread 3 (Thread 0x1080):
#0  0x0000003300001f80 in ?? ()
#1  0x00000000777eb037 in ?? ()
#2  0x0000000000000002 in ?? ()
#3  0x0000000000000000 in ?? ()

Thread 2 (Thread 0xf38):
#0  0x0000003300001f80 in ?? ()
#1  0x000007fefda01a7a in ?? ()
#2  0x000000000042ce00 in ?? ()
#3  0x0000000100582620 in schedule_atimer ()
    at /usr/src/debug/emacs-24.3-7/src/atimer.c:343
#4  0x00000001802de9f8 in ?? ()
#5  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x11b4):
#0  0x0000003300001fa4 in ?? ()
#1  0x0000000100010000 in ?? ()
#2  0x0000000000000000 in ?? ()

$ uname -a
CYGWIN_NT-6.1 SBHC123 1.7.31(0.272/5/3) 2014-07-25 11:26 x86_64 Cygwin
$ cygcheck -f /usr/bin/emacs-X11.exe
emacs-X11-24.3-7

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

bug#17753: Cygwin emacs-X11 core dump

[Achim Gratz]

Ken Brown writes:
> I don't know if it's
> possible at this point to get gdb to read the debug information for
> cygdbus-1-3.dll and cygatspi-0.dll (once you install the debuginfo
> packages) or if you have to wait for the next crash.

The commands symbol-file or add-symbol-file should do what you want.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#17753: Cygwin emacs-X11 core dump

[Ken Brown]

On 10/7/2014 12:47 PM, Achim Gratz wrote:
> Ken Brown writes:
>> I don't know if it's
>> possible at this point to get gdb to read the debug information for
>> cygdbus-1-3.dll and cygatspi-0.dll (once you install the debuginfo
>> packages) or if you have to wait for the next crash.
>
> The commands symbol-file or add-symbol-file should do what you want.

symbol-file does the job.  For example:

(gdb) symbol-file /usr/bin/cygdbus-1-3.dll
Reading symbols from /usr/bin/cygdbus-1-3.dll...Reading symbols from 
/usr/lib/debug//usr/bin/cygdbus-1-3.dll.dbg...done.

Thanks.

Ken