* bug#17753: Cygwin emacs-X11 core dump
@ 2014-06-09 21:55 markus.hoenicka
2014-06-11 2:51 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: markus.hoenicka @ 2014-06-09 21:55 UTC (permalink / raw)
To: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-06-09 21:55 bug#17753: Cygwin emacs-X11 core dump markus.hoenicka
@ 2014-06-11 2:51 ` Eli Zaretskii
2014-06-11 6:16 ` Markus Hoenicka
2014-06-11 12:28 ` Ken Brown
2014-07-04 21:21 ` markus.hoenicka
2014-10-07 16:47 ` Achim Gratz
2 siblings, 2 replies; 56+ messages in thread
From: Eli Zaretskii @ 2014-06-11 2:51 UTC (permalink / raw)
To: markus.hoenicka; +Cc: 17753
> 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.)
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-06-11 2:51 ` Eli Zaretskii
@ 2014-06-11 6:16 ` Markus Hoenicka
2014-06-11 14:47 ` Eli Zaretskii
2014-06-11 12:28 ` Ken Brown
1 sibling, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-06-11 6:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-06-11 2:51 ` Eli Zaretskii
2014-06-11 6:16 ` Markus Hoenicka
@ 2014-06-11 12:28 ` Ken Brown
2014-06-11 15:03 ` Eli Zaretskii
1 sibling, 1 reply; 56+ messages in thread
From: Ken Brown @ 2014-06-11 12:28 UTC (permalink / raw)
To: Eli Zaretskii, markus.hoenicka; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-06-11 6:16 ` Markus Hoenicka
@ 2014-06-11 14:47 ` Eli Zaretskii
2014-06-13 22:53 ` markus.hoenicka
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2014-06-11 14:47 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-06-11 12:28 ` Ken Brown
@ 2014-06-11 15:03 ` Eli Zaretskii
0 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2014-06-11 15:03 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753, markus.hoenicka
> 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-06-11 14:47 ` Eli Zaretskii
@ 2014-06-13 22:53 ` markus.hoenicka
0 siblings, 0 replies; 56+ messages in thread
From: markus.hoenicka @ 2014-06-13 22:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-06-09 21:55 bug#17753: Cygwin emacs-X11 core dump markus.hoenicka
2014-06-11 2:51 ` Eli Zaretskii
@ 2014-07-04 21:21 ` markus.hoenicka
2014-07-05 14:03 ` Ken Brown
2014-10-07 16:47 ` Achim Gratz
2 siblings, 1 reply; 56+ messages in thread
From: markus.hoenicka @ 2014-07-04 21:21 UTC (permalink / raw)
To: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-07-04 21:21 ` markus.hoenicka
@ 2014-07-05 14:03 ` Ken Brown
2014-07-07 21:31 ` markus.hoenicka
0 siblings, 1 reply; 56+ messages in thread
From: Ken Brown @ 2014-07-05 14:03 UTC (permalink / raw)
To: markus.hoenicka, 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-07-05 14:03 ` Ken Brown
@ 2014-07-07 21:31 ` markus.hoenicka
2014-07-09 13:57 ` Ken Brown
0 siblings, 1 reply; 56+ messages in thread
From: markus.hoenicka @ 2014-07-07 21:31 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-07-07 21:31 ` markus.hoenicka
@ 2014-07-09 13:57 ` Ken Brown
2014-07-09 14:30 ` Markus Hoenicka
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Ken Brown @ 2014-07-09 13:57 UTC (permalink / raw)
To: markus.hoenicka; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-07-09 13:57 ` Ken Brown
@ 2014-07-09 14:30 ` Markus Hoenicka
2014-09-17 9:45 ` Markus Hoenicka
2014-07-28 22:45 ` markus.hoenicka
2014-08-06 22:02 ` markus.hoenicka
2 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-07-09 14:30 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-07-09 13:57 ` Ken Brown
2014-07-09 14:30 ` Markus Hoenicka
@ 2014-07-28 22:45 ` markus.hoenicka
2014-08-06 22:02 ` markus.hoenicka
2 siblings, 0 replies; 56+ messages in thread
From: markus.hoenicka @ 2014-07-28 22:45 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-07-09 13:57 ` Ken Brown
2014-07-09 14:30 ` Markus Hoenicka
2014-07-28 22:45 ` markus.hoenicka
@ 2014-08-06 22:02 ` markus.hoenicka
2 siblings, 0 replies; 56+ messages in thread
From: markus.hoenicka @ 2014-08-06 22:02 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-07-09 14:30 ` Markus Hoenicka
@ 2014-09-17 9:45 ` Markus Hoenicka
2014-09-17 10:16 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-09-17 9:45 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
[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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-17 9:45 ` Markus Hoenicka
@ 2014-09-17 10:16 ` Eli Zaretskii
2014-09-17 10:52 ` Eli Zaretskii
2014-09-17 15:17 ` Ken Brown
0 siblings, 2 replies; 56+ messages in thread
From: Eli Zaretskii @ 2014-09-17 10:16 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-17 10:16 ` Eli Zaretskii
@ 2014-09-17 10:52 ` Eli Zaretskii
2014-09-17 11:04 ` Markus Hoenicka
2014-09-17 15:17 ` Ken Brown
1 sibling, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2014-09-17 10:52 UTC (permalink / raw)
To: markus.hoenicka, Ken Brown; +Cc: 17753
> 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-17 10:52 ` Eli Zaretskii
@ 2014-09-17 11:04 ` Markus Hoenicka
0 siblings, 0 replies; 56+ messages in thread
From: Markus Hoenicka @ 2014-09-17 11:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-17 10:16 ` Eli Zaretskii
2014-09-17 10:52 ` Eli Zaretskii
@ 2014-09-17 15:17 ` Ken Brown
2014-09-17 17:06 ` Eli Zaretskii
1 sibling, 1 reply; 56+ messages in thread
From: Ken Brown @ 2014-09-17 15:17 UTC (permalink / raw)
To: Eli Zaretskii, Markus Hoenicka; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-17 15:17 ` Ken Brown
@ 2014-09-17 17:06 ` Eli Zaretskii
2014-09-22 7:14 ` Markus Hoenicka
2014-10-07 7:02 ` Markus Hoenicka
0 siblings, 2 replies; 56+ messages in thread
From: Eli Zaretskii @ 2014-09-17 17:06 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753, markus.hoenicka
> 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-17 17:06 ` Eli Zaretskii
@ 2014-09-22 7:14 ` Markus Hoenicka
2014-09-22 13:32 ` Ken Brown
2014-10-07 7:02 ` Markus Hoenicka
1 sibling, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-09-22 7:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-22 7:14 ` Markus Hoenicka
@ 2014-09-22 13:32 ` Ken Brown
2014-09-22 14:04 ` Markus Hoenicka
0 siblings, 1 reply; 56+ messages in thread
From: Ken Brown @ 2014-09-22 13:32 UTC (permalink / raw)
To: Markus Hoenicka, Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-22 13:32 ` Ken Brown
@ 2014-09-22 14:04 ` Markus Hoenicka
2014-09-22 14:48 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-09-22 14:04 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-22 14:04 ` Markus Hoenicka
@ 2014-09-22 14:48 ` Eli Zaretskii
0 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2014-09-22 14:48 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-09-17 17:06 ` Eli Zaretskii
2014-09-22 7:14 ` Markus Hoenicka
@ 2014-10-07 7:02 ` Markus Hoenicka
2014-10-07 14:56 ` Ken Brown
1 sibling, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-07 7:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-07 7:02 ` Markus Hoenicka
@ 2014-10-07 14:56 ` Ken Brown
2014-10-07 15:05 ` Eli Zaretskii
2014-10-07 16:05 ` Markus Hoenicka
0 siblings, 2 replies; 56+ messages in thread
From: Ken Brown @ 2014-10-07 14:56 UTC (permalink / raw)
To: Markus Hoenicka, Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-07 14:56 ` Ken Brown
@ 2014-10-07 15:05 ` Eli Zaretskii
2014-10-07 16:05 ` Markus Hoenicka
2014-10-07 16:05 ` Markus Hoenicka
1 sibling, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2014-10-07 15:05 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753, markus.hoenicka
> 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.)
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-07 14:56 ` Ken Brown
2014-10-07 15:05 ` Eli Zaretskii
@ 2014-10-07 16:05 ` Markus Hoenicka
1 sibling, 0 replies; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-07 16:05 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-07 15:05 ` Eli Zaretskii
@ 2014-10-07 16:05 ` Markus Hoenicka
2014-10-07 17:04 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-07 16:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-06-09 21:55 bug#17753: Cygwin emacs-X11 core dump markus.hoenicka
2014-06-11 2:51 ` Eli Zaretskii
2014-07-04 21:21 ` markus.hoenicka
@ 2014-10-07 16:47 ` Achim Gratz
2014-10-07 18:43 ` Ken Brown
2 siblings, 1 reply; 56+ messages in thread
From: Achim Gratz @ 2014-10-07 16:47 UTC (permalink / raw)
To: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-07 16:05 ` Markus Hoenicka
@ 2014-10-07 17:04 ` Eli Zaretskii
2014-10-07 20:48 ` Markus Hoenicka
2014-10-09 8:17 ` Markus Hoenicka
0 siblings, 2 replies; 56+ messages in thread
From: Eli Zaretskii @ 2014-10-07 17:04 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-07 16:47 ` Achim Gratz
@ 2014-10-07 18:43 ` Ken Brown
0 siblings, 0 replies; 56+ messages in thread
From: Ken Brown @ 2014-10-07 18:43 UTC (permalink / raw)
To: Achim Gratz, 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-07 17:04 ` Eli Zaretskii
@ 2014-10-07 20:48 ` Markus Hoenicka
2014-10-09 8:17 ` Markus Hoenicka
1 sibling, 0 replies; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-07 20:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-07 17:04 ` Eli Zaretskii
2014-10-07 20:48 ` Markus Hoenicka
@ 2014-10-09 8:17 ` Markus Hoenicka
2014-10-09 8:56 ` Eli Zaretskii
1 sibling, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-09 8:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-09 8:17 ` Markus Hoenicka
@ 2014-10-09 8:56 ` Eli Zaretskii
2014-10-09 9:08 ` Markus Hoenicka
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2014-10-09 8:56 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-09 8:56 ` Eli Zaretskii
@ 2014-10-09 9:08 ` Markus Hoenicka
2014-10-09 10:35 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-09 9:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-09 9:08 ` Markus Hoenicka
@ 2014-10-09 10:35 ` Eli Zaretskii
2014-10-09 10:44 ` Markus Hoenicka
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2014-10-09 10:35 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-09 10:35 ` Eli Zaretskii
@ 2014-10-09 10:44 ` Markus Hoenicka
2014-10-09 11:22 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-09 10:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-09 10:44 ` Markus Hoenicka
@ 2014-10-09 11:22 ` Eli Zaretskii
2014-10-09 11:47 ` Markus Hoenicka
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2014-10-09 11:22 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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.)
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-09 11:22 ` Eli Zaretskii
@ 2014-10-09 11:47 ` Markus Hoenicka
2014-10-09 11:55 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-09 11:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-09 11:47 ` Markus Hoenicka
@ 2014-10-09 11:55 ` Eli Zaretskii
2014-10-11 15:31 ` Ken Brown
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2014-10-09 11:55 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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?
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-09 11:55 ` Eli Zaretskii
@ 2014-10-11 15:31 ` Ken Brown
2014-10-12 0:07 ` Markus Hoenicka
2014-10-20 10:59 ` Markus Hoenicka
0 siblings, 2 replies; 56+ messages in thread
From: Ken Brown @ 2014-10-11 15:31 UTC (permalink / raw)
To: Eli Zaretskii, Markus Hoenicka; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-11 15:31 ` Ken Brown
@ 2014-10-12 0:07 ` Markus Hoenicka
2014-10-20 10:59 ` Markus Hoenicka
1 sibling, 0 replies; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-12 0:07 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-11 15:31 ` Ken Brown
2014-10-12 0:07 ` Markus Hoenicka
@ 2014-10-20 10:59 ` Markus Hoenicka
2014-10-20 11:29 ` Ken Brown
1 sibling, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-20 10:59 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 10:59 ` Markus Hoenicka
@ 2014-10-20 11:29 ` Ken Brown
2014-10-20 12:04 ` martin rudalics
` (3 more replies)
0 siblings, 4 replies; 56+ messages in thread
From: Ken Brown @ 2014-10-20 11:29 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 11:29 ` Ken Brown
@ 2014-10-20 12:04 ` martin rudalics
2014-10-20 13:05 ` Ken Brown
2014-10-20 14:11 ` Markus Hoenicka
` (2 subsequent siblings)
3 siblings, 1 reply; 56+ messages in thread
From: martin rudalics @ 2014-10-20 12:04 UTC (permalink / raw)
To: Ken Brown, Markus Hoenicka; +Cc: 17753
> 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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 12:04 ` martin rudalics
@ 2014-10-20 13:05 ` Ken Brown
0 siblings, 0 replies; 56+ messages in thread
From: Ken Brown @ 2014-10-20 13:05 UTC (permalink / raw)
To: martin rudalics, Markus Hoenicka; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 11:29 ` Ken Brown
2014-10-20 12:04 ` martin rudalics
@ 2014-10-20 14:11 ` Markus Hoenicka
2014-10-20 14:37 ` Markus Hoenicka
2014-10-20 15:29 ` Eli Zaretskii
3 siblings, 0 replies; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-20 14:11 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 11:29 ` Ken Brown
2014-10-20 12:04 ` martin rudalics
2014-10-20 14:11 ` Markus Hoenicka
@ 2014-10-20 14:37 ` Markus Hoenicka
2014-10-20 15:24 ` Eli Zaretskii
2014-10-20 15:29 ` Eli Zaretskii
3 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-20 14:37 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 14:37 ` Markus Hoenicka
@ 2014-10-20 15:24 ` Eli Zaretskii
2014-10-20 15:29 ` Markus Hoenicka
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2014-10-20 15:24 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753
> 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 11:29 ` Ken Brown
` (2 preceding siblings ...)
2014-10-20 14:37 ` Markus Hoenicka
@ 2014-10-20 15:29 ` Eli Zaretskii
3 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2014-10-20 15:29 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753, markus.hoenicka
> 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.
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 15:24 ` Eli Zaretskii
@ 2014-10-20 15:29 ` Markus Hoenicka
2014-10-24 21:27 ` Ken Brown
0 siblings, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-20 15:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-20 15:29 ` Markus Hoenicka
@ 2014-10-24 21:27 ` Ken Brown
2014-10-24 21:42 ` Markus Hoenicka
2014-12-03 12:43 ` Markus Hoenicka
0 siblings, 2 replies; 56+ messages in thread
From: Ken Brown @ 2014-10-24 21:27 UTC (permalink / raw)
To: Markus Hoenicka, Eli Zaretskii; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-24 21:27 ` Ken Brown
@ 2014-10-24 21:42 ` Markus Hoenicka
2014-12-03 12:43 ` Markus Hoenicka
1 sibling, 0 replies; 56+ messages in thread
From: Markus Hoenicka @ 2014-10-24 21:42 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-10-24 21:27 ` Ken Brown
2014-10-24 21:42 ` Markus Hoenicka
@ 2014-12-03 12:43 ` Markus Hoenicka
2014-12-03 14:12 ` Ken Brown
1 sibling, 1 reply; 56+ messages in thread
From: Markus Hoenicka @ 2014-12-03 12:43 UTC (permalink / raw)
To: Ken Brown; +Cc: 17753
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
^ permalink raw reply [flat|nested] 56+ messages in thread
* bug#17753: Cygwin emacs-X11 core dump
2014-12-03 12:43 ` Markus Hoenicka
@ 2014-12-03 14:12 ` Ken Brown
0 siblings, 0 replies; 56+ messages in thread
From: Ken Brown @ 2014-12-03 14:12 UTC (permalink / raw)
To: Markus Hoenicka; +Cc: 17753-done
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
^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2014-12-03 14:12 UTC | newest]
Thread overview: 56+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-09 21:55 bug#17753: Cygwin emacs-X11 core dump markus.hoenicka
2014-06-11 2:51 ` Eli Zaretskii
2014-06-11 6:16 ` Markus Hoenicka
2014-06-11 14:47 ` Eli Zaretskii
2014-06-13 22:53 ` markus.hoenicka
2014-06-11 12:28 ` Ken Brown
2014-06-11 15:03 ` Eli Zaretskii
2014-07-04 21:21 ` markus.hoenicka
2014-07-05 14:03 ` Ken Brown
2014-07-07 21:31 ` markus.hoenicka
2014-07-09 13:57 ` Ken Brown
2014-07-09 14:30 ` Markus Hoenicka
2014-09-17 9:45 ` Markus Hoenicka
2014-09-17 10:16 ` Eli Zaretskii
2014-09-17 10:52 ` Eli Zaretskii
2014-09-17 11:04 ` Markus Hoenicka
2014-09-17 15:17 ` Ken Brown
2014-09-17 17:06 ` Eli Zaretskii
2014-09-22 7:14 ` Markus Hoenicka
2014-09-22 13:32 ` Ken Brown
2014-09-22 14:04 ` Markus Hoenicka
2014-09-22 14:48 ` Eli Zaretskii
2014-10-07 7:02 ` Markus Hoenicka
2014-10-07 14:56 ` Ken Brown
2014-10-07 15:05 ` Eli Zaretskii
2014-10-07 16:05 ` Markus Hoenicka
2014-10-07 17:04 ` Eli Zaretskii
2014-10-07 20:48 ` Markus Hoenicka
2014-10-09 8:17 ` Markus Hoenicka
2014-10-09 8:56 ` Eli Zaretskii
2014-10-09 9:08 ` Markus Hoenicka
2014-10-09 10:35 ` Eli Zaretskii
2014-10-09 10:44 ` Markus Hoenicka
2014-10-09 11:22 ` Eli Zaretskii
2014-10-09 11:47 ` Markus Hoenicka
2014-10-09 11:55 ` Eli Zaretskii
2014-10-11 15:31 ` Ken Brown
2014-10-12 0:07 ` Markus Hoenicka
2014-10-20 10:59 ` Markus Hoenicka
2014-10-20 11:29 ` Ken Brown
2014-10-20 12:04 ` martin rudalics
2014-10-20 13:05 ` Ken Brown
2014-10-20 14:11 ` Markus Hoenicka
2014-10-20 14:37 ` Markus Hoenicka
2014-10-20 15:24 ` Eli Zaretskii
2014-10-20 15:29 ` Markus Hoenicka
2014-10-24 21:27 ` Ken Brown
2014-10-24 21:42 ` Markus Hoenicka
2014-12-03 12:43 ` Markus Hoenicka
2014-12-03 14:12 ` Ken Brown
2014-10-20 15:29 ` Eli Zaretskii
2014-10-07 16:05 ` Markus Hoenicka
2014-07-28 22:45 ` markus.hoenicka
2014-08-06 22:02 ` markus.hoenicka
2014-10-07 16:47 ` Achim Gratz
2014-10-07 18:43 ` Ken Brown
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).