bug#12579: 24.1; Emacs 24.1 / 24.2 (daily) crashes

[Fabrice Niessen]

I've many crashes of Emacs (daily, a couple of crashes). Though, no recipe...

There does not seem to be more or less crashes in Emacs 24.1 or Emacs 24.2 (on
Windows XP). I got the executables from there:

- Emacs 24.1 (http://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-24.1-rc-bin-i386.zip) or
- Emacs 24.2 (http://alpha.gnu.org/gnu/emacs/windows/emacs-20120917-r110062-bin-i386.zip).

Both have crashes, /often/ when filling in my regexp pattern for `helm-files',
but /not necessarily/ (sometimes in Gnus, sometimes at other moments).

_Often_ Emacs is just blocked, and C-g can't help me. I simply have to kill
Emacs from the Task Manager.

_Sometimes_, though, I have an Emacs abort dialog, something like:

I had such a crash this morning, then applied the above recipe. I've no
experience in running a debugger, but here's what I could come up with:

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
Attaching to process 3692
[New Thread 3692.0x5d0]
[New Thread 3692.0x195c]
[New Thread 3692.0x1a20]
[New Thread 3692.0x1884]
Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.
(gdb) thread apply all backtrace

Thread 4 (Thread 3692.0x1884):
#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()
#5 0x7155ffd0 in ?? ()
#6 0x00000000 in ?? ()

Thread 3 (Thread 3692.0x1a20):
#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x77dc8631 in WmiFreeBuffer () from /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL
#4 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#5 0x00000000 in ?? ()

Thread 2 (Thread 3692.0x195c):
#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x011490bd in w32_msg_pump (msg_buf=0x7236ff54) at w32fns.c:2263
#4 0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Thread 1 (Thread 3692.0x5d0):
#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7e399418 in WaitMessage () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3a770a in USER32!CallMsgFilterW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x7e3a49c4 in USER32!GetCursorFrameInfo () from /cygdrive/c/WINDOWS/system32/USER32.dll
#4 0x7e3ba956 in USER32!SoftModalMessageBox () from /cygdrive/c/WINDOWS/system32/USER32.dll
#5 0x7e3ba2bc in USER32!MessageBoxIndirectA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#6 0x7e3e63fd in USER32!MessageBoxTimeoutW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#7 0x7e3e64a2 in USER32!MessageBoxTimeoutA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#8 0x7e3d0877 in USER32!MessageBoxExA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#9 0x7e3d082f in USER32!MessageBoxA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#10 0x011548ad in emacs_abort () at w32fns.c:7200
#11 0x01055503 in sys_kill (pid=3692, sig=22) at w32proc.c:1432
#12 0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647) at emacs.c:331
#13 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
line=1664) at alloc.c:6398
#14 0x010ac068 in compact_buffer (buffer=0x5303800) at buffer.c:1664
#15 0x0103fde2 in Fgarbage_collect () at alloc.c:5085
#16 0x0103997b in maybe_gc () at lisp.h:3637
#17 0x010e0f83 in exec_byte_code (bytestr=71402977, vector=77573749, maxdepth=48, args_template=56346650, nargs=0, args=0x0)
---Type <return> to continue, or q <return> to quit---
at bytecode.c:934
#18 0x010e023e in Fbyte_code (bytestr=71402977, vector=77573749, maxdepth=48) at bytecode.c:474
#19 0x01034a57 in eval_sub (form=77782438) at eval.c:2163
#20 0x010325bd in internal_lisp_condition_case (var=56346650, bodyform=77782438, handlers=77781446) at eval.c:1262
#21 0x010e1ab4 in exec_byte_code (bytestr=71403281, vector=80289685, maxdepth=12, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:1095
#22 0x01037624 in funcall_lambda (fun=77553509, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#23 0x01036abd in Ffuncall (nargs=2, args=0x82db14) at eval.c:2845
#24 0x010e0e77 in exec_byte_code (bytestr=71430993, vector=77549453, maxdepth=8, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#25 0x01037624 in funcall_lambda (fun=77553349, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#26 0x01036abd in Ffuncall (nargs=2, args=0x82de04) at eval.c:2845
#27 0x010e0e77 in exec_byte_code (bytestr=71434081, vector=77553269, maxdepth=32, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#28 0x01037624 in funcall_lambda (fun=77549429, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#29 0x01036abd in Ffuncall (nargs=3, args=0x82e114) at eval.c:2845
#30 0x010e0e77 in exec_byte_code (bytestr=71691921, vector=72289989, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#31 0x01037624 in funcall_lambda (fun=70639325, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#32 0x01036abd in Ffuncall (nargs=2, args=0x82e414) at eval.c:2845
#33 0x010e0e77 in exec_byte_code (bytestr=71695393, vector=65080981, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#34 0x01037624 in funcall_lambda (fun=65081117, nargs=4, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#35 0x01036abd in Ffuncall (nargs=5, args=0x82e714) at eval.c:2845
#36 0x010e0e77 in exec_byte_code (bytestr=67701873, vector=67690925, maxdepth=20, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#37 0x01037624 in funcall_lambda (fun=67690981, nargs=3, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#38 0x01036abd in Ffuncall (nargs=4, args=0x82ea14) at eval.c:2845
#39 0x010e0e77 in exec_byte_code (bytestr=68896881, vector=72048245, maxdepth=24, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#40 0x01037624 in funcall_lambda (fun=76148429, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#41 0x01036abd in Ffuncall (nargs=3, args=0x82ed14) at eval.c:2845
#42 0x010e0e77 in exec_byte_code (bytestr=66747057, vector=75615861, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#43 0x01037624 in funcall_lambda (fun=75616149, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#44 0x01036abd in Ffuncall (nargs=3, args=0x82f014) at eval.c:2845
#45 0x010e0e77 in exec_byte_code (bytestr=64454993, vector=68455093, maxdepth=20, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#46 0x01037624 in funcall_lambda (fun=68455221, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#47 0x01036abd in Ffuncall (nargs=2, args=0x82f314) at eval.c:2845
#48 0x010e0e77 in exec_byte_code (bytestr=59153777, vector=68455549, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#49 0x01037624 in funcall_lambda (fun=68455805, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#50 0x01036abd in Ffuncall (nargs=3, args=0x82f614) at eval.c:2845
#51 0x010e0e77 in exec_byte_code (bytestr=64388225, vector=68456037, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#52 0x01037624 in funcall_lambda (fun=68456109, nargs=0, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
---Type <return> to continue, or q <return> to quit---
#53 0x01036abd in Ffuncall (nargs=1, args=0x82f940) at eval.c:2845
#54 0x01035dd8 in apply1 (fn=68368842, arg=56346650) at eval.c:2557
#55 0x010e4bed in Fcall_interactively (function=68368842, record_flag=56346650, keys=56368045) at callint.c:377
#56 0x0103677b in Ffuncall (nargs=4, args=0x82fb50) at eval.c:2803
#57 0x01035edb in call3 (fn=56457962, arg1=68368842, arg2=56346650, arg3=56346650) at eval.c:2621
#58 0x010207b2 in Fcommand_execute (cmd=68368842, record_flag=56346650, keys=56346650, special=56346650) at keyboard.c:10319
#59 0x010067de in command_loop_1 () at keyboard.c:1615
#60 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#61 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#62 0x010320bb in internal_catch (tag=56387090, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#63 0x0100567e in command_loop () at keyboard.c:1161
#64 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#65 0x01004f54 in Frecursive_edit () at keyboard.c:846
#66 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655
(gdb)
(gdb)
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 3692.0x5d0]
0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) c
Continuing.
[Inferior 1 (process 3692) exited with code 02]
(gdb)
#38 0x01036abd in Ffuncall (nargs=4, args=0x82ea14) at eval.c:2845
#39 0x010e0e77 in exec_byte_code (bytestr=68896881, vector=72048245, maxdepth=24, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#40 0x01037624 in funcall_lambda (fun=76148429, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#41 0x01036abd in Ffuncall (nargs=3, args=0x82ed14) at eval.c:2845
#42 0x010e0e77 in exec_byte_code (bytestr=66747057, vector=75615861, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#43 0x01037624 in funcall_lambda (fun=75616149, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#44 0x01036abd in Ffuncall (nargs=3, args=0x82f014) at eval.c:2845
#45 0x010e0e77 in exec_byte_code (bytestr=64454993, vector=68455093, maxdepth=20, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#46 0x01037624 in funcall_lambda (fun=68455221, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#47 0x01036abd in Ffuncall (nargs=2, args=0x82f314) at eval.c:2845
#48 0x010e0e77 in exec_byte_code (bytestr=59153777, vector=68455549, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#49 0x01037624 in funcall_lambda (fun=68455805, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#50 0x01036abd in Ffuncall (nargs=3, args=0x82f614) at eval.c:2845
#51 0x010e0e77 in exec_byte_code (bytestr=64388225, vector=68456037, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#52 0x01037624 in funcall_lambda (fun=68456109, nargs=0, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
---Type <return> to continue, or q <return> to quit---
#53 0x01036abd in Ffuncall (nargs=1, args=0x82f940) at eval.c:2845
#54 0x01035dd8 in apply1 (fn=68368842, arg=56346650) at eval.c:2557
#55 0x010e4bed in Fcall_interactively (function=68368842, record_flag=56346650, keys=56368045) at callint.c:377
#56 0x0103677b in Ffuncall (nargs=4, args=0x82fb50) at eval.c:2803
#57 0x01035edb in call3 (fn=56457962, arg1=68368842, arg2=56346650, arg3=56346650) at eval.c:2621
#58 0x010207b2 in Fcommand_execute (cmd=68368842, record_flag=56346650, keys=56346650, special=56346650) at keyboard.c:10319
#59 0x010067de in command_loop_1 () at keyboard.c:1615
#60 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#61 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#62 0x010320bb in internal_catch (tag=56387090, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#63 0x0100567e in command_loop () at keyboard.c:1161
#64 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#65 0x01004f54 in Frecursive_edit () at keyboard.c:846
#66 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655
(gdb)
(gdb)
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 3692.0x5d0]
0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) c
Continuing.
[Inferior 1 (process 3692) exited with code 02]
(gdb)



In GNU Emacs 24.1.1 (i386-mingw-nt5.1.2600)
of 2012-06-02 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.6) --no-opt --enable-checking --cflags
-ID:/devel/emacs/libs/libXpm-3.5.8/include
-ID:/devel/emacs/libs/libXpm-3.5.8/src
-ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
-ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
-ID:/devel/emacs/libs/giflib-4.1.4-1/include
-ID:/devel/emacs/libs/jpeg-6b-4/include
-ID:/devel/emacs/libs/tiff-3.8.2-1/include
-ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.utf8
value of $XMODIFIERS: nil
locale-coding-system: cp1252
default enable-multibyte-characters: t

Major mode: Group

Minor modes in effect:
diff-auto-refine-mode: t
gnus-topic-mode: t
auto-image-file-mode: t
gnus-undo-mode: t
recentf-mode: t
helm-dired-mode: Enable helm completion in Dired functions.
Bindings affected are C, R, S, H.
This is deprecated for Emacs24+ users, use `helm-mode' instead.
shell-dirtrack-mode: t
helm-match-plugin-mode: t
global-auto-complete-mode: t
pretty-control-l-mode: t
show-paren-mode: t
tooltip-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

Recent input:
SPC = SPC 0 % <up> <up> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<right> <right> <right> <right> <right> <right> <right>
<left> <left> SPC d i f f e r e n c e <down> , SPC
w e SPC k n o w SPC t h e r e SPC a r e SPC e <backspace>
s o m e SPC e x c <backspace> a c t l y SPC c o m p
u t e d SPC p r i <backspace> e m u m s <backspace>
<backspace> <backspace> i u m s . SPC A n d SPC a SPC
h u g e SPC m a x SPC w o u l d SPC m e a n SPC t h
e SPC a v e r g a g <backspace> <backspace> <backspace>
a g e SPC i s SPC n o t SPC v e r y SPC r e p r e s
e n t a t i v e . M-q <return> <return> F a b r i c
e C-c C-c . T r a s <tab> <return> q <C-f4> C-c C-x
C-z k <return> <up> <up> <up> <up> <up> <up> <up> <f2>
<f12> M-x e m a b <backspace> c s <backspace> <backspace>
<backspace> <backspace> <backspace> b u g - r e <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
p r o <backspace> <backspace> <backspace> r e p o r
t - b u <backspace> <backspace> <down> <down> <down>
<down> <down> <down> <return>

Recent messages:
(info) +-> Requiring `helm-mode'...
(info) +-> Requiring `cl'... already loaded
(info) +-> Requiring `helm'... already loaded
(info) +-> Requiring `helm-files'... already loaded
(info) +-> Requiring `help-fns'... already loaded [2 times]
(info) +-> Requiring `helm-mode'... d:/home/sva/Downloads/emacs/site-lisp/helm/helm-mode.el (loaded in 0.11 s)

Error during redisplay: (wrong-type-argument integer-or-marker-p nil) [4 times]
(info) +-> Requiring `sendmail'... already loaded
(info) +-> Requiring `message'... already loaded

Load-path shadows:
(shadow emacsbug helm-command helm-mode flow-fill diff-mode mm-archive
newcomment gnus-bcklg gnus-async gnus-ml hl-line mailalias smtpmail qp sort
gnus-alias auto-complete gnus-cite org-table mail-extr nndraft nnmh gnus-agent
gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-topic utf-7 nnimap
utf7 nnfolder parse-time cl-specs gnus-cache time-stamp copyright bbdb-message
sendmail epa-file epa epg netrc gnutls network-stream starttls tls nntp
gnus-leuven gnus-dired bbdb-gnus gnus-art mm-uu mml2015 epg-config mm-view
mml-smime smime dig bbdb-mua bbdb-com bbdb timezone vc-git flyspell ispell
org-id org-gnus org-info org-crypt org-mime org-inlinetask anything-orgcard
ob-sql ob-sh ob-python ob-org ob-ledger ob-latex ob-gnuplot ob-dot ob-ditaa
ob-calc calc-store calc-trail calc-ext calc calc-loaddefs calc-macs ob-awk
ob-R org-special-blocks org-html org-e-latex org-e-html table org-e-ascii
org-export org-element org-protocol org-habit org-clock org-exp ob-exp
org-agenda holidays hol-loaddefs vc-dispatcher vc-svn image-file appt
diary-lib diary-loaddefs org-occur-goto mule-util org ob-tangle ob-ref ob-lob
ob-table org-footnote org-src ob-keys org-pcomplete org-list org-faces
org-entities noutline outline org-version ob-emacs-lisp ob-comint ob
org-compat org-macs ob-eval org-loaddefs cal-menu calendar cal-loaddefs
gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec
gnus-int gnus-range message dircolors rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus-win gnus gnus-ems gnus-compat nnheader mail-utils filecache
recentf tree-widget wid-edit ido helm-files image-dired warnings tramp
tramp-compat shell pcomplete format-spec tramp-loaddefs ffap thingatpt
helm-tags helm-bookmark helm-adaptative helm-info helm-net browse-url xml url
url-proxy url-privacy url-expand url-methods url-history url-cookie url-util
url-parse auth-source eieio byte-opt bytecomp byte-compile cconv macroexp
gnus-util password-cache url-vars mm-util mail-prsvr mailcap helm-plugin
bookmark pp helm-locate helm-grep helm-buffers helm-elscreen helm-regexp grep
helm-external helm-utils dired-sort-map dired-single help-mode view dired+
dired-x ediff-merg ediff-diff ediff-wind ediff-mult ediff-help ediff-init
ediff-util dired-aux dired compile comint regexp-opt ansi-color ring helm-help
helm-match-plugin helm-config helm popup show-point-mode eldoc edebug redshank
derived skeleton paredit whitespace hideshow easymenu pp-c-l emacs-leuven
saveplace leuven-theme server gnus-load org-install find-func eval-expr
mic-paren paren uniquify diff-mode- edmacro kmacro idle-require easy-mmode
advice help-fns advice-preload cl time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar
dnd fontset image fringe lisp-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
loaddefs button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable backquote
make-network-process multi-tty emacs)

Best regards,
Fabrice Niessen

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Date: Fri, 05 Oct 2012 10:14:56 +0200

>
> I've many crashes of Emacs (daily, a couple of crashes). Though, no recipe...

Thank you for your report.

> _Often_ Emacs is just blocked, and C-g can't help me. I simply have to kill
> Emacs from the Task Manager.

Next time when this happens, instead of killing Emacs, attach GDB to
it and show us the backtrace you get in all threads.

> _Sometimes_, though, I have an Emacs abort dialog, something like:
>
> I had such a crash this morning, then applied the above recipe. I've no
> experience in running a debugger, but here's what I could come up with:

Here's the culprit:

> #13 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",

Next time, could you also type "xbacktrace" and show the results? If
you don't have the .gdbinit file to go with the binary you use, you
should be able to find it in the src directory of the corresponding
source tarball; then type "source .gdbinit" from the GDB prompt, when
you enter GDB, or just put .gdbinit in the directory where you start
GDB. The xbacktrace command is defined on .gdbinit.

TIA

[Fabrice Niessen]

Hi Eli,

First, thanks a lot for following up this closely, as you do!

I'm eager to have a very stable Emacs under Windows, being an Emacs user since
1999. And being forced to use Windows right now.

Eli Zaretskii wrote:
>> _Often_ Emacs is just blocked, and C-g can't help me. I simply have to kill
>> Emacs from the Task Manager.
>
> Next time when this happens, instead of killing Emacs, attach GDB to
> it and show us the backtrace you get in all threads.

It happened now, once again.

I attached GDB to it. Or do I have to say that I attached the process to GDB?

--8<---------------cut here---------------start------------->8---

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 7368
[New Thread 7368.0x18ec]
[New Thread 7368.0x1878]
[New Thread 7368.0xdb8]
[New Thread 7368.0x1248]
[New Thread 7368.0xfd0]
[New Thread 7368.0x3d0]
[New Thread 7368.0x1a04]
[New Thread 7368.0x155c]
Reading symbols from /cygdrive/c/Program Files/emacs-24.1/bin/emacs.exe...done.
(gdb) continue
Continuing.
thread apply all backtrace


[Inferior 1 (process 7368) exited with code 01]
(gdb) Quit(gdb)
--8<---------------cut here---------------end--------------->8---

As you can see (?), it got no information after I typed "thread apply all
backtrace". GDB was simply not responding... I waited one minute or more.

Then, I tried launching /another/ GDB instance from C:/Program
Files/Emacs-24.2, as, there, I have a .gdbinit file.

--8<---------------cut here---------------start------------->8---

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.
(gdb) Can't attach to process.
warning: File "/cygdrive/c/Program Files/Emacs-24.2/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
^C(gdb) Quit
quit
--8<---------------cut here---------------end--------------->8---

But you see I wasn't more successful... Maybe you understand what goes wrong?

I guess that I couldn't attach twice GDB processes to Emacs. But what about
the warning "auto-loading has been declined by your `auto-load safe-path' set
to `$debugdir:$datadir/auto-load'"?

> Here's the culprit:
>
>> #13 0x010431b7 in die (msg=0x1537030 "assertion failed:
>> buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",

Do you have enough hints with that already?

> Next time, could you also type "xbacktrace" and show the results? If
> you don't have the .gdbinit file to go with the binary you use, you
> should be able to find it in the src directory of the corresponding
> source tarball; then type "source .gdbinit" from the GDB prompt, when
> you enter GDB, or just put .gdbinit in the directory where you start
> GDB. The xbacktrace command is defined on .gdbinit.

What's good is that I already found a .gdbinit file in the Emacs 24.2
"zipball" I had downloaded from http://alpha.gnu.org/gnu/emacs/windows/.

Best regards,
Fabrice

--
Fabrice Niessen
Pre-sales, Network and Software Engineer
M i s s i o n C r i t i c a l I T
✉ f...@missioncriticalit.com
☎ +32 2-757.10.15

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: 12...@debbugs.gnu.org
> Date: Sat, 06 Oct 2012 11:31:43 +0200

Do NOT type "continue" at this point, if you attached GDB to Emacs
that appears to be hung. Just "thread apply all backtrace" will do.

You do need to type "continue" when you attach GDB to Emacs that's
crashed, and see an abort dialog. In this case, wait for the GDB
prompt after you type "continue", and _then_ type "thread apply all

backtrace".

> As you can see (?), it got no information after I typed "thread apply all
> backtrace".

Because Emacs is again running, since you gave the "continue" command,
and GDB cannot get control.

In the case where you see the abort dialog, typing "continue" stops
Emacs again when it gets a fatal signal. But if Emacs hangs, there's
no fatal signal, so typing "continue" just lets Emacs continue its
infinite loop.

> (gdb) Can't attach to process.
> warning: File "/cygdrive/c/Program Files/Emacs-24.2/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> ^C(gdb) Quit
> quit
> --8<---------------cut here---------------end--------------->8---
>
> But you see I wasn't more successful... Maybe you understand what goes wrong?

It can't attach, because another instance of GDB already is attached.

> I guess that I couldn't attach twice GDB processes to Emacs. But what about
> the warning "auto-loading has been declined by your `auto-load safe-path' set
> to `$debugdir:$datadir/auto-load'"?

This is a nuisance with latest GDB versions. I have this in my
~/.gdbinit to countermand that:

set auto-load safe-path /

> > Here's the culprit:
> >
> >> #13 0x010431b7 in die (msg=0x1537030 "assertion failed:
> >> buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
>
> Do you have enough hints with that already?

No. But someone else might.

[Fabrice Niessen]

Dear Eli,

Here is more info, from another crash:

--8<---------------cut here---------------start------------->8---
GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 5928
[New Thread 5928.0x1904]
[New Thread 5928.0x1c7c]
[New Thread 5928.0x1644]
[New Thread 5928.0x28c]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

warning: File "/cygdrive/c/Program Files/Emacs-24.2/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

(gdb) thread apply all backtrace

Thread 4 (Thread 5928.0x28c):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x7132ffd0 in ?? ()

#6 0x00000000 in ?? ()

Thread 3 (Thread 5928.0x1644):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x00000658 in ?? ()
#4 0x00000000 in ?? ()

Thread 2 (Thread 5928.0x1c7c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x011490bd in w32_msg_pump (msg_buf=0x7236ff54) at w32fns.c:2263
#4 0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Thread 1 (Thread 5928.0x1904):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c8648a2 in UnhandledExceptionFilter () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x00000002 in ?? ()
#4 0x007b7f4c in ?? ()
#5 0x7c8438fa in ValidateLocale () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#6 0x00000000 in ?? ()

(gdb) xbacktrace
(gdb) Undefined command: "xbacktrace". Try "help".

(gdb) Undefined command: "xbacktrace". Try "help".
source .gdbinit
Warning: /cygdrive/c/Program Files/Emacs-24.2/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x1154889: file w32fns.c, line 7200.
Temporary breakpoint 2 at 0x11449c9: file sysdep.c, line 819.
(gdb) xbacktrace
"split-string" (0x82cb40)
"cons" (0x82cd64)
"setq" (0x82ceb4)
"progn" (0x82cfe4)
"if" (0x82d114)
"ac-update-word-index-1" (0x82d200)
"save-current-buffer" (0x82d474)
"progn" (0x82d5a4)
"if" (0x82d6d4)
"while" (0x82d844)
"let" (0x82da14)
"progn" (0x82db44)
"ac-update-word-index" (0x82dce4)
"funcall" (0x82dce0)
"cond" (0x82dee4)
"save-excursion" (0x82e044)
"progn" (0x82e174)
"if" (0x82e2a4)
"while" (0x82e414)
"let*" (0x82e5a4)
"progn" (0x82e6d4)
"ac-init" (0x82e7c0)
"progn" (0x82ea04)
"if" (0x82eb34)
"if" (0x82ec94)
"let*" (0x82ee24)
"if" (0x82ef84)
"progn" (0x82f0b4)
"let*" (0x82f244)
"ac-start" (0x82f330)
"progn" (0x82f584)
"if" (0x82f6b4)
"condition-case" (0x82f894)
"ac-handle-post-command" (0x82fa44)
(gdb)
"split-string" (0x82cb40)
"cons" (0x82cd64)
"setq" (0x82ceb4)
"progn" (0x82cfe4)
"if" (0x82d114)
"ac-update-word-index-1" (0x82d200)
"save-current-buffer" (0x82d474)
"progn" (0x82d5a4)
"if" (0x82d6d4)
"while" (0x82d844)
"let" (0x82da14)
"progn" (0x82db44)
"ac-update-word-index" (0x82dce4)
"funcall" (0x82dce0)
"cond" (0x82dee4)
"save-excursion" (0x82e044)
"progn" (0x82e174)
"if" (0x82e2a4)
"while" (0x82e414)
"let*" (0x82e5a4)
"progn" (0x82e6d4)
"ac-init" (0x82e7c0)
"progn" (0x82ea04)
"if" (0x82eb34)
"if" (0x82ec94)
"let*" (0x82ee24)
"if" (0x82ef84)
"progn" (0x82f0b4)
"let*" (0x82f244)
"ac-start" (0x82f330)
"progn" (0x82f584)
"if" (0x82f6b4)
"condition-case" (0x82f894)
"ac-handle-post-command" (0x82fa44)
(gdb)
--8<---------------cut here---------------end--------------->8---

Hopefully, this time, it should be much more helpful for you (thus, for me!).

Thanks a lot,

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:
>> Eli Zaretskii wrote:
>>>> _Often_ Emacs is just blocked, and C-g can't help me. I simply have to kill
>>>> Emacs from the Task Manager.
>>>
>>> Next time when this happens, instead of killing Emacs, attach GDB to
>>> it and show us the backtrace you get in all threads.
>>
>> It happened now, once again.
>>
>> I attached GDB to it. Or do I have to say that I attached the process to GDB?
>>

>> --8<---------------cut here---------------start------------->8---
>> GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
>> Copyright (C) 2012 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 "i686-cygwin".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>.

That's all crystal clear. Thanks for the explanation.

>> (gdb) Can't attach to process.

>> warning: File "/cygdrive/c/Program Files/Emacs-24.2/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

>> ^C(gdb) Quit
>> quit
>> --8<---------------cut here---------------end--------------->8---
>>
>> But you see I wasn't more successful... Maybe you understand what goes wrong?
>
> It can't attach, because another instance of GDB already is attached.

OK.

>> I guess that I couldn't attach twice GDB processes to Emacs. But what about
>> the warning "auto-loading has been declined by your `auto-load safe-path' set
>> to `$debugdir:$datadir/auto-load'"?
>
> This is a nuisance with latest GDB versions. I have this in my
> ~/.gdbinit to countermand that:
>
> set auto-load safe-path /

Does it make sense to copy Emacs-24.2's .gdbinit file to ~/.gdbinit?

Or, are both config files read, if I start GDB from Emacs-24.2's directory
(where one .gdbinit file is located)?

>>> Here's the culprit:
>>>
>>>> #13 0x010431b7 in die (msg=0x1537030 "assertion failed:
>>>> buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
>>
>> Do you have enough hints with that already?
>
> No. But someone else might.

Hopefully, the other mail I sent (at 13:36) should give you much more details
about what goes wrong for me.

Thanks a lot for your help!

Best regards,

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: 12...@debbugs.gnu.org

> Date: Sat, 06 Oct 2012 13:26:26 +0200

>
> Attaching to process 5928
> [New Thread 5928.0x1904]
> [New Thread 5928.0x1c7c]
> [New Thread 5928.0x1644]
> [New Thread 5928.0x28c]
> Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

> warning: File "/cygdrive/c/Program Files/Emacs-24.2/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

> (gdb) thread apply all backtrace

Since this _is_ a crash, you _must_ type "continue", wait for another
GDB prompt, and only then type "thread apply all backtrace".
Otherwise, you get a backtrace that is not useful. Like this one:

Thread 1 is the interesting thread, but this backtrace just shows that
it is in an exception handler, which is not useful.

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: 12...@debbugs.gnu.org

> Date: Sat, 06 Oct 2012 14:22:39 +0200

>
> Does it make sense to copy Emacs-24.2's .gdbinit file to ~/.gdbinit?

It would, but you will have to remember to remove or rename it when
attaching GDB to other programs.

> Or, are both config files read, if I start GDB from Emacs-24.2's directory
> (where one .gdbinit file is located)?

Your ~/.gdbinit is always read. If there's another .gdbinit in the
directory from which you start GDB, then that file is also read.

> Hopefully, the other mail I sent (at 13:36) should give you much more details
> about what goes wrong for me.

It doesn't :-( But thanks anyway.

[Drew Adams]

FWIW, I too get crashes frequently with Emacs 24 (.1, .2, and dev versions) on
MS Windows. I even get them sometimes when I just click the Windows `X' box in
the upper right of a frame, to close it.

Mentioning this only in case it helps. If not, ignore.

[Eli Zaretskii]

> From: "Drew Adams" <drew....@oracle.com>
> Cc: <12...@debbugs.gnu.org>
> Date: Sat, 6 Oct 2012 10:24:35 -0700

Without at least a backtrace, no, it doesn't help.

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

>> Attaching to process 5928
>> [New Thread 5928.0x1904]
>> [New Thread 5928.0x1c7c]
>> [New Thread 5928.0x1644]
>> [New Thread 5928.0x28c]
>> Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.
>> warning: File "/cygdrive/c/Program Files/Emacs-24.2/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
>> (gdb) thread apply all backtrace
>
> Since this _is_ a crash, you _must_ type "continue", wait for another
> GDB prompt, and only then type "thread apply all backtrace".

Yes, I've the impression that it was well a crash. But wasn't aware yet of the
subtle differences in the GDB commands I have to type. Now, I should be aware.
"Hoping" to give you much more meaningful stuff soon.

> Otherwise, you get a backtrace that is not useful.

AFAICT, there are 3 types of problems I have observed:

- infinite loop, where C-g doesn't do anything
- crash with Emacs dialog box "attach GDB, type continue"
- crash with some sort of Dr Watson, where Windows asks for launching a
debugger.

I must have had that last one this afternoon, in the mail you reply to.

For information, the two last cases can be considered as one, and the same?
That is: type continue, wait, and type "thread..."?

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: 12...@debbugs.gnu.org

> Date: Sat, 06 Oct 2012 22:42:50 +0200

>
> AFAICT, there are 3 types of problems I have observed:
>
> - infinite loop, where C-g doesn't do anything
> - crash with Emacs dialog box "attach GDB, type continue"
> - crash with some sort of Dr Watson, where Windows asks for launching a
> debugger.

Right.

> For information, the two last cases can be considered as one, and the same?
> That is: type continue, wait, and type "thread..."?

Yes.

[Juanma Barranquero]

> FWIW, I too get crashes frequently with Emacs 24 (.1, .2, and dev versions) on
> MS Windows. I even get them sometimes when I just click the Windows `X' box in
> the upper right of a frame, to close it.

How frequently?

Both the OP and you, Drew, are using the binary distributions from
alpha.gnu.org. I do not get crashes, frequent or otherwise, unless
there's a specific problem (like the 64-bit changes the other day).

Perhaps something in the build process, compiler version, compilation
options...? It's hard to pinpoint any connection between both
problems without backtraces, though.

Juanma

[Drew Adams]

> > FWIW, I too get crashes frequently with Emacs 24 (.1, .2,
> > and dev versions) on MS Windows. I even get them sometimes
> > when I just click the Windows `X' box in
> > the upper right of a frame, to close it.
>
> How frequently?

I'm sorry I can't be much help here. I would say it crashes pretty much each
time I use it - and I don't use it for long at a time.

Generally, I use it (and also the latest dev version) now to test software that
I develop using Emacs 23.4 (or older). If it did not crash so much then I would
do that development using 24.2 or even the latest dev version.

The crashes I get seem to happen randomly. I have not been able to associate
them with anything particular that I or Emacs is doing at the time. As I
mentioned, I've even had a few crashes occur when I just clicked a frame `X' to
close the frame (an ordinary frame - nothing unusual).

> Both the OP and you, Drew, are using the binary distributions from
> alpha.gnu.org. I do not get crashes, frequent or otherwise, unless
> there's a specific problem (like the 64-bit changes the other day).

Yes. If you are not using those binaries then perhaps that is a relevant
difference.

> Perhaps something in the build process, compiler version, compilation
> options...? It's hard to pinpoint any connection between both
> problems without backtraces, though.

Admittedly, there is not much to go on. Hopefully there will be more reports,
with more useful information.

One thing that seems interesting (but it doesn't necessarily mean anything) is
that there seem (for me) to be the same frequency of crashes with 24.2 and a dev
version (I don't really use 24.1 much at all, but IIRC it was the same story).
There has been a lot of development since 24.1, including in the C code, but
perhaps (?) some of the problems I'm seeing are the same since 24.1. Dunno.

[Eli Zaretskii]

> From: "Drew Adams" <drew....@oracle.com>
> Cc: "'Eli Zaretskii'" <el...@gnu.org>,
> "'Fabrice Niessen'" <f...@missioncriticalit.com>,
> <12...@debbugs.gnu.org>
> Date: Sun, 7 Oct 2012 10:48:16 -0700

>
> > Perhaps something in the build process, compiler version, compilation
> > options...? It's hard to pinpoint any connection between both
> > problems without backtraces, though.
>
> Admittedly, there is not much to go on. Hopefully there will be more reports,
> with more useful information.

If you, or others, can provide backtraces of these crashes, that would
be a useful beginning.

Anyway, I just installed a change that might fix some crashes. Please
see if the situation changes with the next binary snapshot of the
development sources.

[Fabrice Niessen]

Hi Eli, Drew and all,

Eli Zaretskii wrote:
>>> Perhaps something in the build process, compiler version, compilation
>>> options...? It's hard to pinpoint any connection between both
>>> problems without backtraces, though.
>>
>> Admittedly, there is not much to go on. Hopefully there will be more reports,
>> with more useful information.
>
> If you, or others, can provide backtraces of these crashes, that would
> be a useful beginning.

Here some food... I hope/guess it will help a lot to pinpoint what's going
wrong.

Note that I have the _impression_ that the problem lies, somehow, in packages
I would load from my .emacs file (such as idle-require, auto-complete, helm,
etc.). *NOT* that _they_ are wrong, but, when loaded, the problem would be
(more) apparent.

I say that because I worked a lot on optimizing the performances in my .emacs
recently, and I had no that frequent crashes in a not so far past. And I was
already using the same binary of 24.1 -- This does not apply for 24.2, as I
took one binary of mid-September.

Bon, let's go with the reports... for 3 crashes I had since yesterday morning.

* Infinite loop (24.1? Almost sure)

$ gdb -p 2412

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 2412
[New Thread 2412.0x720]
[New Thread 2412.0x13b4]
[New Thread 2412.0x131c]
[New Thread 2412.0x116c]
[New Thread 2412.0x17ec]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

Warning: /cygdrive/c/Program Files/Emacs-24.2/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x1154889: file w32fns.c, line 7200.
Temporary breakpoint 2 at 0x11449c9: file sysdep.c, line 819.

(gdb) thread apply all backtrace

Thread 5 (Thread 2412.0x17ec):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x715affd0 in ?? ()

#6 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x82a55c)
"helm-kill-async-process" (0x82a74c)
"mapc" (0x82a83c)
"helm-kill-async-processes" (0x82a980)
"helm-update" (0x82ab80)
"if" (0x82adf4)
"helm-check-new-input" (0x82aee0)
"progn" (0x82b134)
"unwind-protect" (0x82b264)
"save-current-buffer" (0x82b3c4)
"let" (0x82b594)
"progn" (0x82b6c4)
"condition-case" (0x82b8a4)
"let" (0x82ba74)
"helm-check-minibuffer-input-1" (0x82bd0c)
"apply" (0x82bd08)
"byte-code" (0x82bf7c)
"timer-event-handler" (0x82c3fc)
"read-from-minibuffer" (0x82ceec)
"let" (0x82d114)
"cond" (0x82d274)
"let*" (0x82d404)
"save-current-buffer" (0x82d564)
"helm-read-pattern-maybe" (0x82d650)
"unwind-protect" (0x82d8b4)
"progn" (0x82d9e4)
"unwind-protect" (0x82db14)
"let" (0x82dce4)
"let" (0x82dec4)
"condition-case" (0x82e0a4)
"unwind-protect" (0x82e1d4)
"let" (0x82e3a4)
"catch" (0x82e594)
"helm-internal" (0x82e724)
"apply" (0x82e7d0)
"if" (0x82e9d4)

---Type <return> to continue, or q <return> to quit---

"helm" (0x82eb64)
"apply" (0x82ec10)
0x403fd68 Lisp type 6
"funcall" (0x82ee50)
"unwind-protect" (0x82f024)
"helm-let-internal" (0x82f110)
"if" (0x82f364)
"helm" (0x82f450)
"helm-other-buffer" (0x82f660)
"helm-for-files" (0x82f944)
"call-interactively" (0x82fb54)

Thread 4 (Thread 2412.0x116c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x0000050c in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x82a55c)
"helm-kill-async-process" (0x82a74c)
"mapc" (0x82a83c)
"helm-kill-async-processes" (0x82a980)
"helm-update" (0x82ab80)
"if" (0x82adf4)
"helm-check-new-input" (0x82aee0)
"progn" (0x82b134)
"unwind-protect" (0x82b264)
"save-current-buffer" (0x82b3c4)
"let" (0x82b594)
"progn" (0x82b6c4)
"condition-case" (0x82b8a4)
"let" (0x82ba74)
"helm-check-minibuffer-input-1" (0x82bd0c)
"apply" (0x82bd08)
"byte-code" (0x82bf7c)
"timer-event-handler" (0x82c3fc)
"read-from-minibuffer" (0x82ceec)
"let" (0x82d114)
"cond" (0x82d274)
"let*" (0x82d404)
"save-current-buffer" (0x82d564)
"helm-read-pattern-maybe" (0x82d650)
"unwind-protect" (0x82d8b4)
"progn" (0x82d9e4)
"unwind-protect" (0x82db14)

---Type <return> to continue, or q <return> to quit---

"let" (0x82dce4)
"let" (0x82dec4)
"condition-case" (0x82e0a4)
"unwind-protect" (0x82e1d4)
"let" (0x82e3a4)
"catch" (0x82e594)
"helm-internal" (0x82e724)
"apply" (0x82e7d0)
"if" (0x82e9d4)
"helm" (0x82eb64)
"apply" (0x82ec10)
0x403fd68 Lisp type 6
"funcall" (0x82ee50)
"unwind-protect" (0x82f024)
"helm-let-internal" (0x82f110)
"if" (0x82f364)
"helm" (0x82f450)
"helm-other-buffer" (0x82f660)
"helm-for-files" (0x82f944)
"call-interactively" (0x82fb54)

Thread 3 (Thread 2412.0x131c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x000006a4 in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x82a55c)
"helm-kill-async-process" (0x82a74c)
"mapc" (0x82a83c)
"helm-kill-async-processes" (0x82a980)
"helm-update" (0x82ab80)
"if" (0x82adf4)
"helm-check-new-input" (0x82aee0)
"progn" (0x82b134)
"unwind-protect" (0x82b264)
"save-current-buffer" (0x82b3c4)
"let" (0x82b594)
"progn" (0x82b6c4)
"condition-case" (0x82b8a4)
"let" (0x82ba74)
"helm-check-minibuffer-input-1" (0x82bd0c)
"apply" (0x82bd08)
"byte-code" (0x82bf7c)
"timer-event-handler" (0x82c3fc)

---Type <return> to continue, or q <return> to quit---

"read-from-minibuffer" (0x82ceec)
"let" (0x82d114)
"cond" (0x82d274)
"let*" (0x82d404)
"save-current-buffer" (0x82d564)
"helm-read-pattern-maybe" (0x82d650)
"unwind-protect" (0x82d8b4)
"progn" (0x82d9e4)
"unwind-protect" (0x82db14)
"let" (0x82dce4)
"let" (0x82dec4)
"condition-case" (0x82e0a4)
"unwind-protect" (0x82e1d4)
"let" (0x82e3a4)
"catch" (0x82e594)
"helm-internal" (0x82e724)
"apply" (0x82e7d0)
"if" (0x82e9d4)
"helm" (0x82eb64)
"apply" (0x82ec10)
0x403fd68 Lisp type 6
"funcall" (0x82ee50)
"unwind-protect" (0x82f024)
"helm-let-internal" (0x82f110)
"if" (0x82f364)
"helm" (0x82f450)
"helm-other-buffer" (0x82f660)
"helm-for-files" (0x82f944)
"call-interactively" (0x82fb54)

Thread 2 (Thread 2412.0x13b4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x011490bd in w32_msg_pump (msg_buf=0x7236ff54) at w32fns.c:2263
#4 0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x82a55c)
"helm-kill-async-process" (0x82a74c)
"mapc" (0x82a83c)
"helm-kill-async-processes" (0x82a980)
"helm-update" (0x82ab80)
"if" (0x82adf4)
"helm-check-new-input" (0x82aee0)

---Type <return> to continue, or q <return> to quit---

"progn" (0x82b134)
"unwind-protect" (0x82b264)
"save-current-buffer" (0x82b3c4)
"let" (0x82b594)
"progn" (0x82b6c4)
"condition-case" (0x82b8a4)
"let" (0x82ba74)
"helm-check-minibuffer-input-1" (0x82bd0c)
"apply" (0x82bd08)
"byte-code" (0x82bf7c)
"timer-event-handler" (0x82c3fc)
"read-from-minibuffer" (0x82ceec)
"let" (0x82d114)
"cond" (0x82d274)
"let*" (0x82d404)
"save-current-buffer" (0x82d564)
"helm-read-pattern-maybe" (0x82d650)
"unwind-protect" (0x82d8b4)
"progn" (0x82d9e4)
"unwind-protect" (0x82db14)
"let" (0x82dce4)
"let" (0x82dec4)
"condition-case" (0x82e0a4)
"unwind-protect" (0x82e1d4)
"let" (0x82e3a4)
"catch" (0x82e594)
"helm-internal" (0x82e724)
"apply" (0x82e7d0)
"if" (0x82e9d4)
"helm" (0x82eb64)
"apply" (0x82ec10)
0x403fd68 Lisp type 6
"funcall" (0x82ee50)
"unwind-protect" (0x82f024)
"helm-let-internal" (0x82f110)
"if" (0x82f364)
"helm" (0x82f450)
"helm-other-buffer" (0x82f660)
"helm-for-files" (0x82f944)
"call-interactively" (0x82fb54)

Thread 1 (Thread 2412.0x720):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#4 0x00a41fbc in ?? ()

---Type <return> to continue, or q <return> to quit---

#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll
#6 0x00000004 in ?? ()
#7 0x00000008 in ?? ()
#8 0x00000004 in ?? ()
#9 0x04ae9e70 in ?? ()
#10 0x0105fdc8 in sys_close (fd=4) at w32.c:5960
#11 0x01145749 in emacs_close (fd=4) at sysdep.c:1851
#12 0x0104b550 in deactivate_process (proc=78552693) at process.c:3929
#13 0x0104457e in remove_process (proc=78552693) at process.c:746
#14 0x010519b6 in status_notify (deleting_process=0x4ae9e70) at process.c:6673
#15 0x01044a4f in Fdelete_process (process=78552693) at process.c:861
#16 0x01034973 in eval_sub (form=61861718) at eval.c:2157
#17 0x0103087a in Fprogn (args=61861422) at eval.c:369
#18 0x010374ef in funcall_lambda (fun=61861358, nargs=1, arg_vector=0x82a74c) at eval.c:3021
#19 0x01036b8f in Ffuncall (nargs=2, args=0x82a748) at eval.c:2857
#20 0x01035e61 in call1 (fn=62683074, arg1=78552693) at eval.c:2590
#21 0x0107bf8c in mapcar1 (leni=1, vals=0x0, fn=62683074, seq=76855542) at fns.c:2318
#22 0x0107c477 in Fmapc (function=62683074, sequence=76855542) at fns.c:2407
#23 0x010349e0 in eval_sub (form=61862254) at eval.c:2160
#24 0x0103087a in Fprogn (args=61862038) at eval.c:369
#25 0x010374ef in funcall_lambda (fun=61861974, nargs=0, arg_vector=0x82a980) at eval.c:3021
#26 0x01036dfe in apply_lambda (fun=61861974, args=56346650) at eval.c:2905
#27 0x01034f5b in eval_sub (form=61760982) at eval.c:2232
#28 0x0103087a in Fprogn (args=61774534) at eval.c:369
#29 0x010374ef in funcall_lambda (fun=61774606, nargs=0, arg_vector=0x82ab80) at eval.c:3021
#30 0x01036dfe in apply_lambda (fun=61774606, args=56346650) at eval.c:2905
#31 0x01034f5b in eval_sub (form=56593110) at eval.c:2232
#32 0x0103087a in Fprogn (args=56592750) at eval.c:369
#33 0x010306fe in Fif (args=56592046) at eval.c:320
#34 0x0103453b in eval_sub (form=56592054) at eval.c:2105
#35 0x0103087a in Fprogn (args=56591806) at eval.c:369
#36 0x010374ef in funcall_lambda (fun=56591830, nargs=1, arg_vector=0x82aee0) at eval.c:3021
#37 0x01036dfe in apply_lambda (fun=56591830, args=61546790) at eval.c:2905
#38 0x01034f5b in eval_sub (form=61546854) at eval.c:2232
#39 0x0103087a in Fprogn (args=56594134) at eval.c:369
#40 0x0103453b in eval_sub (form=56594014) at eval.c:2105
#41 0x01032267 in Funwind_protect (args=56594006) at eval.c:1167
#42 0x0103453b in eval_sub (form=56593998) at eval.c:2105
#43 0x0103087a in Fprogn (args=56593974) at eval.c:369
#44 0x011032d4 in Fsave_current_buffer (args=56593974) at editfns.c:951
#45 0x0103453b in eval_sub (form=56593966) at eval.c:2105
#46 0x0103087a in Fprogn (args=56593958) at eval.c:369
#47 0x01031cc1 in Flet (args=56593950) at eval.c:923
#48 0x0103453b in eval_sub (form=56593942) at eval.c:2105
#49 0x0103087a in Fprogn (args=56593734) at eval.c:369
#50 0x0103453b in eval_sub (form=56593742) at eval.c:2105
#51 0x010325bd in internal_lisp_condition_case (var=58047706, bodyform=56593742, handlers=67374158) at eval.c:1262

---Type <return> to continue, or q <return> to quit---

#52 0x010322d7 in Fcondition_case (args=56593662) at eval.c:1203
#53 0x0103453b in eval_sub (form=56593654) at eval.c:2105
#54 0x0103087a in Fprogn (args=56593646) at eval.c:369
#55 0x01031cc1 in Flet (args=56593630) at eval.c:923
#56 0x0103453b in eval_sub (form=56593622) at eval.c:2105
#57 0x0103087a in Fprogn (args=56593590) at eval.c:369
#58 0x010374ef in funcall_lambda (fun=56593614, nargs=0, arg_vector=0x82bd0c) at eval.c:3021
#59 0x01036b8f in Ffuncall (nargs=1, args=0x82bd08) at eval.c:2857
#60 0x0103505e in Fapply (nargs=2, args=0x82bd08) at eval.c:2269
#61 0x0103640c in Ffuncall (nargs=3, args=0x82bd04) at eval.c:2777
#62 0x010e0e77 in exec_byte_code (bytestr=20934073, vector=20934125, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#63 0x010e023e in Fbyte_code (bytestr=20934073, vector=20934125, maxdepth=16) at bytecode.c:474
#64 0x01034a57 in eval_sub (form=20934062) at eval.c:2163
#65 0x010325bd in internal_lisp_condition_case (var=56346650, bodyform=20934062, handlers=20120582) at eval.c:1262
#66 0x010e1ab4 in exec_byte_code (bytestr=20933817, vector=20933949, maxdepth=20, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:1095
#67 0x01037624 in funcall_lambda (fun=20933789, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#68 0x01036abd in Ffuncall (nargs=2, args=0x82c3f8) at eval.c:2845
#69 0x01035e61 in call1 (fn=56388898, arg1=78552965) at eval.c:2590
#70 0x0100e60f in timer_check_2 () at keyboard.c:4461
#71 0x0100e692 in timer_check () at keyboard.c:4507
#72 0x0100c4a7 in readable_events (flags=1) at keyboard.c:3404
#73 0x01014ffa in get_input_pending (addr=0x1664980, flags=1) at keyboard.c:6730
#74 0x0102083f in detect_input_pending_run_timers (do_display=1) at keyboard.c:10357
#75 0x0104cfc2 in wait_reading_process_output (time_limit=8, nsecs=0, read_kbd=-1, do_display=1, wait_for_cell=56346650,
wait_proc=0x0, just_wait_proc=0) at process.c:4768
#76 0x010fbc2a in sit_for (timeout=32, reading=true, do_display=1) at dispnew.c:5977
#77 0x010095c4 in read_char (commandflag=1, nmaps=2, maps=0x82c880, prev_event=56346650, used_mouse_menu=0x82c958, end_time=0x0)
at keyboard.c:2707
#78 0x0101ccb2 in read_key_sequence (keybuf=0x82cae0, bufsize=30, prompt=56346650, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9312
#79 0x01005f89 in command_loop_1 () at keyboard.c:1487
#80 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#81 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#82 0x010320bb in internal_catch (tag=56450866, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#83 0x0100562d in command_loop () at keyboard.c:1147
#84 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#85 0x010beab0 in read_minibuf (map=67894814, initial=56346650, prompt=65029089, expflag=0, histvar=56468442, histpos=0,
defalt=69408721, allow_props=0, inherit_input_method=0) at minibuf.c:685
#86 0x010bf7b3 in Fread_from_minibuffer (prompt=65029089, initial_contents=56346650, keymap=67894814, sys_read=56346650,
hist=56346650, default_value=69408721, inherit_input_method=56346650) at minibuf.c:987
#87 0x01034cc7 in eval_sub (form=60478894) at eval.c:2181
#88 0x0103087a in Fprogn (args=60478718) at eval.c:369
#89 0x01031cc1 in Flet (args=60548358) at eval.c:923
#90 0x0103453b in eval_sub (form=60548350) at eval.c:2105

---Type <return> to continue, or q <return> to quit---

#91 0x0103087a in Fprogn (args=60548334) at eval.c:369
#92 0x010307c8 in Fcond (args=60548294) at eval.c:347
#93 0x0103453b in eval_sub (form=60548270) at eval.c:2105
#94 0x0103087a in Fprogn (args=60548262) at eval.c:369
#95 0x01031829 in FletX (args=60548246) at eval.c:853
#96 0x0103453b in eval_sub (form=60548238) at eval.c:2105
#97 0x0103087a in Fprogn (args=60548054) at eval.c:369
#98 0x011032d4 in Fsave_current_buffer (args=60548062) at editfns.c:951
#99 0x0103453b in eval_sub (form=60548134) at eval.c:2105
#100 0x0103087a in Fprogn (args=60547782) at eval.c:369
#101 0x010374ef in funcall_lambda (fun=60548038, nargs=7, arg_vector=0x82d650) at eval.c:3021
#102 0x01036dfe in apply_lambda (fun=60548038, args=67413790) at eval.c:2905
#103 0x01034f5b in eval_sub (form=67413782) at eval.c:2232
#104 0x01032267 in Funwind_protect (args=67413854) at eval.c:1167
#105 0x0103453b in eval_sub (form=67413846) at eval.c:2105
#106 0x0103087a in Fprogn (args=67413902) at eval.c:369
#107 0x0103453b in eval_sub (form=67413870) at eval.c:2105
#108 0x01032267 in Funwind_protect (args=67413918) at eval.c:1167
#109 0x0103453b in eval_sub (form=67413910) at eval.c:2105
#110 0x0103087a in Fprogn (args=67411638) at eval.c:369
#111 0x01031cc1 in Flet (args=67411646) at eval.c:923
#112 0x0103453b in eval_sub (form=67411654) at eval.c:2105
#113 0x0103087a in Fprogn (args=67411662) at eval.c:369
#114 0x01031cc1 in Flet (args=67411814) at eval.c:923
#115 0x0103453b in eval_sub (form=67411822) at eval.c:2105
#116 0x010325bd in internal_lisp_condition_case (var=58047706, bodyform=67411822, handlers=67414686) at eval.c:1262
#117 0x010322d7 in Fcondition_case (args=67411902) at eval.c:1203
#118 0x0103453b in eval_sub (form=67411910) at eval.c:2105
#119 0x01032267 in Funwind_protect (args=67411926) at eval.c:1167
#120 0x0103453b in eval_sub (form=67411918) at eval.c:2105
#121 0x0103087a in Fprogn (args=67409950) at eval.c:369
#122 0x01031cc1 in Flet (args=67409958) at eval.c:923
#123 0x0103453b in eval_sub (form=67409966) at eval.c:2105
#124 0x0103087a in Fprogn (args=67409974) at eval.c:369
#125 0x010320bb in internal_catch (tag=56450866, func=0x1030825 <Fprogn>, arg=67413134) at eval.c:1069
#126 0x01032021 in Fcatch (args=67413126) at eval.c:1040
#127 0x0103453b in eval_sub (form=67413118) at eval.c:2105
#128 0x0103087a in Fprogn (args=67410006) at eval.c:369
#129 0x010374ef in funcall_lambda (fun=67409982, nargs=9, arg_vector=0x82e724) at eval.c:3021
#130 0x01036b8f in Ffuncall (nargs=10, args=0x82e720) at eval.c:2857
#131 0x010358a8 in Fapply (nargs=2, args=0x82e7d0) at eval.c:2326
#132 0x010347cc in eval_sub (form=67371854) at eval.c:2129
#133 0x0103087a in Fprogn (args=67371894) at eval.c:369
#134 0x010306fe in Fif (args=67370422) at eval.c:320
#135 0x0103453b in eval_sub (form=67370414) at eval.c:2105
#136 0x0103087a in Fprogn (args=67370486) at eval.c:369
#137 0x010374ef in funcall_lambda (fun=67370462, nargs=9, arg_vector=0x82eb64) at eval.c:3021

---Type <return> to continue, or q <return> to quit---

#138 0x01036b8f in Ffuncall (nargs=10, args=0x82eb60) at eval.c:2857
#139 0x010358a8 in Fapply (nargs=2, args=0x82ec10) at eval.c:2326
#140 0x010347cc in eval_sub (form=67370326) at eval.c:2129
#141 0x0103087a in Fprogn (args=67370366) at eval.c:369
#142 0x010374ef in funcall_lambda (fun=67370350, nargs=0, arg_vector=0x82ee54) at eval.c:3021
#143 0x01036b8f in Ffuncall (nargs=1, args=0x82ee50) at eval.c:2857
#144 0x010347cc in eval_sub (form=67349422) at eval.c:2129
#145 0x01032267 in Funwind_protect (args=67349438) at eval.c:1167
#146 0x0103453b in eval_sub (form=67349414) at eval.c:2105
#147 0x0103087a in Fprogn (args=67347550) at eval.c:369
#148 0x010374ef in funcall_lambda (fun=67347614, nargs=2, arg_vector=0x82f110) at eval.c:3021
#149 0x01036dfe in apply_lambda (fun=67347614, args=67370398) at eval.c:2905
#150 0x01034f5b in eval_sub (form=67370390) at eval.c:2232
#151 0x010306e1 in Fif (args=67370422) at eval.c:319
#152 0x0103453b in eval_sub (form=67370414) at eval.c:2105
#153 0x0103087a in Fprogn (args=67370486) at eval.c:369
#154 0x010374ef in funcall_lambda (fun=67370462, nargs=4, arg_vector=0x82f450) at eval.c:3021
#155 0x01036dfe in apply_lambda (fun=67370462, args=67408318) at eval.c:2905
#156 0x01034f5b in eval_sub (form=67408310) at eval.c:2232
#157 0x0103087a in Fprogn (args=67408438) at eval.c:369
#158 0x010374ef in funcall_lambda (fun=67408494, nargs=2, arg_vector=0x82f660) at eval.c:3021
#159 0x01036dfe in apply_lambda (fun=67408494, args=66726406) at eval.c:2905
#160 0x01034f5b in eval_sub (form=66726398) at eval.c:2232
#161 0x0103087a in Fprogn (args=66726510) at eval.c:369
#162 0x010374ef in funcall_lambda (fun=66726574, nargs=0, arg_vector=0x82f944) at eval.c:3021
#163 0x01036b8f in Ffuncall (nargs=1, args=0x82f940) at eval.c:2857
#164 0x01035dd8 in apply1 (fn=57906730, arg=56346650) at eval.c:2557
#165 0x010e4bed in Fcall_interactively (function=57906730, record_flag=56346650, keys=56368045) at callint.c:377
#166 0x0103677b in Ffuncall (nargs=4, args=0x82fb50) at eval.c:2803
#167 0x01035edb in call3 (fn=56457962, arg1=57906730, arg2=56346650, arg3=56346650) at eval.c:2621
#168 0x010207b2 in Fcommand_execute (cmd=57906730, record_flag=56346650, keys=56346650, special=56346650) at keyboard.c:10319
#169 0x010067de in command_loop_1 () at keyboard.c:1615
#170 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#171 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#172 0x010320bb in internal_catch (tag=56387090, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#173 0x0100567e in command_loop () at keyboard.c:1161
#174 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#175 0x01004f54 in Frecursive_edit () at keyboard.c:846
#176 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655

Lisp Backtrace:
"delete-process" (0x82a55c)
"helm-kill-async-process" (0x82a74c)
"mapc" (0x82a83c)
"helm-kill-async-processes" (0x82a980)
"helm-update" (0x82ab80)

---Type <return> to continue, or q <return> to quit---

"if" (0x82adf4)
"helm-check-new-input" (0x82aee0)
"progn" (0x82b134)
"unwind-protect" (0x82b264)
"save-current-buffer" (0x82b3c4)
"let" (0x82b594)
"progn" (0x82b6c4)
"condition-case" (0x82b8a4)
"let" (0x82ba74)
"helm-check-minibuffer-input-1" (0x82bd0c)
"apply" (0x82bd08)
"byte-code" (0x82bf7c)
"timer-event-handler" (0x82c3fc)
"read-from-minibuffer" (0x82ceec)
"let" (0x82d114)
"cond" (0x82d274)
"let*" (0x82d404)
"save-current-buffer" (0x82d564)
"helm-read-pattern-maybe" (0x82d650)
"unwind-protect" (0x82d8b4)
"progn" (0x82d9e4)
"unwind-protect" (0x82db14)
"let" (0x82dce4)
"let" (0x82dec4)
"condition-case" (0x82e0a4)
"unwind-protect" (0x82e1d4)
"let" (0x82e3a4)
"catch" (0x82e594)
"helm-internal" (0x82e724)
"apply" (0x82e7d0)
"if" (0x82e9d4)
"helm" (0x82eb64)
"apply" (0x82ec10)
0x403fd68 Lisp type 6
"funcall" (0x82ee50)
"unwind-protect" (0x82f024)
"helm-let-internal" (0x82f110)
"if" (0x82f364)
"helm" (0x82f450)
"helm-other-buffer" (0x82f660)
"helm-for-files" (0x82f944)
"call-interactively" (0x82fb54)
(gdb)
(gdb) xbacktrace
"delete-process" (0x82a55c)
"helm-kill-async-process" (0x82a74c)
"mapc" (0x82a83c)
"helm-kill-async-processes" (0x82a980)
"helm-update" (0x82ab80)
"if" (0x82adf4)
"helm-check-new-input" (0x82aee0)
"progn" (0x82b134)
"unwind-protect" (0x82b264)
"save-current-buffer" (0x82b3c4)
"let" (0x82b594)
"progn" (0x82b6c4)
"condition-case" (0x82b8a4)
"let" (0x82ba74)
"helm-check-minibuffer-input-1" (0x82bd0c)
"apply" (0x82bd08)
"byte-code" (0x82bf7c)
"timer-event-handler" (0x82c3fc)
"read-from-minibuffer" (0x82ceec)
"let" (0x82d114)
"cond" (0x82d274)
"let*" (0x82d404)
"save-current-buffer" (0x82d564)
"helm-read-pattern-maybe" (0x82d650)
"unwind-protect" (0x82d8b4)
"progn" (0x82d9e4)
"unwind-protect" (0x82db14)
"let" (0x82dce4)
"let" (0x82dec4)
"condition-case" (0x82e0a4)
"unwind-protect" (0x82e1d4)
"let" (0x82e3a4)
"catch" (0x82e594)
"helm-internal" (0x82e724)
"apply" (0x82e7d0)
"if" (0x82e9d4)
"helm" (0x82eb64)
"apply" (0x82ec10)
0x403fd68 Lisp type 6
"funcall" (0x82ee50)
"unwind-protect" (0x82f024)
"helm-let-internal" (0x82f110)
"if" (0x82f364)
"helm" (0x82f450)
"helm-other-buffer" (0x82f660)
"helm-for-files" (0x82f944)
"call-interactively" (0x82fb54)
(gdb) quit
A debugging session is active.

Inferior 1 [process 2412] will be detached.

Quit anyway? (y or n) y
error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1392 was 31
error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1273 was 31
error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1273 was 31
error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1273 was 31
error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1273 was 31
Quitting: Can't detach process 2412 (error 5)
Fabrice@MEDIACENTER:Program Files/Emacs-24.2 0$

* Emacs Abord Dialog (24.2)

$ gdb -p 5624

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 5624
[New Thread 5624.0x15ac]
[New Thread 5624.0x16f4]
[New Thread 5624.0x1354]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

Warning: /cygdrive/c/Program Files/Emacs-24.2/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x1154889: file w32fns.c, line 7200.
Temporary breakpoint 2 at 0x11449c9: file sysdep.c, line 819.
(gdb)

(gdb)
(gdb) continue

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

[Switching to Thread 5624.0x15ac]

0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) thread apply all backtrace

Thread 2 (Thread 5624.0x16f4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x77ef6bf2 in GdiDrawStream () from /cygdrive/c/WINDOWS/system32/GDI32.dll
#2 0x00fa2b1b in ?? () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#3 0x00fa289b in ?? () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#4 0x00fa406b in UxTheme!GetWindowTheme () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#5 0x00fa2c9f in UxTheme!DrawThemeParentBackground () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#6 0x00fa5f14 in UxTheme!SetThemeAppProperties () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#7 0x00fa6485 in UxTheme!SetThemeAppProperties () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#8 0x00fa67ed in UxTheme!SetThemeAppProperties () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#9 0x00fa1ac7 in ?? () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#10 0x00fa1b3d in ?? () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#11 0x7e3a94ed in USER32!GetPropW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#12 0x0114d071 in w32_wnd_proc (hwnd=0x33039e, msg=134, wParam=0, lParam=0) at w32fns.c:3831
#13 0x7e398734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/USER32.dll
#14 0x0033039e in ?? ()
#15 0x00000086 in ?? ()
#16 0x00000000 in ?? ()

Lisp Backtrace:
"progn" (0x82c474)
"if" (0x82c5a4)
"catch" (0x82c794)
"while" (0x82c904)
"save-restriction" (0x82ca64)
"save-excursion" (0x82cbc4)
"progn" (0x82ccf4)
"or" (0x82ce24)
"save-current-buffer" (0x82cf84)
"while" (0x82d0f4)
"while" (0x82d264)
"save-current-buffer" (0x82d3c4)
"let" (0x82d5c4)
"org-refile-get-targets" (0x82d6b0)
"setq" (0x82d924)
"let" (0x82daf4)
"org-refile-get-location" (0x82dbe0)
"save-excursion" (0x82de64)
"let" (0x82e034)
"or" (0x82e164)
"setq" (0x82e2b4)
"or" (0x82e3e4)
"if" (0x82e514)
"if" (0x82e674)
"let*" (0x82e804)
"if" (0x82e964)

---Type <return> to continue, or q <return> to quit---

"org-refile" (0x82eb44)
"call-interactively" (0x82ed0c)
"save-restriction" (0x82eec4)
"save-excursion" (0x82f024)
"save-current-buffer" (0x82f184)
"progn" (0x82f2b4)
"unwind-protect" (0x82f3e4)
"let" (0x82f5b4)
"let" (0x82f784)
"org-capture-refile" (0x82f944)
"call-interactively" (0x82fb54)

Thread 1 (Thread 5624.0x15ac):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x011548c0 in emacs_abort () at w32fns.c:7214
#2 0x01055503 in sys_kill (pid=5624, sig=22) at w32proc.c:1432
#3 0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647) at emacs.c:331
#4 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
line=1664) at alloc.c:6398
#5 0x010ac068 in compact_buffer (buffer=0x3c44600) at buffer.c:1664
#6 0x0103fde2 in Fgarbage_collect () at alloc.c:5085
#7 0x0103997b in maybe_gc () at lisp.h:3637
#8 0x010341a8 in eval_sub (form=68615390) at eval.c:2054
#9 0x0103087a in Fprogn (args=68615310) at eval.c:369
#10 0x0103453b in eval_sub (form=68615462) at eval.c:2105
#11 0x010306e1 in Fif (args=68615294) at eval.c:319
#12 0x0103453b in eval_sub (form=68615302) at eval.c:2105
#13 0x0103087a in Fprogn (args=68615278) at eval.c:369
#14 0x010320bb in internal_catch (tag=58060850, func=0x1030825 <Fprogn>, arg=68616494) at eval.c:1069
#15 0x01032021 in Fcatch (args=68616502) at eval.c:1040
#16 0x0103453b in eval_sub (form=68616510) at eval.c:2105
#17 0x0103087a in Fprogn (args=68615246) at eval.c:369
#18 0x01031d5a in Fwhile (args=68615262) at eval.c:945
#19 0x0103453b in eval_sub (form=68615270) at eval.c:2105
#20 0x0103087a in Fprogn (args=68614998) at eval.c:369
#21 0x01109c8e in Fsave_restriction (body=68615014) at editfns.c:3423
#22 0x0103453b in eval_sub (form=68615022) at eval.c:2105
#23 0x0103087a in Fprogn (args=68614982) at eval.c:369
#24 0x0110328f in Fsave_excursion (args=68614982) at editfns.c:938
#25 0x0103453b in eval_sub (form=68614990) at eval.c:2105
#26 0x0103087a in Fprogn (args=68614974) at eval.c:369
#27 0x0103453b in eval_sub (form=68617014) at eval.c:2105
#28 0x01030584 in For (args=68614950) at eval.c:269
#29 0x0103453b in eval_sub (form=68614966) at eval.c:2105
#30 0x0103087a in Fprogn (args=68614926) at eval.c:369
#31 0x011032d4 in Fsave_current_buffer (args=68614934) at editfns.c:951
#32 0x0103453b in eval_sub (form=68614942) at eval.c:2105

---Type <return> to continue, or q <return> to quit---

#33 0x0103087a in Fprogn (args=68614774) at eval.c:369
#34 0x01031d5a in Fwhile (args=68617526) at eval.c:945
#35 0x0103453b in eval_sub (form=68617534) at eval.c:2105
#36 0x0103087a in Fprogn (args=68614726) at eval.c:369
#37 0x01031d5a in Fwhile (args=68619286) at eval.c:945
#38 0x0103453b in eval_sub (form=68619294) at eval.c:2105
#39 0x0103087a in Fprogn (args=68614702) at eval.c:369
#40 0x011032d4 in Fsave_current_buffer (args=68614710) at editfns.c:951
#41 0x0103453b in eval_sub (form=68614718) at eval.c:2105
#42 0x0103087a in Fprogn (args=68614686) at eval.c:369
#43 0x01031cc1 in Flet (args=68614646) at eval.c:923
#44 0x0103453b in eval_sub (form=68614638) at eval.c:2105
#45 0x0103087a in Fprogn (args=68614606) at eval.c:369
#46 0x010374ef in funcall_lambda (fun=68614630, nargs=2, arg_vector=0x82d6b0) at eval.c:3021
#47 0x01036dfe in apply_lambda (fun=68614630, args=68674142) at eval.c:2905
#48 0x01034f5b in eval_sub (form=68674150) at eval.c:2232
#49 0x01030a7d in Fsetq (args=68674158) at eval.c:438
#50 0x0103453b in eval_sub (form=68674166) at eval.c:2105
#51 0x0103087a in Fprogn (args=68674118) at eval.c:369
#52 0x01031cc1 in Flet (args=68670054) at eval.c:923
#53 0x0103453b in eval_sub (form=68670046) at eval.c:2105
#54 0x0103087a in Fprogn (args=68670014) at eval.c:369
#55 0x010374ef in funcall_lambda (fun=68670038, nargs=4, arg_vector=0x82dbe0) at eval.c:3021
#56 0x01036dfe in apply_lambda (fun=68670038, args=68640982) at eval.c:2905
#57 0x01034f5b in eval_sub (form=68641286) at eval.c:2232
#58 0x0103087a in Fprogn (args=68640862) at eval.c:369
#59 0x0110328f in Fsave_excursion (args=68635046) at editfns.c:938
#60 0x0103453b in eval_sub (form=68635054) at eval.c:2105
#61 0x0103087a in Fprogn (args=68634174) at eval.c:369
#62 0x01031cc1 in Flet (args=68634166) at eval.c:923
#63 0x0103453b in eval_sub (form=68634158) at eval.c:2105
#64 0x01030584 in For (args=68634134) at eval.c:269
#65 0x0103453b in eval_sub (form=68634150) at eval.c:2105
#66 0x01030a7d in Fsetq (args=68634118) at eval.c:438
#67 0x0103453b in eval_sub (form=68634126) at eval.c:2105
#68 0x01030584 in For (args=68634086) at eval.c:269
#69 0x0103453b in eval_sub (form=68634102) at eval.c:2105
#70 0x010306bb in Fif (args=68634070) at eval.c:315
#71 0x0103453b in eval_sub (form=68634078) at eval.c:2105
#72 0x0103087a in Fprogn (args=68675230) at eval.c:369
#73 0x010306fe in Fif (args=68675246) at eval.c:320
#74 0x0103453b in eval_sub (form=68675254) at eval.c:2105
#75 0x0103087a in Fprogn (args=68675222) at eval.c:369
#76 0x01031829 in FletX (args=68675214) at eval.c:853
#77 0x0103453b in eval_sub (form=68675206) at eval.c:2105
#78 0x0103087a in Fprogn (args=68675174) at eval.c:369
#79 0x010306fe in Fif (args=68675190) at eval.c:320

---Type <return> to continue, or q <return> to quit---

#80 0x0103453b in eval_sub (form=68675198) at eval.c:2105
#81 0x0103087a in Fprogn (args=68675134) at eval.c:369
#82 0x010374ef in funcall_lambda (fun=68675166, nargs=1, arg_vector=0x82eb44) at eval.c:3021
#83 0x01036b8f in Ffuncall (nargs=2, args=0x82eb40) at eval.c:2857
#84 0x010e6918 in Fcall_interactively (function=56783474, record_flag=56346650, keys=56368045) at callint.c:852
#85 0x01034a57 in eval_sub (form=75074790) at eval.c:2163
#86 0x0103087a in Fprogn (args=75074822) at eval.c:369
#87 0x01109c8e in Fsave_restriction (body=75074758) at editfns.c:3423
#88 0x0103453b in eval_sub (form=75074742) at eval.c:2105
#89 0x0103087a in Fprogn (args=75074830) at eval.c:369
#90 0x0110328f in Fsave_excursion (args=75074830) at editfns.c:938
#91 0x0103453b in eval_sub (form=75074734) at eval.c:2105
#92 0x0103087a in Fprogn (args=75075430) at eval.c:369
#93 0x011032d4 in Fsave_current_buffer (args=75075454) at editfns.c:951
#94 0x0103453b in eval_sub (form=75075462) at eval.c:2105
#95 0x0103087a in Fprogn (args=75073550) at eval.c:369
#96 0x0103453b in eval_sub (form=75073542) at eval.c:2105
#97 0x01032267 in Funwind_protect (args=75073566) at eval.c:1167
#98 0x0103453b in eval_sub (form=75073558) at eval.c:2105
#99 0x0103087a in Fprogn (args=75073590) at eval.c:369
#100 0x01031cc1 in Flet (args=75073598) at eval.c:923
#101 0x0103453b in eval_sub (form=75073606) at eval.c:2105
#102 0x0103087a in Fprogn (args=75073622) at eval.c:369
#103 0x01031cc1 in Flet (args=75073630) at eval.c:923
#104 0x0103453b in eval_sub (form=75073638) at eval.c:2105
#105 0x0103087a in Fprogn (args=75073646) at eval.c:369
#106 0x010374ef in funcall_lambda (fun=75075206, nargs=0, arg_vector=0x82f944) at eval.c:3021
#107 0x01036b8f in Ffuncall (nargs=1, args=0x82f940) at eval.c:2857
#108 0x01035dd8 in apply1 (fn=74372482, arg=56346650) at eval.c:2557
#109 0x010e4bed in Fcall_interactively (function=74372482, record_flag=56346650, keys=56368045) at callint.c:377
#110 0x0103677b in Ffuncall (nargs=4, args=0x82fb50) at eval.c:2803
#111 0x01035edb in call3 (fn=56457962, arg1=74372482, arg2=56346650, arg3=56346650) at eval.c:2621
#112 0x010207b2 in Fcommand_execute (cmd=74372482, record_flag=56346650, keys=56346650, special=56346650) at keyboard.c:10319
#113 0x010067de in command_loop_1 () at keyboard.c:1615
#114 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#115 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#116 0x010320bb in internal_catch (tag=56387090, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#117 0x0100567e in command_loop () at keyboard.c:1161
#118 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#119 0x01004f54 in Frecursive_edit () at keyboard.c:846
#120 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655

Lisp Backtrace:
"progn" (0x82c474)
"if" (0x82c5a4)
"catch" (0x82c794)

---Type <return> to continue, or q <return> to quit---

"while" (0x82c904)
"save-restriction" (0x82ca64)
"save-excursion" (0x82cbc4)
"progn" (0x82ccf4)
"or" (0x82ce24)
"save-current-buffer" (0x82cf84)
"while" (0x82d0f4)
"while" (0x82d264)
"save-current-buffer" (0x82d3c4)
"let" (0x82d5c4)
"org-refile-get-targets" (0x82d6b0)
"setq" (0x82d924)
"let" (0x82daf4)
"org-refile-get-location" (0x82dbe0)
"save-excursion" (0x82de64)
"let" (0x82e034)
"or" (0x82e164)
"setq" (0x82e2b4)
"or" (0x82e3e4)
"if" (0x82e514)
"if" (0x82e674)
"let*" (0x82e804)
"if" (0x82e964)
"org-refile" (0x82eb44)
"call-interactively" (0x82ed0c)
"save-restriction" (0x82eec4)
"save-excursion" (0x82f024)
"save-current-buffer" (0x82f184)
"progn" (0x82f2b4)
"unwind-protect" (0x82f3e4)
"let" (0x82f5b4)
"let" (0x82f784)
"org-capture-refile" (0x82f944)
"call-interactively" (0x82fb54)
(gdb)
(gdb) xbacktrace
"progn" (0x82c474)
"if" (0x82c5a4)
"catch" (0x82c794)
"while" (0x82c904)
"save-restriction" (0x82ca64)
"save-excursion" (0x82cbc4)
"progn" (0x82ccf4)
"or" (0x82ce24)
"save-current-buffer" (0x82cf84)
"while" (0x82d0f4)
"while" (0x82d264)
"save-current-buffer" (0x82d3c4)
"let" (0x82d5c4)
"org-refile-get-targets" (0x82d6b0)
"setq" (0x82d924)
"let" (0x82daf4)
"org-refile-get-location" (0x82dbe0)
"save-excursion" (0x82de64)
"let" (0x82e034)
"or" (0x82e164)
"setq" (0x82e2b4)
"or" (0x82e3e4)
"if" (0x82e514)
"if" (0x82e674)
"let*" (0x82e804)
"if" (0x82e964)
"org-refile" (0x82eb44)
"call-interactively" (0x82ed0c)
"save-restriction" (0x82eec4)
"save-excursion" (0x82f024)
"save-current-buffer" (0x82f184)
"progn" (0x82f2b4)
"unwind-protect" (0x82f3e4)
"let" (0x82f5b4)
"let" (0x82f784)
"org-capture-refile" (0x82f944)
"call-interactively" (0x82fb54)
(gdb)
"progn" (0x82c474)
"if" (0x82c5a4)
"catch" (0x82c794)
"while" (0x82c904)
"save-restriction" (0x82ca64)
"save-excursion" (0x82cbc4)
"progn" (0x82ccf4)
"or" (0x82ce24)
"save-current-buffer" (0x82cf84)
"while" (0x82d0f4)
"while" (0x82d264)
"save-current-buffer" (0x82d3c4)
"let" (0x82d5c4)
"org-refile-get-targets" (0x82d6b0)
"setq" (0x82d924)
"let" (0x82daf4)
"org-refile-get-location" (0x82dbe0)
"save-excursion" (0x82de64)
"let" (0x82e034)
"or" (0x82e164)
"setq" (0x82e2b4)
"or" (0x82e3e4)
"if" (0x82e514)
"if" (0x82e674)
"let*" (0x82e804)
"if" (0x82e964)
"org-refile" (0x82eb44)
"call-interactively" (0x82ed0c)
"save-restriction" (0x82eec4)
"save-excursion" (0x82f024)
"save-current-buffer" (0x82f184)
"progn" (0x82f2b4)
"unwind-protect" (0x82f3e4)
"let" (0x82f5b4)
"let" (0x82f784)
"org-capture-refile" (0x82f944)
"call-interactively" (0x82fb54)
(gdb)

* Emacs Abord Dialog (24.2)

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 3928
[New Thread 3928.0x7d0]
[New Thread 3928.0x1180]
[New Thread 3928.0x141c]
[New Thread 3928.0x1414]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

Warning: /cygdrive/c/Program Files/Emacs-24.2/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x1154889: file w32fns.c, line 7200.
Temporary breakpoint 2 at 0x11449c9: file sysdep.c, line 819.

(gdb) continue

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

[Switching to Thread 3928.0x7d0]

0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) thread apply all backtrace

Thread 3 (Thread 3928.0x141c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000480 in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:
"format-time-string" (0x82cf8c)
"gnus-seconds-year" (0x82d1e0)
"eval" (0x82d458)
"byte-code" (0x82d6dc)
"gnus-user-date" (0x82daa0)
"format" (0x82dce4)
"insert" (0x82de04)
"progn" (0x82df34)
"gnus-add-text-properties" (0x82e034)
"let" (0x82e204)
"eval" (0x82e370)
"gnus-summary-prepare-threads" (0x82e6d8)
"gnus-summary-prepare" (0x82e9d8)
"gnus-summary-read-group-1" (0x82ecd8)
"gnus-summary-read-group" (0x82efe8)
"gnus-group-read-group" (0x82f2f8)
"gnus-group-select-group" (0x82f5e8)
"gnus-topic-select-group" (0x82f924)
"call-interactively" (0x82fb54)

Thread 2 (Thread 3928.0x1180):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x011490bd in w32_msg_pump (msg_buf=0x7236ff54) at w32fns.c:2263
#4 0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Lisp Backtrace:
"format-time-string" (0x82cf8c)
"gnus-seconds-year" (0x82d1e0)
"eval" (0x82d458)
"byte-code" (0x82d6dc)
"gnus-user-date" (0x82daa0)
"format" (0x82dce4)
"insert" (0x82de04)
"progn" (0x82df34)

---Type <return> to continue, or q <return> to quit---

"gnus-add-text-properties" (0x82e034)
"let" (0x82e204)
"eval" (0x82e370)
"gnus-summary-prepare-threads" (0x82e6d8)
"gnus-summary-prepare" (0x82e9d8)
"gnus-summary-read-group-1" (0x82ecd8)
"gnus-summary-read-group" (0x82efe8)
"gnus-group-read-group" (0x82f2f8)
"gnus-group-select-group" (0x82f5e8)
"gnus-topic-select-group" (0x82f924)
"call-interactively" (0x82fb54)

Thread 1 (Thread 3928.0x7d0):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x011548c0 in emacs_abort () at w32fns.c:7214
#2 0x01055503 in sys_kill (pid=3928, sig=22) at w32proc.c:1432
#3 0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647) at emacs.c:331
#4 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
line=1664) at alloc.c:6398
#5 0x010ac068 in compact_buffer (buffer=0x5695200) at buffer.c:1664
#6 0x0103fde2 in Fgarbage_collect () at alloc.c:5085
#7 0x0103997b in maybe_gc () at lisp.h:3637
#8 0x01036105 in Ffuncall (nargs=3, args=0x82cf88) at eval.c:2747
#9 0x010e0e77 in exec_byte_code (bytestr=67280609, vector=67239301, maxdepth=24, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#10 0x01037624 in funcall_lambda (fun=67239357, nargs=0, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#11 0x01036dfe in apply_lambda (fun=67239357, args=56346650) at eval.c:2905
#12 0x01034dd4 in eval_sub (form=79425814) at eval.c:2202
#13 0x010340a8 in Feval (form=79425814, lexical=56346650) at eval.c:2022
#14 0x0103670a in Ffuncall (nargs=2, args=0x82d454) at eval.c:2799
#15 0x010e0e77 in exec_byte_code (bytestr=71034417, vector=71022485, maxdepth=32, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#16 0x010e023e in Fbyte_code (bytestr=71034417, vector=71022485, maxdepth=32) at bytecode.c:474
#17 0x01034a57 in eval_sub (form=70955758) at eval.c:2163
#18 0x010325bd in internal_lisp_condition_case (var=56346650, bodyform=70955758, handlers=70955926) at eval.c:1262
#19 0x010e1ab4 in exec_byte_code (bytestr=71034369, vector=71022589, maxdepth=12, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:1095
#20 0x01037624 in funcall_lambda (fun=71022613, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#21 0x01036dfe in apply_lambda (fun=71022613, args=67929502) at eval.c:2905
#22 0x01034dd4 in eval_sub (form=67929486) at eval.c:2202
#23 0x01034733 in eval_sub (form=84414334) at eval.c:2121
#24 0x01034733 in eval_sub (form=84414350) at eval.c:2121
#25 0x0103087a in Fprogn (args=84414366) at eval.c:369
#26 0x0103453b in eval_sub (form=84414374) at eval.c:2105
#27 0x0103487a in eval_sub (form=84412438) at eval.c:2142
#28 0x0103087a in Fprogn (args=84411326) at eval.c:369
#29 0x01031cc1 in Flet (args=84409350) at eval.c:923

---Type <return> to continue, or q <return> to quit---

#30 0x0103453b in eval_sub (form=84409358) at eval.c:2105
#31 0x010340a8 in Feval (form=84409358, lexical=56346650) at eval.c:2022
#32 0x0103670a in Ffuncall (nargs=2, args=0x82e36c) at eval.c:2799
#33 0x010e0e77 in exec_byte_code (bytestr=71134625, vector=71117565, maxdepth=132, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#34 0x01037624 in funcall_lambda (fun=71118221, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#35 0x01036abd in Ffuncall (nargs=2, args=0x82e6d4) at eval.c:2845
#36 0x010e0e77 in exec_byte_code (bytestr=71038513, vector=71023373, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#37 0x01037624 in funcall_lambda (fun=71023453, nargs=0, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#38 0x01036abd in Ffuncall (nargs=1, args=0x82e9d4) at eval.c:2845
#39 0x010e0e77 in exec_byte_code (bytestr=71040785, vector=71022861, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#40 0x01037624 in funcall_lambda (fun=71023261, nargs=6, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#41 0x01036abd in Ffuncall (nargs=7, args=0x82ecd4) at eval.c:2845
#42 0x010e0e77 in exec_byte_code (bytestr=71040385, vector=71022757, maxdepth=32, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#43 0x01037624 in funcall_lambda (fun=71022829, nargs=7, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#44 0x01036abd in Ffuncall (nargs=8, args=0x82efe4) at eval.c:2845
#45 0x010e0e77 in exec_byte_code (bytestr=70285329, vector=70251517, maxdepth=36, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#46 0x01037624 in funcall_lambda (fun=70251629, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#47 0x01036abd in Ffuncall (nargs=3, args=0x82f2f4) at eval.c:2845
#48 0x010e0e77 in exec_byte_code (bytestr=70285777, vector=70251661, maxdepth=12, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#49 0x01037624 in funcall_lambda (fun=70251693, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#50 0x01036abd in Ffuncall (nargs=2, args=0x82f5e4) at eval.c:2845
#51 0x010e0e77 in exec_byte_code (bytestr=62647201, vector=78606245, maxdepth=8, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#52 0x01037624 in funcall_lambda (fun=74156789, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#53 0x01036abd in Ffuncall (nargs=2, args=0x82f920) at eval.c:2845
#54 0x010e6918 in Fcall_interactively (function=70102834, record_flag=56346650, keys=56368045) at callint.c:852
#55 0x0103677b in Ffuncall (nargs=4, args=0x82fb50) at eval.c:2803
#56 0x01035edb in call3 (fn=56457962, arg1=70102834, arg2=56346650, arg3=56346650) at eval.c:2621
#57 0x010207b2 in Fcommand_execute (cmd=70102834, record_flag=56346650, keys=56346650, special=56346650) at keyboard.c:10319
#58 0x010067de in command_loop_1 () at keyboard.c:1615
#59 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#60 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#61 0x010320bb in internal_catch (tag=56387090, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#62 0x0100567e in command_loop () at keyboard.c:1161
#63 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#64 0x01004f54 in Frecursive_edit () at keyboard.c:846
#65 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655

Lisp Backtrace:
"format-time-string" (0x82cf8c)

---Type <return> to continue, or q <return> to quit---

"gnus-seconds-year" (0x82d1e0)
"eval" (0x82d458)
"byte-code" (0x82d6dc)
"gnus-user-date" (0x82daa0)
"format" (0x82dce4)
"insert" (0x82de04)
"progn" (0x82df34)
"gnus-add-text-properties" (0x82e034)
"let" (0x82e204)
"eval" (0x82e370)
"gnus-summary-prepare-threads" (0x82e6d8)
"gnus-summary-prepare" (0x82e9d8)
"gnus-summary-read-group-1" (0x82ecd8)
"gnus-summary-read-group" (0x82efe8)
"gnus-group-read-group" (0x82f2f8)
"gnus-group-select-group" (0x82f5e8)
"gnus-topic-select-group" (0x82f924)
"call-interactively" (0x82fb54)
(gdb) xbacktrace
"format-time-string" (0x82cf8c)
"gnus-seconds-year" (0x82d1e0)
"eval" (0x82d458)
"byte-code" (0x82d6dc)
"gnus-user-date" (0x82daa0)
"format" (0x82dce4)
"insert" (0x82de04)
"progn" (0x82df34)
"gnus-add-text-properties" (0x82e034)
"let" (0x82e204)
"eval" (0x82e370)
"gnus-summary-prepare-threads" (0x82e6d8)
"gnus-summary-prepare" (0x82e9d8)
"gnus-summary-read-group-1" (0x82ecd8)
"gnus-summary-read-group" (0x82efe8)
"gnus-group-read-group" (0x82f2f8)
"gnus-group-select-group" (0x82f5e8)
"gnus-topic-select-group" (0x82f924)
"call-interactively" (0x82fb54)
(gdb)

HTH!

Best regards,
Fabrice

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

>> From: "Drew Adams" <drew....@oracle.com>
>> Cc: "'Eli Zaretskii'" <el...@gnu.org>,
>> "'Fabrice Niessen'" <f...@missioncriticalit.com>,
>> <12...@debbugs.gnu.org>
>> Date: Sun, 7 Oct 2012 10:48:16 -0700
>>

>> > Perhaps something in the build process, compiler version, compilation
>> > options...? It's hard to pinpoint any connection between both
>> > problems without backtraces, though.
>>
>> Admittedly, there is not much to go on. Hopefully there will be more reports,
>> with more useful information.
>
> If you, or others, can provide backtraces of these crashes, that would
> be a useful beginning.

Another crash... On Emacs 24.2 when editing a mail in Message mode:

$ gdb -p 5552

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 5552
[New Thread 5552.0xb8c]
[New Thread 5552.0x1108]
[New Thread 5552.0x171c]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.
Warning: /cygdrive/c/Program Files/Emacs-24.2/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x1154889: file w32fns.c, line 7200.
Temporary breakpoint 2 at 0x11449c9: file sysdep.c, line 819.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

[Switching to Thread 5552.0xb8c]

0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) thread apply all backtrace

Thread 2 (Thread 5552.0x1108):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x011490bd in w32_msg_pump (msg_buf=0x7236ff54) at w32fns.c:2263
#4 0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Lisp Backtrace:

"re-search-forward" (0x82ae48)
0x4048798 PVEC_COMPILED
"font-lock-fontify-keywords-region" (0x82b458)
"font-lock-default-fontify-region" (0x82b758)
"font-lock-fontify-region" (0x82bb9c)
"run-hook-with-args" (0x82bb98)
"byte-code" (0x82be0c)
"jit-lock-fontify-now" (0x82c298)
"jit-lock-function" (0x82c664)

Thread 1 (Thread 5552.0xb8c):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x011548c0 in emacs_abort () at w32fns.c:7214

#2 0x01055503 in sys_kill (pid=5552, sig=22) at w32proc.c:1432

#3 0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647) at emacs.c:331
#4 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
line=1664) at alloc.c:6398

#5 0x010ac068 in compact_buffer (buffer=0x3c43800) at buffer.c:1664

#6 0x0103fde2 in Fgarbage_collect () at alloc.c:5085
#7 0x0103997b in maybe_gc () at lisp.h:3637

#8 0x01036105 in Ffuncall (nargs=4, args=0x82ae44) at eval.c:2747
#9 0x010e0e77 in exec_byte_code (bytestr=62899649, vector=67405669, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#10 0x01037624 in funcall_lambda (fun=67405725, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#11 0x01036abd in Ffuncall (nargs=2, args=0x82b144) at eval.c:2845
#12 0x010e0e77 in exec_byte_code (bytestr=20885385, vector=20885637, maxdepth=36, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#13 0x01037624 in funcall_lambda (fun=20885357, nargs=3, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#14 0x01036abd in Ffuncall (nargs=4, args=0x82b454) at eval.c:2845
#15 0x010e0e77 in exec_byte_code (bytestr=20881041, vector=20881213, maxdepth=20, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#16 0x01037624 in funcall_lambda (fun=20880997, nargs=3, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#17 0x01036abd in Ffuncall (nargs=4, args=0x82b754) at eval.c:2845
#18 0x010e0e77 in exec_byte_code (bytestr=20879369, vector=20879421, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#19 0x01037624 in funcall_lambda (fun=20879309, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028

---Type <return> to continue, or q <return> to quit---

#20 0x01036abd in Ffuncall (nargs=3, args=0x82bb98) at eval.c:2845
#21 0x010358eb in funcall_nil (nargs=3, args=0x82bb98) at eval.c:2338
#22 0x01035d22 in run_hook_with_args (nargs=3, args=0x82bb98, funcall=0x10358d3 <funcall_nil>) at eval.c:2527
#23 0x01035962 in Frun_hook_with_args (nargs=3, args=0x82bb98) at eval.c:2388
#24 0x0103640c in Ffuncall (nargs=4, args=0x82bb94) at eval.c:2777
#25 0x010e0e77 in exec_byte_code (bytestr=20308769, vector=20895285, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#26 0x010e023e in Fbyte_code (bytestr=20308769, vector=20895285, maxdepth=16) at bytecode.c:474
#27 0x01034a57 in eval_sub (form=20895238) at eval.c:2163
#28 0x010325bd in internal_lisp_condition_case (var=58199066, bodyform=20895238, handlers=20895310) at eval.c:1262
#29 0x010e1ab4 in exec_byte_code (bytestr=20894849, vector=20895013, maxdepth=32, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:1095
#30 0x01037624 in funcall_lambda (fun=20894821, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#31 0x01036abd in Ffuncall (nargs=3, args=0x82c294) at eval.c:2845
#32 0x010e0e77 in exec_byte_code (bytestr=20894417, vector=20894541, maxdepth=40, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#33 0x01037624 in funcall_lambda (fun=20894389, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#34 0x01036abd in Ffuncall (nargs=2, args=0x82c660) at eval.c:2845
#35 0x01032973 in internal_condition_case_n (bfun=0x1036042 <Ffuncall>, nargs=2, args=0x82c660, handlers=56346674,
hfun=0x11e4053 <safe_eval_handler>) at eval.c:1432
#36 0x011e417e in safe_call (nargs=2, func=59487098) at xdisp.c:2457
#37 0x011e41bb in safe_call1 (fn=59487098, arg=2680) at xdisp.c:2473
#38 0x011e7472 in handle_fontified_prop (it=0x82d254) at xdisp.c:3646
#39 0x011e655e in handle_stop (it=0x82d254) at xdisp.c:3210
#40 0x011f54f4 in next_element_from_buffer (it=0x82d254) at xdisp.c:7903
#41 0x011f1041 in get_next_display_element (it=0x82d254) at xdisp.c:6568
#42 0x0121b432 in display_line (it=0x82d254) at xdisp.c:19382
#43 0x01211c15 in try_window (window=68976245, pos=..., flags=1) at xdisp.c:16285
#44 0x0120f741 in redisplay_window (window=68976245, just_this_one_p=0) at xdisp.c:15811
#45 0x01208e35 in redisplay_window_0 (window=68976245) at xdisp.c:13879
#46 0x01032787 in internal_condition_case_1 (bfun=0x1208dff <redisplay_window_0>, arg=68976245, handlers=56329326,
hfun=0x1208ddb <redisplay_window_error>) at eval.c:1346
#47 0x01208dc2 in redisplay_windows (window=68976245) at xdisp.c:13859
#48 0x012071cc in redisplay_internal () at xdisp.c:13439
#49 0x01203fe4 in redisplay () at xdisp.c:12648
#50 0x01008d3f in read_char (commandflag=1, nmaps=8, maps=0x82f980, prev_event=56346650, used_mouse_menu=0x82fa68, end_time=0x0)
at keyboard.c:2464
#51 0x0101ccb2 in read_key_sequence (keybuf=0x82fbf0, bufsize=30, prompt=56346650, dont_downcase_last=0,

can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9312

#52 0x01005f89 in command_loop_1 () at keyboard.c:1487
#53 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#54 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#55 0x010320bb in internal_catch (tag=56387090, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#56 0x0100567e in command_loop () at keyboard.c:1161
#57 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#58 0x01004f54 in Frecursive_edit () at keyboard.c:846

---Type <return> to continue, or q <return> to quit---

#59 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655

Lisp Backtrace:
"re-search-forward" (0x82ae48)
0x4048798 PVEC_COMPILED
"font-lock-fontify-keywords-region" (0x82b458)
"font-lock-default-fontify-region" (0x82b758)
"font-lock-fontify-region" (0x82bb9c)
"run-hook-with-args" (0x82bb98)
"byte-code" (0x82be0c)
"jit-lock-fontify-now" (0x82c298)
"jit-lock-function" (0x82c664)
(gdb) xbacktrace
"re-search-forward" (0x82ae48)
0x4048798 PVEC_COMPILED
"font-lock-fontify-keywords-region" (0x82b458)
"font-lock-default-fontify-region" (0x82b758)
"font-lock-fontify-region" (0x82bb9c)
"run-hook-with-args" (0x82bb98)
"byte-code" (0x82be0c)
"jit-lock-fontify-now" (0x82c298)
"jit-lock-function" (0x82c664)
(gdb)

Best regards,
Fabrice Niessen

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
> If you, or others, can provide backtraces of these crashes, that would
> be a useful beginning.

Backtrace from infinite loop in Emacs 24.1:

--8<---------------cut here---------------start------------->8---
$ gdb -p 5836

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 5836
[New Thread 5836.0x1668]
[New Thread 5836.0xc3c]
[New Thread 5836.0x1540]
[New Thread 5836.0x15ac]
[New Thread 5836.0x4e4]

Reading symbols from /cygdrive/c/Program Files/emacs-24.1/bin/emacs.exe...done.

Warning: /cygdrive/c/Program Files/Emacs-24.2/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color

.gdbinit:1217: Error in sourced command file:
No symbol "CHECK_LISP_OBJECT_TYPE" in current context.

(gdb) thread apply all backtrace

Thread 5 (Thread 5836.0x4e4):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x7161ffd0 in ?? ()

#6 0x00000000 in ?? ()

Lisp Backtrace:

(gdb) No symbol "CHECK_LISP_OBJECT_TYPE" in current context.


Thread 5 (Thread 5836.0x4e4):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x7161ffd0 in ?? ()

#6 0x00000000 in ?? ()

Lisp Backtrace:

(gdb) No symbol "CHECK_LISP_OBJECT_TYPE" in current context.
xbacktrace
No symbol "CHECK_LISP_OBJECT_TYPE" in current context.

(gdb) quit
A debugging session is active.

Inferior 1 [process 5836] will be detached.

Quit anyway? (y or n) y

Detaching from program: /cygdrive/c/Program Files/emacs-24.1/bin/emacs.exe, Pid 5836
--8<---------------cut here---------------end--------------->8---

Best regards,
Fabrice

[Eli Zaretskii]

> From: "Drew Adams" <drew....@oracle.com>
> Cc: <lek...@gmail.com>, <12...@debbugs.gnu.org>
> Date: Tue, 9 Oct 2012 09:02:28 -0700
>
> Another bit that might or might not help: the crashes I get seem to often occur
> when I hit C-g one or more times. Now maybe I did that because something seemed
> hung; dunno. I'll try to pay more attention and see if I can learn more.

Thanks, this is good information (although by itself it is not enough
to identify the root cause.

[Drew Adams]

Another bit that might or might not help: the crashes I get seem to often occur
when I hit C-g one or more times. Now maybe I did that because something seemed

hung; dunno. I'll try to pay more attention and see if I can learn more. (This
is with a build before Eli's fixes.)

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: Drew Adams <drew....@oracle.com>, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Tue, 09 Oct 2012 08:36:54 +0200

>
> Here some food... I hope/guess it will help a lot to pinpoint what's going
> wrong.

Thanks. We are not there yet.

> Note that I have the _impression_ that the problem lies, somehow, in packages
> I would load from my .emacs file (such as idle-require, auto-complete, helm,
> etc.). *NOT* that _they_ are wrong, but, when loaded, the problem would be
> (more) apparent.

helm is definitely involved, see below. Not sure it's the culprit,
though.

> #1 0x011548c0 in emacs_abort () at w32fns.c:7214

> #2 0x01055503 in sys_kill (pid=5624, sig=22) at w32proc.c:1432

> #3 0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647) at emacs.c:331
> #4 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
> line=1664) at alloc.c:6398

> #5 0x010ac068 in compact_buffer (buffer=0x3c44600) at buffer.c:1664

> #6 0x0103fde2 in Fgarbage_collect () at alloc.c:5085

This one we already saw. I think it's already fixed in the
development sources, so either try the next development snapshot or
wait for the pretest of v24.3.

> #0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

> #1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #4 0x00a41fbc in ?? ()

> #5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll
> #6 0x00000004 in ?? ()
> #7 0x00000008 in ?? ()
> #8 0x00000004 in ?? ()
> #9 0x04ae9e70 in ?? ()
> #10 0x0105fdc8 in sys_close (fd=4) at w32.c:5960
> #11 0x01145749 in emacs_close (fd=4) at sysdep.c:1851
> #12 0x0104b550 in deactivate_process (proc=78552693) at process.c:3929
> #13 0x0104457e in remove_process (proc=78552693) at process.c:746
> #14 0x010519b6 in status_notify (deleting_process=0x4ae9e70) at process.c:6673

> [...]

> Lisp Backtrace:
> "delete-process" (0x82a55c)
> "helm-kill-async-process" (0x82a74c)
> "mapc" (0x82a83c)
> "helm-kill-async-processes" (0x82a980)
> "helm-update" (0x82ab80)
> "if" (0x82adf4)
> "helm-check-new-input" (0x82aee0)

> [...]

> "funcall" (0x82ee50)
> "unwind-protect" (0x82f024)
> "helm-let-internal" (0x82f110)
> "if" (0x82f364)
> "helm" (0x82f450)
> "helm-other-buffer" (0x82f660)
> "helm-for-files" (0x82f944)
> "call-interactively" (0x82fb54)

This backtrace (and all the rest like it which you got by attaching to
an Emacs that appears "hung") is not helpful. All they say is that
helm, for whatever reason, tried to kill all asynchronous subprocesses
(any idea why would it want to do that?) as part of running the
command 'helm-for-files', and that this attempt to kill the processes
hung for some reason. But it doesn't show where Emacs is hung or
inflooping, because attaching to such a process catches it in some
random place. What is needed is information about where Emacs loops.
I guess it's time for another GDB lesson, this time copied from
etc/DEBUG:

If Emacs is in an infinite loop, try to determine where the loop
starts and ends. The easiest way to do this is to use the GDB command
`finish'. Each time you use it, Emacs resumes execution until it
exits one stack frame. Keep typing `finish' until it doesn't
return--that means the infinite loop is in the stack frame which you
just tried to finish.

Can you please do this, after attaching to Emacs, and report which
'finish' command doesn't return?

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: Drew Adams <drew....@oracle.com>, lek...@gmail.com, 12...@debbugs.gnu.org

> Date: Tue, 09 Oct 2012 09:11:54 +0200

>
> .gdbinit:1217: Error in sourced command file:
> No symbol "CHECK_LISP_OBJECT_TYPE" in current context.

You are using .gdbinit file from the wrong Emacs version, so you will
get no useful backtraces.

[Drew Adams]

> helm is definitely involved, see below. Not sure it's the culprit,
> though.

Just FWIW - my crashes might not be related, since I do not use Helm (I use
Icicles).

HTH.

[Eli Zaretskii]

> From: "Drew Adams" <drew....@oracle.com>
> Cc: <lek...@gmail.com>, <12...@debbugs.gnu.org>

> Date: Tue, 9 Oct 2012 10:26:56 -0700

Yes, I realize that. But I'm not yet sure Helm is the root cause,
either.

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

Yes, I don't have any .gdbinit file in the Emacs-24.1 I have.

Useless, then. OK, understood!

BTW, I now have the impression that:

- Emacs 24.1 hangs
- Emacs 24.2 crashes

and never (???) the other way around.

To be confirmed...

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>> Cc: Drew Adams <drew....@oracle.com>, lek...@gmail.com, 12...@debbugs.gnu.org

>> Date: Tue, 09 Oct 2012 08:36:54 +0200
>>
>> Here some food... I hope/guess it will help a lot to pinpoint what's going
>> wrong.
>
> Thanks. We are not there yet.

Thanks for your precious help, anyway.

>> Note that I have the _impression_ that the problem lies, somehow, in packages
>> I would load from my .emacs file (such as idle-require, auto-complete, helm,
>> etc.). *NOT* that _they_ are wrong, but, when loaded, the problem would be
>> (more) apparent.
>

> helm is definitely involved, see below. Not sure it's the culprit,
> though.

OK.

>> #1 0x011548c0 in emacs_abort () at w32fns.c:7214
>> #2 0x01055503 in sys_kill (pid=5624, sig=22) at w32proc.c:1432
>> #3 0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647)
>> at emacs.c:331
>> #4 0x010431b7 in die (msg=0x1537030 "assertion failed:
>> buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
>> line=1664) at alloc.c:6398
>> #5 0x010ac068 in compact_buffer (buffer=0x3c44600) at buffer.c:1664
>> #6 0x0103fde2 in Fgarbage_collect () at alloc.c:5085
>
> This one we already saw. I think it's already fixed in the
> development sources, so either try the next development snapshot or
> wait for the pretest of v24.3.

There is no new development snapshot on
http://alpha.gnu.org/gnu/emacs/windows/.

The same applies for a pretest version: nothing new since August on
http://alpha.gnu.org/gnu/emacs/pretest/windows/.

Still a bit of patience?

Sometimes (once a day, I'd say), I get errors from (Cygwin's) Bash, when
Helm-for-files is running: I get a popup, click OK, and then Helm goes on.

Maybe the crashes happen when I don't get such a popup, but some process is
still crashed, letting Emacs with no response?

> But it doesn't show where Emacs is hung or inflooping, because attaching to
> such a process catches it in some random place. What is needed is
> information about where Emacs loops. I guess it's time for another GDB
> lesson, this time copied from etc/DEBUG:
>
> If Emacs is in an infinite loop, try to determine where the loop
> starts and ends. The easiest way to do this is to use the GDB command
> `finish'. Each time you use it, Emacs resumes execution until it
> exits one stack frame. Keep typing `finish' until it doesn't
> return--that means the infinite loop is in the stack frame which you
> just tried to finish.
>
> Can you please do this, after attaching to Emacs, and report which
> 'finish' command doesn't return?

For sure, I'll do. Wait. Except that I don't have a .gdbinit file for Emacs
24.1, and that I've the impression that only Emacs 24.1 does hang from time to
time.

Should I take a snapshot from Emacs 24.1 on
http://alpha.gnu.org/gnu/emacs/windows/? If yes, which one can I take: there
is no version indicated there... How can I know which file is a snapshot of
24.1?

Another question: before typing finish, do I do the other sequence as well:

- (continue),
- thread apply all backtrace, and
- xbacktrace?

Thanks for doing me learn along this painful process!

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Tue, 09 Oct 2012 21:46:28 +0200

>
> > This one we already saw. I think it's already fixed in the
> > development sources, so either try the next development snapshot or
> > wait for the pretest of v24.3.
>
> There is no new development snapshot on
> http://alpha.gnu.org/gnu/emacs/windows/.
>
> The same applies for a pretest version: nothing new since August on
> http://alpha.gnu.org/gnu/emacs/pretest/windows/.
>
> Still a bit of patience?

Yes, I meant the future snapshots.

> Sometimes (once a day, I'd say), I get errors from (Cygwin's) Bash, when
> Helm-for-files is running: I get a popup, click OK, and then Helm goes on.

What does the error message say?

> Except that I don't have a .gdbinit file for Emacs 24.1, and that
> I've the impression that only Emacs 24.1 does hang from time to
> time.

That's not necessarily a problem. Not having a .gdbinit just means
you won't be able to use the Emacs-specific commands it defines. For
doing the trick with 'finish' in order to find where Emacs loops, this
is not an issue. Having a wrong .gdbinit file where you start GDB
_is_ a problem. So only use .gdbinit with the Emacs version it
matches.

> Should I take a snapshot from Emacs 24.1 on
> http://alpha.gnu.org/gnu/emacs/windows/? If yes, which one can I take: there
> is no version indicated there... How can I know which file is a snapshot of
> 24.1?

24.1 is the official release, so you don't need any snapshots of it.
If you want to get its .gdbinit file, download the source distribution
from ftp.gnu.org, and look in the src directory there.

> Another question: before typing finish, do I do the other sequence as well:
>
> - (continue),
> - thread apply all backtrace, and
> - xbacktrace?

For an Emacs that is hung, no 'continue'. And 'xbacktrace' will only
work if you have a .gdbinit for that version of Emacs.

Also, before you start with 'finish', you need to switch to the main
thread. This is usually thread 1, so you type

(gdb) thread 1

and then start the 'finish' dance.

To make sure thread 1 is the main thread, verify that "thread apply
all backtrace" ends with the 'main' function for thread 1, like this:

> Thread 1 (Thread 5552.0xb8c):

> #0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

> [...]

> #58 0x01004f54 in Frecursive_edit () at keyboard.c:846

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
>> Sometimes (once a day, I'd say), I get errors from (Cygwin's) Bash, when
>> Helm-for-files is running: I get a popup, click OK, and then Helm goes on.
>
> What does the error message say?

I'll copy it, when it occurs next time.

>> Except that I don't have a .gdbinit file for Emacs 24.1, and that
>> I've the impression that only Emacs 24.1 does hang from time to
>> time.
>
> That's not necessarily a problem. Not having a .gdbinit just means
> you won't be able to use the Emacs-specific commands it defines. For
> doing the trick with 'finish' in order to find where Emacs loops, this
> is not an issue. Having a wrong .gdbinit file where you start GDB
> _is_ a problem. So only use .gdbinit with the Emacs version it
> matches.

Thanks for hte info.

>> Should I take a snapshot from Emacs 24.1 on
>> http://alpha.gnu.org/gnu/emacs/windows/? If yes, which one can I take: there
>> is no version indicated there... How can I know which file is a snapshot of
>> 24.1?
>
> 24.1 is the official release, so you don't need any snapshots of it.
> If you want to get its .gdbinit file, download the source distribution
> from ftp.gnu.org, and look in the src directory there.

I'll try it tomorrow.

>> Another question: before typing finish, do I do the other sequence as well:
>>
>> - (continue),
>> - thread apply all backtrace, and
>> - xbacktrace?
>
> For an Emacs that is hung, no 'continue'. And 'xbacktrace' will only
> work if you have a .gdbinit for that version of Emacs.
>
> Also, before you start with 'finish', you need to switch to the main
> thread. This is usually thread 1, so you type
>
> (gdb) thread 1
>
> and then start the 'finish' dance.
>
> To make sure thread 1 is the main thread, verify that "thread apply
> all backtrace" ends with the 'main' function for thread 1, like this:

Useful info!

>> Thread 1 (Thread 5552.0xb8c):
>> #0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> [...]
>> #58 0x01004f54 in Frecursive_edit () at keyboard.c:846
>> #59 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655

My turn to give you something more. Just had 2 new crashes within Emacs 24.2
in just 5 minutes.

Here the backtraces:

--8<---------------cut here---------------start------------->8---
$ gdb -p 7300

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 7300
[New Thread 7300.0x19ac]
[New Thread 7300.0x26f8]
[New Thread 7300.0x1088]
[New Thread 7300.0x1fc4]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

Warning: /cygdrive/c/Program Files/Emacs-24.2/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color

Breakpoint 1 at 0x1154889: file w32fns.c, line 7200.
Temporary breakpoint 2 at 0x11449c9: file sysdep.c, line 819.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

[Switching to Thread 7300.0x19ac]

0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) thread apply all backtrace

Thread 3 (Thread 7300.0x1088):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x0000066c in ?? ()
#4 0x00000000 in ?? ()

Lisp Backtrace:
"eval" (0x82c104)
"redisplay" (0x82ea28)
"sit-for" (0x82ed28)
"isearch-lazy-highlight-new-loop" (0x82f028)
"isearch-update" (0x82f328)
"isearch-repeat" (0x82f628)
"isearch-repeat-forward" (0x82f944)
"call-interactively" (0x82fb54)

Thread 2 (Thread 7300.0x26f8):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x011490bd in w32_msg_pump (msg_buf=0x7236ff54) at w32fns.c:2263
#4 0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#6 0x00000000 in ?? ()

Lisp Backtrace:

"eval" (0x82c104)
"redisplay" (0x82ea28)
"sit-for" (0x82ed28)
"isearch-lazy-highlight-new-loop" (0x82f028)
"isearch-update" (0x82f328)
"isearch-repeat" (0x82f628)
"isearch-repeat-forward" (0x82f944)
"call-interactively" (0x82fb54)

Thread 1 (Thread 7300.0x19ac):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x011548c0 in emacs_abort () at w32fns.c:7214

#2 0x01055503 in sys_kill (pid=7300, sig=22) at w32proc.c:1432

#3 0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647) at emacs.c:331
#4 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
line=1664) at alloc.c:6398

#5 0x010ac068 in compact_buffer (buffer=0x5868c00) at buffer.c:1664

#6 0x0103fde2 in Fgarbage_collect () at alloc.c:5085

#7 0x0103997b in maybe_gc () at lisp.h:3637

---Type <return> to continue, or q <return> to quit---

#8 0x01036105 in Ffuncall (nargs=2, args=0x82c100) at eval.c:2747
#9 0x01032973 in internal_condition_case_n (bfun=0x1036042 <Ffuncall>, nargs=2, args=0x82c100, handlers=56346674,

hfun=0x11e4053 <safe_eval_handler>) at eval.c:1432

#10 0x011e417e in safe_call (nargs=2, func=56449818) at xdisp.c:2457
#11 0x011e41bb in safe_call1 (fn=56449818, arg=58027374) at xdisp.c:2473
#12 0x011e41d7 in safe_eval (sexpr=58027374) at xdisp.c:2481
#13 0x01220a3b in display_mode_element (it=0x82c358, depth=3, field_width=0, precision=0, elt=58027382, props=56346650, risky=0)
at xdisp.c:20752
#14 0x01220f7c in display_mode_element (it=0x82c358, depth=1, field_width=0, precision=0, elt=88751782, props=56346650, risky=0)
at xdisp.c:20833
#15 0x0121f8d5 in display_mode_line (w=0x67bf790, face_id=MODE_LINE_FACE_ID, format=88751790) at xdisp.c:20350
#16 0x0121f5ad in display_mode_lines (w=0x67bf790) at xdisp.c:20292
#17 0x01210f08 in redisplay_window (window=108787605, just_this_one_p=0) at xdisp.c:16127
#18 0x01208e35 in redisplay_window_0 (window=108787605) at xdisp.c:13879
#19 0x01032787 in internal_condition_case_1 (bfun=0x1208dff <redisplay_window_0>, arg=108787605, handlers=56329326,

hfun=0x1208ddb <redisplay_window_error>) at eval.c:1346

#20 0x01208dc2 in redisplay_windows (window=108787605) at xdisp.c:13859
#21 0x01208d0d in redisplay_windows (window=108787317) at xdisp.c:13851
#22 0x012071cc in redisplay_internal () at xdisp.c:13439
#23 0x012082da in redisplay_preserve_echo_area (from_where=2) at xdisp.c:13695
#24 0x010fbce0 in Fredisplay (force=56346650) at dispnew.c:6006
#25 0x010366a2 in Ffuncall (nargs=1, args=0x82ea24) at eval.c:2796
#26 0x010e0e77 in exec_byte_code (bytestr=20121401, vector=20121493, maxdepth=20, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#27 0x01037624 in funcall_lambda (fun=20121341, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#28 0x01036abd in Ffuncall (nargs=2, args=0x82ed24) at eval.c:2845
#29 0x010e0e77 in exec_byte_code (bytestr=20971105, vector=20971293, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#30 0x01037624 in funcall_lambda (fun=20971077, nargs=0, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#31 0x01036abd in Ffuncall (nargs=1, args=0x82f024) at eval.c:2845
#32 0x010e0e77 in exec_byte_code (bytestr=20944657, vector=20944837, maxdepth=20, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#33 0x01037624 in funcall_lambda (fun=20944629, nargs=0, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#34 0x01036abd in Ffuncall (nargs=1, args=0x82f324) at eval.c:2845
#35 0x010e0e77 in exec_byte_code (bytestr=20951329, vector=20951477, maxdepth=16, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#36 0x01037624 in funcall_lambda (fun=20951309, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#37 0x01036abd in Ffuncall (nargs=2, args=0x82f624) at eval.c:2845
#38 0x010e0e77 in exec_byte_code (bytestr=20155913, vector=20951701, maxdepth=8, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#39 0x01037624 in funcall_lambda (fun=20951653, nargs=0, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#40 0x01036abd in Ffuncall (nargs=1, args=0x82f940) at eval.c:2845
#41 0x01035dd8 in apply1 (fn=58996882, arg=56346650) at eval.c:2557
#42 0x010e4bed in Fcall_interactively (function=58996882, record_flag=56346650, keys=56368045) at callint.c:377
#43 0x0103677b in Ffuncall (nargs=4, args=0x82fb50) at eval.c:2803
#44 0x01035edb in call3 (fn=56457962, arg1=58996882, arg2=56346650, arg3=56346650) at eval.c:2621
#45 0x010207b2 in Fcommand_execute (cmd=58996882, record_flag=56346650, keys=56346650, special=56346650) at keyboard.c:10319

---Type <return> to continue, or q <return> to quit---

#46 0x010067de in command_loop_1 () at keyboard.c:1615
#47 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#48 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#49 0x010320bb in internal_catch (tag=56387090, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#50 0x0100567e in command_loop () at keyboard.c:1161
#51 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#52 0x01004f54 in Frecursive_edit () at keyboard.c:846
#53 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655

Lisp Backtrace:
"eval" (0x82c104)
"redisplay" (0x82ea28)
"sit-for" (0x82ed28)
"isearch-lazy-highlight-new-loop" (0x82f028)
"isearch-update" (0x82f328)
"isearch-repeat" (0x82f628)
"isearch-repeat-forward" (0x82f944)

"call-interactively" (0x82fb54)
(gdb)
(gdb) xbacktrace

"eval" (0x82c104)
"redisplay" (0x82ea28)
"sit-for" (0x82ed28)
"isearch-lazy-highlight-new-loop" (0x82f028)
"isearch-update" (0x82f328)
"isearch-repeat" (0x82f628)
"isearch-repeat-forward" (0x82f944)
"call-interactively" (0x82fb54)
(gdb)
"eval" (0x82c104)
"redisplay" (0x82ea28)
"sit-for" (0x82ed28)
"isearch-lazy-highlight-new-loop" (0x82f028)
"isearch-update" (0x82f328)
"isearch-repeat" (0x82f628)
"isearch-repeat-forward" (0x82f944)
"call-interactively" (0x82fb54)

(gdb) quit
A debugging session is active.

Inferior 1 [process 7300] will be detached.

Quit anyway? (y or n) y

error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1392 was 31
error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1273 was 31
error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1273 was 31

Quitting: Can't detach process 7300 (error 5)
--8<---------------cut here---------------end--------------->8---

and

--8<---------------cut here---------------start------------->8---
$ gdb -p 9840

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 9840
[New Thread 9840.0x2554]
[New Thread 9840.0x1f38]
[New Thread 9840.0x1a34]
[New Thread 9840.0x20d0]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

Warning: /cygdrive/c/Program Files/Emacs-24.2/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color

Breakpoint 1 at 0x1154889: file w32fns.c, line 7200.
Temporary breakpoint 2 at 0x11449c9: file sysdep.c, line 819.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

[Switching to Thread 9840.0x2554]

0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) thread apply all backtrace

Thread 3 (Thread 9840.0x1a34):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000610 in ?? ()
#4 0x00000000 in ?? ()

Lisp Backtrace:
"nnimap-parse-line" (0x82d4c8)
"nnimap-parse-response" (0x82d7c8)
"nnimap-get-response" (0x82dab8)
"nnimap-command" (0x82ddc8)
"nnimap-possibly-change-group" (0x82e0c8)
"nnimap-request-group" (0x82e3d8)
"gnus-request-group" (0x82e6d8)
"gnus-select-newsgroup" (0x82e9d8)

"gnus-summary-read-group-1" (0x82ecd8)
"gnus-summary-read-group" (0x82efe8)
"gnus-group-read-group" (0x82f2f8)
"gnus-group-select-group" (0x82f5e8)
"gnus-topic-select-group" (0x82f924)
"call-interactively" (0x82fb54)

Thread 2 (Thread 9840.0x1f38):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x011490bd in w32_msg_pump (msg_buf=0x7236ff54) at w32fns.c:2263
#4 0x011492fb in w32_msg_worker@4 (arg=0x0) at w32fns.c:2485
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#6 0x00000000 in ?? ()

Lisp Backtrace:

"nnimap-parse-line" (0x82d4c8)
"nnimap-parse-response" (0x82d7c8)
"nnimap-get-response" (0x82dab8)
"nnimap-command" (0x82ddc8)
"nnimap-possibly-change-group" (0x82e0c8)
"nnimap-request-group" (0x82e3d8)
"gnus-request-group" (0x82e6d8)
"gnus-select-newsgroup" (0x82e9d8)

"gnus-summary-read-group-1" (0x82ecd8)
"gnus-summary-read-group" (0x82efe8)
"gnus-group-read-group" (0x82f2f8)
"gnus-group-select-group" (0x82f5e8)
"gnus-topic-select-group" (0x82f924)

---Type <return> to continue, or q <return> to quit---

"call-interactively" (0x82fb54)

Thread 1 (Thread 9840.0x2554):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x011548c0 in emacs_abort () at w32fns.c:7214

#2 0x01055503 in sys_kill (pid=9840, sig=22) at w32proc.c:1432

#3 0x010014fc in fatal_error_backtrace (sig=22, backtrace_limit=2147483647) at emacs.c:331
#4 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
line=1664) at alloc.c:6398

#5 0x010ac068 in compact_buffer (buffer=0x44cec00) at buffer.c:1664

#6 0x0103fde2 in Fgarbage_collect () at alloc.c:5085

#7 0x0103997b in maybe_gc () at lisp.h:3637

#8 0x010e0f83 in exec_byte_code (bytestr=66924881, vector=70166269, maxdepth=24, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:934
#9 0x01037624 in funcall_lambda (fun=70166373, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#10 0x01036abd in Ffuncall (nargs=2, args=0x82d4c4) at eval.c:2845
#11 0x010e0e77 in exec_byte_code (bytestr=66925281, vector=70166173, maxdepth=20, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#12 0x01037624 in funcall_lambda (fun=70166221, nargs=0, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#13 0x01036abd in Ffuncall (nargs=1, args=0x82d7c4) at eval.c:2845
#14 0x010e0e77 in exec_byte_code (bytestr=66907409, vector=70165765, maxdepth=8, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#15 0x01037624 in funcall_lambda (fun=70165789, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#16 0x01036abd in Ffuncall (nargs=2, args=0x82dab4) at eval.c:2845
#17 0x010e0e77 in exec_byte_code (bytestr=66907889, vector=70165661, maxdepth=32, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#18 0x01037624 in funcall_lambda (fun=70165741, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#19 0x01036abd in Ffuncall (nargs=3, args=0x82ddc4) at eval.c:2845
#20 0x010e0e77 in exec_byte_code (bytestr=66897329, vector=70165189, maxdepth=24, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#21 0x01037624 in funcall_lambda (fun=70165293, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#22 0x01036abd in Ffuncall (nargs=3, args=0x82e0c4) at eval.c:2845
#23 0x010e0e77 in exec_byte_code (bytestr=64247073, vector=70114773, maxdepth=32, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#24 0x01037624 in funcall_lambda (fun=70114965, nargs=4, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#25 0x01036abd in Ffuncall (nargs=5, args=0x82e3d4) at eval.c:2845
#26 0x010e0e77 in exec_byte_code (bytestr=63507569, vector=64322693, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#27 0x01037624 in funcall_lambda (fun=64323069, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#28 0x01036abd in Ffuncall (nargs=3, args=0x82e6d4) at eval.c:2845
#29 0x010e0e77 in exec_byte_code (bytestr=63105809, vector=65465533, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#30 0x01037624 in funcall_lambda (fun=65465981, nargs=3, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#31 0x01036abd in Ffuncall (nargs=4, args=0x82e9d4) at eval.c:2845
#32 0x010e0e77 in exec_byte_code (bytestr=62726577, vector=65386005, maxdepth=28, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#33 0x01037624 in funcall_lambda (fun=65386405, nargs=6, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028

---Type <return> to continue, or q <return> to quit---

#34 0x01036abd in Ffuncall (nargs=7, args=0x82ecd4) at eval.c:2845
#35 0x010e0e77 in exec_byte_code (bytestr=62711969, vector=65385901, maxdepth=32, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#36 0x01037624 in funcall_lambda (fun=65385973, nargs=7, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#37 0x01036abd in Ffuncall (nargs=8, args=0x82efe4) at eval.c:2845
#38 0x010e0e77 in exec_byte_code (bytestr=62625489, vector=66507189, maxdepth=36, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#39 0x01037624 in funcall_lambda (fun=66507301, nargs=2, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#40 0x01036abd in Ffuncall (nargs=3, args=0x82f2f4) at eval.c:2845
#41 0x010e0e77 in exec_byte_code (bytestr=62624817, vector=66507333, maxdepth=12, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#42 0x01037624 in funcall_lambda (fun=66507365, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#43 0x01036abd in Ffuncall (nargs=2, args=0x82f5e4) at eval.c:2845
#44 0x010e0e77 in exec_byte_code (bytestr=72077585, vector=72062109, maxdepth=8, args_template=56346650, nargs=0, args=0x0)
at bytecode.c:899
#45 0x01037624 in funcall_lambda (fun=72062157, nargs=1, arg_vector=0x35bc81a <__register_frame_info+56346650>) at eval.c:3028
#46 0x01036abd in Ffuncall (nargs=2, args=0x82f920) at eval.c:2845
#47 0x010e6918 in Fcall_interactively (function=65493042, record_flag=56346650, keys=56368045) at callint.c:852
#48 0x0103677b in Ffuncall (nargs=4, args=0x82fb50) at eval.c:2803
#49 0x01035edb in call3 (fn=56457962, arg1=65493042, arg2=56346650, arg3=56346650) at eval.c:2621
#50 0x010207b2 in Fcommand_execute (cmd=65493042, record_flag=56346650, keys=56346650, special=56346650) at keyboard.c:10319
#51 0x010067de in command_loop_1 () at keyboard.c:1615
#52 0x0103269f in internal_condition_case (bfun=0x1005a97 <command_loop_1>, handlers=56397234, hfun=0x100526a <cmd_error>)
at eval.c:1308
#53 0x010056c4 in command_loop_2 (ignore=56346650) at keyboard.c:1182
#54 0x010320bb in internal_catch (tag=56387090, func=0x10056a0 <command_loop_2>, arg=56346650) at eval.c:1069
#55 0x0100567e in command_loop () at keyboard.c:1161
#56 0x01004c27 in recursive_edit_1 () at keyboard.c:782
#57 0x01004f54 in Frecursive_edit () at keyboard.c:846
#58 0x01002b68 in main (argc=1, argv=0xa43e18) at emacs.c:1655

Lisp Backtrace:
"nnimap-parse-line" (0x82d4c8)
"nnimap-parse-response" (0x82d7c8)
"nnimap-get-response" (0x82dab8)
"nnimap-command" (0x82ddc8)
"nnimap-possibly-change-group" (0x82e0c8)
"nnimap-request-group" (0x82e3d8)
"gnus-request-group" (0x82e6d8)
"gnus-select-newsgroup" (0x82e9d8)

"gnus-summary-read-group-1" (0x82ecd8)
"gnus-summary-read-group" (0x82efe8)
"gnus-group-read-group" (0x82f2f8)
"gnus-group-select-group" (0x82f5e8)
"gnus-topic-select-group" (0x82f924)
"call-interactively" (0x82fb54)
(gdb)

(gdb) xbacktrace
"nnimap-parse-line" (0x82d4c8)
"nnimap-parse-response" (0x82d7c8)
"nnimap-get-response" (0x82dab8)
"nnimap-command" (0x82ddc8)
"nnimap-possibly-change-group" (0x82e0c8)
"nnimap-request-group" (0x82e3d8)
"gnus-request-group" (0x82e6d8)
"gnus-select-newsgroup" (0x82e9d8)

"gnus-summary-read-group-1" (0x82ecd8)
"gnus-summary-read-group" (0x82efe8)
"gnus-group-read-group" (0x82f2f8)
"gnus-group-select-group" (0x82f5e8)
"gnus-topic-select-group" (0x82f924)
"call-interactively" (0x82fb54)
(gdb)

--8<---------------cut here---------------end--------------->8---

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com
> Date: Tue, 09 Oct 2012 23:43:42 +0200

>
> My turn to give you something more. Just had 2 new crashes within Emacs 24.2
> in just 5 minutes.
>
> Here the backtraces:

They are all of the same kind we saw before:

#4 0x010431b7 in die (msg=0x1537030 "assertion failed: buffer->base_buffer->indirections > 0", file=0x1535810 "buffer.c",
line=1664) at alloc.c:6398
#5 0x010ac068 in compact_buffer (buffer=0x5868c00) at buffer.c:1664
#6 0x0103fde2 in Fgarbage_collect () at alloc.c:5085

I think we have enough of this evidence. When the next snapshot or
pretest comes out, please try that, I think this problem is already
fixed.

I think the only other interesting case is the hangs you experience,
so let's concentrate on that.

Thanks.

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

> I think we have enough of this evidence. When the next snapshot or pretest
> comes out, please try that, I think this problem is already fixed.

I just downloaded a version from 13 hours ago from
https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8

I'll run Emacs 24.2 from now on until the next crash occurs.

> I think the only other interesting case is the hangs you experience, so
> let's concentrate on that.

When the next crash of Emacs 24.2 occurs (I should say "if"), I'll go back to
Emacs 24.1 and wait for infinite loops (or message with Bash problems).

[Fabrice Niessen]

Eli,

"Fabrice Niessen" wrote:
> Eli Zaretskii wrote:
>> I think we have enough of this evidence. When the next snapshot or pretest
>> comes out, please try that, I think this problem is already fixed.
>
> I just downloaded a version from 13 hours ago from
> https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8

I've also disabled the bidirectional reordering of text for display in the
visual order:

(setq-default bidi-display-reordering nil)

It was previously set'ed to nil in Org-mode buffers only.

> I'll run Emacs 24.2 from now on until the next crash occurs.

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

>> Sometimes (once a day, I'd say), I get errors from (Cygwin's) Bash, when
>> Helm-for-files is running: I get a popup, click OK, and then Helm goes on.
>
> What does the error message say?

The (translated) title of the dialog box is: "Windows Cannot End This
Program". And the program is "Bash".

I can (try to) give you a screenshot, if you need so. But I have it only in
French.

[Stefan Monnier]

> I've also disabled the bidirectional reordering of text for display in the
> visual order:

> (setq-default bidi-display-reorderingq nil)

> It was previously set'ed to nil in Org-mode buffers only.

Better not: it's only a debugging option to track down bidi problems,
but nothing in your descriptions hints at a bidi-related problem.


Stefan

[Fabrice Niessen]

Hello Stefan,

OK. Thanks for mentioning it.

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
> I think the only other interesting case is the hangs you experience,
> so let's concentrate on that.

Got it!

* Infinite loop in Emacs 24.2 (from 19 hours ago, found on
https://www.dropbox.com/sh/7jr3vbv9tm1zod0/QEm5VwvAPx/emacs-trunk-r110489-w32-i386.zip)
[2012-10-10 Wed 15:35]

Don't remember what I was doing...

$ gdb -p 6176

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 6176
[New Thread 6176.0x272c]
[New Thread 6176.0x2090]
[New Thread 6176.0x275c]
[New Thread 6176.0x1e90]
[New Thread 6176.0x1bb8]
[New Thread 6176.0x1fc0]
[New Thread 6176.0x1e04]
[New Thread 6176.0x2030]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

(gdb) thread apply all backtrace

Thread 8 (Thread 6176.0x2030):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x5afdffd0 in ?? ()

#6 0x00000000 in ?? ()

Thread 7 (Thread 6176.0x1e04):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x0000049c in ?? ()

#4 0x00000000 in ?? ()

Thread 6 (Thread 6176.0x1fc0):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
#5 0x0108d770 in _sys_read_ahead (fd=7) at w32.c:6073
#6 0x010330e7 in reader_thread (arg=0x1665d48) at w32proc.c:839
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 5 (Thread 6176.0x1bb8):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000654 in ?? ()

#4 0x00000000 in ?? ()

Thread 4 (Thread 6176.0x1e90):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000006a4 in ?? ()

#4 0x00000000 in ?? ()

Thread 3 (Thread 6176.0x275c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll

#3 0x0114843c in w32_msg_pump (msg_buf=0x5b8cff54) at w32fns.c:2373

---Type <return> to continue, or q <return> to quit---

#4 0x0114867a in w32_msg_worker@4 (arg=0x0) at w32fns.c:2599

#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Thread 2 (Thread 6176.0x2090):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d21a in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8023f1 in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x00000000 in ?? ()

Thread 1 (Thread 6176.0x272c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#4 0x00a41fe0 in ?? ()

#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll

#6 0x00000005 in ?? ()
#7 0x0000000a in ?? ()
#8 0x00000005 in ?? ()
#9 0x047afe70 in ?? ()
#10 0x0108d269 in sys_close (fd=5) at w32.c:5912
#11 0x01144d9c in emacs_close (fd=5) at sysdep.c:2082
#12 0x01029cd3 in deactivate_process (proc=75169397) at process.c:3936
#13 0x01022d72 in remove_process (proc=75169397) at process.c:747
#14 0x0102ffbf in status_notify (deleting_process=0x47afe70) at process.c:6618
#15 0x01023243 in Fdelete_process (process=75169397) at process.c:862
#16 0x01013148 in eval_sub (form=60697438) at eval.c:2137
#17 0x0100f0aa in Fprogn (args=60535502) at eval.c:359
#18 0x01015cc5 in funcall_lambda (fun=60535430, nargs=1, arg_vector=0x829f4c) at eval.c:2997
#19 0x01015365 in Ffuncall (nargs=2, args=0x829f48) at eval.c:2833
#20 0x01014635 in call1 (fn=60858258, arg1=75169397) at eval.c:2566
#21 0x01070668 in mapcar1 (leni=1, vals=0x0, fn=60858258, seq=98139750) at fns.c:2312
#22 0x01070b53 in Fmapc (function=60858258, sequence=98139750) at fns.c:2401
#23 0x010131b5 in eval_sub (form=64888382) at eval.c:2140
#24 0x0100f0aa in Fprogn (args=64888590) at eval.c:359
#25 0x01015cc5 in funcall_lambda (fun=64888646, nargs=0, arg_vector=0x82a180) at eval.c:2997
#26 0x010155d4 in apply_lambda (fun=64888646, args=56846362) at eval.c:2881
#27 0x0101372f in eval_sub (form=64829694) at eval.c:2212
#28 0x0100f0aa in Fprogn (args=64827774) at eval.c:359
#29 0x01015cc5 in funcall_lambda (fun=64827742, nargs=0, arg_vector=0x82a380) at eval.c:2997
#30 0x010155d4 in apply_lambda (fun=64827742, args=56846362) at eval.c:2881
#31 0x0101372f in eval_sub (form=64762502) at eval.c:2212
#32 0x0100f0aa in Fprogn (args=64762742) at eval.c:359
#33 0x0100ef2e in Fif (args=64760926) at eval.c:310
#34 0x01012d10 in eval_sub (form=64760918) at eval.c:2085
#35 0x0100f0aa in Fprogn (args=64761062) at eval.c:359

---Type <return> to continue, or q <return> to quit---

#36 0x01015cc5 in funcall_lambda (fun=64761038, nargs=1, arg_vector=0x82a6e0) at eval.c:2997
#37 0x010155d4 in apply_lambda (fun=64761038, args=64763542) at eval.c:2881
#38 0x0101372f in eval_sub (form=64763526) at eval.c:2212
#39 0x0100f0aa in Fprogn (args=64761862) at eval.c:359
#40 0x01012d10 in eval_sub (form=64761918) at eval.c:2085
#41 0x01010a51 in Funwind_protect (args=64761926) at eval.c:1147
#42 0x01012d10 in eval_sub (form=64761934) at eval.c:2085
#43 0x0100f0aa in Fprogn (args=64761942) at eval.c:359
#44 0x01102c28 in Fsave_current_buffer (args=64761942) at editfns.c:953
#45 0x01012d10 in eval_sub (form=64761950) at eval.c:2085
#46 0x0100f0aa in Fprogn (args=64761958) at eval.c:359
#47 0x010104e9 in Flet (args=64761966) at eval.c:913
#48 0x01012d10 in eval_sub (form=64761974) at eval.c:2085
#49 0x0100f0aa in Fprogn (args=64762110) at eval.c:359
#50 0x01012d10 in eval_sub (form=64762102) at eval.c:2085
#51 0x01010da7 in internal_lisp_condition_case (var=58536418, bodyform=64762102, handlers=64694518) at eval.c:1242
#52 0x01010ac1 in Fcondition_case (args=64762166) at eval.c:1183
#53 0x01012d10 in eval_sub (form=64762174) at eval.c:2085
#54 0x0100f0aa in Fprogn (args=64762182) at eval.c:359
#55 0x010104e9 in Flet (args=64762190) at eval.c:913
#56 0x01012d10 in eval_sub (form=64762198) at eval.c:2085
#57 0x0100f0aa in Fprogn (args=64762230) at eval.c:359
#58 0x01015cc5 in funcall_lambda (fun=64762206, nargs=0, arg_vector=0x82b50c) at eval.c:2997
#59 0x01015365 in Ffuncall (nargs=1, args=0x82b508) at eval.c:2833
#60 0x01013832 in Fapply (nargs=2, args=0x82b508) at eval.c:2249
#61 0x01014be2 in Ffuncall (nargs=3, args=0x82b504) at eval.c:2753
#62 0x010e0b23 in exec_byte_code (bytestr=20931209, vector=20931261, maxdepth=16, args_template=56846362, nargs=0, args=0x0)
at bytecode.c:899
#63 0x010dfeea in Fbyte_code (bytestr=20931209, vector=20931261, maxdepth=16) at bytecode.c:474
#64 0x0101322c in eval_sub (form=20931198) at eval.c:2143
#65 0x01010da7 in internal_lisp_condition_case (var=56846362, bodyform=20931198, handlers=20115838) at eval.c:1242
#66 0x010e1760 in exec_byte_code (bytestr=20930953, vector=20931085, maxdepth=20, args_template=56846362, nargs=0, args=0x0)
at bytecode.c:1095
#67 0x01015dfa in funcall_lambda (fun=20930925, nargs=1, arg_vector=0x363681a <__register_frame_info+56846362>) at eval.c:3004
#68 0x01015293 in Ffuncall (nargs=2, args=0x82bbf8) at eval.c:2821
#69 0x01014635 in call1 (fn=56888610, arg1=75177909) at eval.c:2566
#70 0x0104087c in timer_check_2 (timers=98139870, idle_timers=98139830) at keyboard.c:4421
#71 0x01040965 in timer_check () at keyboard.c:4488
#72 0x0103e7d8 in readable_events (flags=1) at keyboard.c:3382
#73 0x010472cd in get_input_pending (addr=0x1666740, flags=1) at keyboard.c:6712
#74 0x01052ab1 in detect_input_pending_run_timers (do_display=1) at keyboard.c:10304
#75 0x0102b74e in wait_reading_process_output (time_limit=8, nsecs=0, read_kbd=-1, do_display=1, wait_for_cell=56846362,
wait_proc=0x0, just_wait_proc=0) at process.c:4761
#76 0x010fb5a1 in sit_for (timeout=32, reading=true, do_display=1) at dispnew.c:5973
#77 0x0103baec in read_char (commandflag=1, nmaps=2, maps=0x82c070, prev_event=56846362, used_mouse_menu=0x82c148, end_time=0x0)
at keyboard.c:2687
#78 0x0104ef24 in read_key_sequence (keybuf=0x82c2d0, bufsize=30, prompt=56846362, dont_downcase_last=0,

---Type <return> to continue, or q <return> to quit---

can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9259
#79 0x010385a1 in command_loop_1 () at keyboard.c:1474
#80 0x01010e89 in internal_condition_case (bfun=0x10380af <command_loop_1>, handlers=56896946, hfun=0x10378c9 <cmd_error>)
at eval.c:1288
#81 0x01037d23 in command_loop_2 (ignore=56846362) at keyboard.c:1179
#82 0x010108e3 in internal_catch (tag=56950578, func=0x1037cff <command_loop_2>, arg=56846362) at eval.c:1059
#83 0x01037c8c in command_loop () at keyboard.c:1144
#84 0x01037286 in recursive_edit_1 () at keyboard.c:779
#85 0x010be1cc in read_minibuf (map=62296974, initial=56846362, prompt=64754449, expflag=0, histvar=56968154, histpos=0,
defalt=56846362, allow_props=0, inherit_input_method=1) at minibuf.c:685
#86 0x010beecf in Fread_from_minibuffer (prompt=64754449, initial_contents=56846362, keymap=62296974, sys_read=56846362,
hist=56846362, default_value=56846362, inherit_input_method=56846386) at minibuf.c:987
#87 0x0101349c in eval_sub (form=64710542) at eval.c:2161
#88 0x0100f0aa in Fprogn (args=64708614) at eval.c:359
#89 0x010104e9 in Flet (args=64773182) at eval.c:913
#90 0x01012d10 in eval_sub (form=64773190) at eval.c:2085
#91 0x0100f0aa in Fprogn (args=64773206) at eval.c:359
#92 0x0100eff8 in Fcond (args=64773230) at eval.c:337
#93 0x01012d10 in eval_sub (form=64773238) at eval.c:2085
#94 0x0100f0aa in Fprogn (args=64773246) at eval.c:359
#95 0x01010051 in FletX (args=64773254) at eval.c:843
#96 0x01012d10 in eval_sub (form=64773262) at eval.c:2085
#97 0x0100f0aa in Fprogn (args=64773286) at eval.c:359
#98 0x01102c28 in Fsave_current_buffer (args=64773278) at editfns.c:953
#99 0x01012d10 in eval_sub (form=64773270) at eval.c:2085
#100 0x0100f0aa in Fprogn (args=64773326) at eval.c:359
#101 0x01015cc5 in funcall_lambda (fun=64773294, nargs=7, arg_vector=0x82ce40) at eval.c:2997
#102 0x010155d4 in apply_lambda (fun=64773294, args=64683598) at eval.c:2881
#103 0x0101372f in eval_sub (form=64683590) at eval.c:2212
#104 0x01010a51 in Funwind_protect (args=64683662) at eval.c:1147
#105 0x01012d10 in eval_sub (form=64683654) at eval.c:2085
#106 0x0100f0aa in Fprogn (args=64683710) at eval.c:359
#107 0x01012d10 in eval_sub (form=64683678) at eval.c:2085
#108 0x01010a51 in Funwind_protect (args=64683726) at eval.c:1147
#109 0x01012d10 in eval_sub (form=64683718) at eval.c:2085
#110 0x0100f0aa in Fprogn (args=64681446) at eval.c:359
#111 0x010104e9 in Flet (args=64681454) at eval.c:913
#112 0x01012d10 in eval_sub (form=64681462) at eval.c:2085
#113 0x0100f0aa in Fprogn (args=64681470) at eval.c:359
#114 0x010104e9 in Flet (args=64681622) at eval.c:913
#115 0x01012d10 in eval_sub (form=64681630) at eval.c:2085
#116 0x01010da7 in internal_lisp_condition_case (var=58536418, bodyform=64681630, handlers=64681782) at eval.c:1242
#117 0x01010ac1 in Fcondition_case (args=64681798) at eval.c:1183
#118 0x01012d10 in eval_sub (form=64681806) at eval.c:2085
#119 0x01010a51 in Funwind_protect (args=64681822) at eval.c:1147
#120 0x01012d10 in eval_sub (form=64681814) at eval.c:2085
#121 0x0100f0aa in Fprogn (args=64681862) at eval.c:359

---Type <return> to continue, or q <return> to quit---

#122 0x010104e9 in Flet (args=64681870) at eval.c:913
#123 0x01012d10 in eval_sub (form=64681878) at eval.c:2085
#124 0x0100f0aa in Fprogn (args=64681886) at eval.c:359
#125 0x010108e3 in internal_catch (tag=56950578, func=0x100f055 <Fprogn>, arg=64684966) at eval.c:1059
#126 0x01010849 in Fcatch (args=64684958) at eval.c:1030
#127 0x01012d10 in eval_sub (form=64684950) at eval.c:2085
#128 0x0100f0aa in Fprogn (args=64681918) at eval.c:359
#129 0x01015cc5 in funcall_lambda (fun=64681894, nargs=9, arg_vector=0x82df04) at eval.c:2997
#130 0x01015365 in Ffuncall (nargs=10, args=0x82df00) at eval.c:2833
#131 0x0101407c in Fapply (nargs=2, args=0x82dfb0) at eval.c:2306
#132 0x01012fa1 in eval_sub (form=64690638) at eval.c:2109
#133 0x0100f0aa in Fprogn (args=64690662) at eval.c:359
#134 0x0100ef2e in Fif (args=64689310) at eval.c:310
#135 0x01012d10 in eval_sub (form=64689302) at eval.c:2085
#136 0x0100f0aa in Fprogn (args=64689374) at eval.c:359
#137 0x0100ef2e in Fif (args=64689358) at eval.c:310
#138 0x01012d10 in eval_sub (form=64689350) at eval.c:2085
#139 0x0100f0aa in Fprogn (args=64689382) at eval.c:359
#140 0x010104e9 in Flet (args=64689390) at eval.c:913
#141 0x01012d10 in eval_sub (form=64689398) at eval.c:2085
#142 0x0100f0aa in Fprogn (args=64689430) at eval.c:359
#143 0x01015cc5 in funcall_lambda (fun=64689406, nargs=9, arg_vector=0x82e674) at eval.c:2997
#144 0x01015365 in Ffuncall (nargs=10, args=0x82e670) at eval.c:2833
#145 0x0101407c in Fapply (nargs=2, args=0x82e720) at eval.c:2306
#146 0x01012fa1 in eval_sub (form=64690494) at eval.c:2109
#147 0x0100f0aa in Fprogn (args=64689174) at eval.c:359
#148 0x01015cc5 in funcall_lambda (fun=64689190, nargs=0, arg_vector=0x82e964) at eval.c:2997
#149 0x01015365 in Ffuncall (nargs=1, args=0x82e960) at eval.c:2833
#150 0x01012fa1 in eval_sub (form=64651366) at eval.c:2109
#151 0x01010a51 in Funwind_protect (args=64651382) at eval.c:1147
#152 0x01012d10 in eval_sub (form=64651358) at eval.c:2085
#153 0x0100f0aa in Fprogn (args=64651510) at eval.c:359
#154 0x01015cc5 in funcall_lambda (fun=64651574, nargs=2, arg_vector=0x82ec20) at eval.c:2997
#155 0x010155d4 in apply_lambda (fun=64651574, args=64689286) at eval.c:2881
#156 0x0101372f in eval_sub (form=64689278) at eval.c:2212
#157 0x0100ef11 in Fif (args=64689310) at eval.c:309
#158 0x01012d10 in eval_sub (form=64689302) at eval.c:2085
#159 0x0100f0aa in Fprogn (args=64689374) at eval.c:359
#160 0x0100ef2e in Fif (args=64689358) at eval.c:310
#161 0x01012d10 in eval_sub (form=64689350) at eval.c:2085
#162 0x0100f0aa in Fprogn (args=64689382) at eval.c:359
#163 0x010104e9 in Flet (args=64689390) at eval.c:913
#164 0x01012d10 in eval_sub (form=64689398) at eval.c:2085
#165 0x0100f0aa in Fprogn (args=64689430) at eval.c:359
#166 0x01015cc5 in funcall_lambda (fun=64689406, nargs=4, arg_vector=0x82f290) at eval.c:2997
#167 0x010155d4 in apply_lambda (fun=64689406, args=64723270) at eval.c:2881
#168 0x0101372f in eval_sub (form=64723262) at eval.c:2212

---Type <return> to continue, or q <return> to quit---

#169 0x0100f0aa in Fprogn (args=64723390) at eval.c:359
#170 0x01015cc5 in funcall_lambda (fun=64723446, nargs=2, arg_vector=0x82f4a0) at eval.c:2997
#171 0x010155d4 in apply_lambda (fun=64723446, args=66111382) at eval.c:2881
#172 0x0101372f in eval_sub (form=66111390) at eval.c:2212
#173 0x0100f0aa in Fprogn (args=66111366) at eval.c:359
#174 0x010104e9 in Flet (args=66111398) at eval.c:913
#175 0x01012d10 in eval_sub (form=66111430) at eval.c:2085
#176 0x0100f0aa in Fprogn (args=66111270) at eval.c:359
#177 0x01015cc5 in funcall_lambda (fun=66111206, nargs=0, arg_vector=0x82f954) at eval.c:2997
#178 0x01015365 in Ffuncall (nargs=1, args=0x82f950) at eval.c:2833
#179 0x010145ac in apply1 (fn=60857682, arg=56846362) at eval.c:2533
#180 0x010e48a1 in Fcall_interactively (function=60857682, record_flag=56846362, keys=56867757) at callint.c:377
#181 0x01014f51 in Ffuncall (nargs=4, args=0x82fb60) at eval.c:2779
#182 0x010146af in call3 (fn=56957674, arg1=60857682, arg2=56846362, arg3=56846362) at eval.c:2597
#183 0x01052a24 in Fcommand_execute (cmd=60857682, record_flag=56846362, keys=56846362, special=56846362) at keyboard.c:10266
#184 0x01038df6 in command_loop_1 () at keyboard.c:1602
#185 0x01010e89 in internal_condition_case (bfun=0x10380af <command_loop_1>, handlers=56896946, hfun=0x10378c9 <cmd_error>)
at eval.c:1288
#186 0x01037d23 in command_loop_2 (ignore=56846362) at keyboard.c:1179
#187 0x010108e3 in internal_catch (tag=56886802, func=0x1037cff <command_loop_2>, arg=56846362) at eval.c:1059
#188 0x01037cdd in command_loop () at keyboard.c:1158
#189 0x01037286 in recursive_edit_1 () at keyboard.c:779
#190 0x010375b3 in Frecursive_edit () at keyboard.c:843
#191 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552
(gdb)
(gdb) thread 1
[Switching to thread 1 (Thread 6176.0x272c)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) finish
Run till exit from #0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

[Inferior 1 (process 6176) exited with code 01]
(gdb)
The program is not being run.(gdb)

(gdb) The program is not being run.

The "finish dance" ended prematurely: I only could type it once, and got no
answer. Is it a slow? ;-)

I waited for about 2 minutes before killing the process from the Task Manager.

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com

> Date: Wed, 10 Oct 2012 10:41:25 +0200

>
> I just downloaded a version from 13 hours ago from
> https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8
>

> I'll run Emacs 24.2 from now on until the next crash occurs.

The above isn't Emacs 24.2, it's what will become Emacs 24.3.

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com

> Date: Wed, 10 Oct 2012 10:45:45 +0200

> I've also disabled the bidirectional reordering of text for display in the
> visual order:
>

> (setq-default bidi-display-reordering nil)

No, please don't do that, at least not in the context of tracking the
bug in this thread. Turning off bidi-display-reordering is supported
only as a means to debug the display engine. By setting that variable
to nil, you may well bump into additional bugs and even crashes that
no one is interested in fixing.

If the default setting of bidi-display-reordering results in some
trouble, please report that as bugs, so that they could be fixed. The
old unidirectional display is deprecated, so the sooner we fix any
remaining problems in the bidirectional display engine, the better.

TIA

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com

> Date: Wed, 10 Oct 2012 12:02:20 +0200

>
> The (translated) title of the dialog box is: "Windows Cannot End This
> Program". And the program is "Bash".

This may well be the reason for Emacs hanging. Next time Emacs hangs,
can you look in the Task manager or some equivalent program for such a
stray Bash which is a sub-process of Emacs, and if you find one, kill
it forcibly from the Task manager, and see if Emacs then becomes
responsive again?

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com

> Date: Wed, 10 Oct 2012 16:09:34 +0200
>
> Eli,

> (gdb) thread 1
> [Switching to thread 1 (Thread 6176.0x272c)]
> #0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
> (gdb) finish
> Run till exit from #0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>
> [Inferior 1 (process 6176) exited with code 01]
> (gdb)
> The program is not being run.(gdb)
>
> (gdb) The program is not being run.

Not sure what happened here.

> I waited for about 2 minutes before killing the process from the Task Manager.

Which process? Emacs was supposed to be already dead, see this
announcement by GDB:

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
>> I've also disabled the bidirectional reordering of text for display in the
>> visual order:
>>
>> (setq-default bidi-display-reordering nil)
>
> No, please don't do that, at least not in the context of tracking the
> bug in this thread. Turning off bidi-display-reordering is supported
> only as a means to debug the display engine. By setting that variable
> to nil, you may well bump into additional bugs and even crashes that
> no one is interested in fixing.

Understood! I keep off that...

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
>> The (translated) title of the dialog box is: "Windows Cannot End This
>> Program". And the program is "Bash".
>
> This may well be the reason for Emacs hanging. Next time Emacs hangs,
> can you look in the Task manager or some equivalent program for such a
> stray Bash which is a sub-process of Emacs, and if you find one, kill
> it forcibly from the Task manager, and see if Emacs then becomes
> responsive again?

I'll do. I keep you posted.

[Fabrice Niessen]

Eli,

No, I am quite sure that the announcement has been displayed once I've killed
Emacs from the Task Manager, not before.

[Fabrice Niessen]

Hello Eli,

I've been running Emacs 24.2 for 1.5 day so far with no crash... This is with
the version I got from
ftp://ftp.gnu.org/gnu/emacs/windows/emacs-24.2-bin-i386.zip, dated 7th of
October. So, clearly, one of the most often occurring reason for crashing has
been fixed. That's pretty good news.

Now, I just got an infloop with that version, when I was using helm-for-files,
from Helm version:

--8<---------------cut here---------------start------------->8---
commit a6da05c96da1dbf9f3591060880b2801e5503500
Author: Thierry Volpiatto <thierry....@gmail.com>
Date: Fri Aug 31 08:45:28 2012 +0200
--8<---------------cut here---------------end--------------->8---

Here the backtrace, and the short "finish" dance:

--8<---------------cut here---------------start------------->8---
$ gdb -p 7864

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 7864
[New Thread 7864.0x17ac]
[New Thread 7864.0x1e6c]
[New Thread 7864.0x8a4]
[New Thread 7864.0x12d8]
[New Thread 7864.0x18d0]
[New Thread 7864.0x14e0]
[New Thread 7864.0x690]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.
(gdb) thread apply all backtrace

Thread 7 (Thread 7864.0x690):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x72f8ffd0 in ?? ()

#6 0x00000000 in ?? ()

Thread 6 (Thread 7864.0x14e0):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000650 in ?? ()

#4 0x00000000 in ?? ()

Thread 5 (Thread 7864.0x18d0):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000006e0 in ?? ()

#4 0x00000000 in ?? ()

Thread 4 (Thread 7864.0x12d8):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x725c402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x725c57c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x724b67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
#5 0x0102f9f2 in _sys_read_ahead ()
#6 0x0105dc16 in reader_thread@4 ()

#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 3 (Thread 7864.0x8a4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000584 in ?? ()

#4 0x00000000 in ?? ()

Thread 2 (Thread 7864.0x1e6c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll

#2 0x7e3a776b in USER32!GetMessageA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x010bb5b3 in w32_msg_pump.isra.14 ()

---Type <return> to continue, or q <return> to quit---

#4 0x010bbc23 in w32_msg_worker@4 ()

#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Thread 1 (Thread 7864.0x17ac):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#4 0x00a41fe0 in ?? ()
#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll
#6 0x00000005 in ?? ()

#7 0x013deddc in fd_info ()
#8 0x013df250 in child_procs ()
#9 0x00000005 in ?? ()
#10 0x0141f81a in __register_frame_info ()
#11 0x0102f72b in sys_close ()
#12 0x010c2b6c in emacs_close ()
#13 0x0101204c in deactivate_process ()
#14 0x010141f2 in status_notify ()
#15 0x010147cc in Fdelete_process ()
#16 0x0100e4b4 in eval_sub ()
#17 0x0100e810 in Fprogn ()
#18 0x0100eaff in funcall_lambda ()
#19 0x0100ed43 in Ffuncall ()
#20 0x0100f1fe in call1 ()
#21 0x0104c4cd in mapcar1 ()
#22 0x0104f6db in Fmapc ()
#23 0x0100e4a4 in eval_sub ()
#24 0x0100e810 in Fprogn ()
#25 0x0100eaff in funcall_lambda ()
#26 0x0100dfa2 in apply_lambda ()
#27 0x0100e216 in eval_sub ()
#28 0x0100e810 in Fprogn ()
#29 0x0100eaff in funcall_lambda ()
#30 0x0100dfa2 in apply_lambda ()
#31 0x0100e216 in eval_sub ()
#32 0x0100e810 in Fprogn ()
#33 0x0100e60d in eval_sub ()
#34 0x0100e3a7 in eval_sub ()
#35 0x0100e810 in Fprogn ()
#36 0x0100eaff in funcall_lambda ()
#37 0x0100dfa2 in apply_lambda ()
#38 0x0100e216 in eval_sub ()
#39 0x0100e810 in Fprogn ()
#40 0x0100e60d in eval_sub ()
#41 0x0101120e in Funwind_protect ()

---Type <return> to continue, or q <return> to quit---

#42 0x0100e60d in eval_sub ()
#43 0x0100e810 in Fprogn ()
#44 0x010430e4 in Fsave_current_buffer ()
#45 0x0100e60d in eval_sub ()
#46 0x0100e810 in Fprogn ()
#47 0x0101145d in Flet ()
#48 0x0100e60d in eval_sub ()
#49 0x0100e3a7 in eval_sub ()
#50 0x0100e810 in Fprogn ()
#51 0x0100e60d in eval_sub ()
#52 0x0101111b in internal_lisp_condition_case ()
#53 0x010111c8 in Fcondition_case ()
#54 0x0100e60d in eval_sub ()
#55 0x0100e810 in Fprogn ()
#56 0x0101145d in Flet ()
#57 0x0100e60d in eval_sub ()
#58 0x0100e3a7 in eval_sub ()
#59 0x0100e810 in Fprogn ()
#60 0x0100eaff in funcall_lambda ()
#61 0x0100ed43 in Ffuncall ()
#62 0x0100fd11 in Fapply ()
#63 0x0100ef7d in Ffuncall ()
#64 0x0107139d in exec_byte_code ()
#65 0x01071f9a in Fbyte_code ()
#66 0x0100e48d in eval_sub ()
#67 0x0101111b in internal_lisp_condition_case ()
#68 0x01070ae5 in exec_byte_code ()
#69 0x0100e9ec in funcall_lambda ()
#70 0x0100ed43 in Ffuncall ()
#71 0x0100f1fe in call1 ()
#72 0x0101f040 in timer_check ()
#73 0x0101f1e5 in readable_events ()
#74 0x0101fcce in get_input_pending.constprop.15 ()
#75 0x01021698 in detect_input_pending_run_timers ()
#76 0x01015b49 in wait_reading_process_output ()
#77 0x0105c7e4 in sit_for ()
#78 0x01023219 in read_char ()
#79 0x01024005 in read_key_sequence.constprop.14 ()
#80 0x01025879 in command_loop_1 ()
#81 0x0100d5b1 in internal_condition_case ()
#82 0x0101cf14 in command_loop_2 ()
#83 0x0100d4fb in internal_catch ()
#84 0x0101dc03 in recursive_edit_1 ()
#85 0x01085ca8 in read_minibuf ()
#86 0x0100e3eb in eval_sub ()
#87 0x0100e810 in Fprogn ()
#88 0x0101145d in Flet ()

---Type <return> to continue, or q <return> to quit---

#89 0x0100e60d in eval_sub ()
#90 0x0100e810 in Fprogn ()
#91 0x0100e60d in eval_sub ()
#92 0x0100e810 in Fprogn ()
#93 0x01011638 in FletX ()
#94 0x0100e60d in eval_sub ()
#95 0x0100e810 in Fprogn ()
#96 0x010430e4 in Fsave_current_buffer ()
#97 0x0100e60d in eval_sub ()
#98 0x0100e3a7 in eval_sub ()
#99 0x0100e810 in Fprogn ()
#100 0x0100eaff in funcall_lambda ()
#101 0x0100dfa2 in apply_lambda ()
#102 0x0100e216 in eval_sub ()
#103 0x0101120e in Funwind_protect ()
#104 0x0100e60d in eval_sub ()
#105 0x0100e810 in Fprogn ()
#106 0x0100e60d in eval_sub ()
#107 0x0101120e in Funwind_protect ()
#108 0x0100e60d in eval_sub ()
#109 0x0100e810 in Fprogn ()
#110 0x0101145d in Flet ()
#111 0x0100e60d in eval_sub ()
#112 0x0100e3a7 in eval_sub ()
#113 0x0100e810 in Fprogn ()
#114 0x0101145d in Flet ()
#115 0x0100e60d in eval_sub ()
#116 0x0101111b in internal_lisp_condition_case ()
#117 0x010111c8 in Fcondition_case ()
#118 0x0100e60d in eval_sub ()
#119 0x0101120e in Funwind_protect ()
#120 0x0100e60d in eval_sub ()
#121 0x0100e810 in Fprogn ()
#122 0x0101145d in Flet ()
#123 0x0100e60d in eval_sub ()
#124 0x0100e810 in Fprogn ()
#125 0x0100d4fb in internal_catch ()
#126 0x0100e6b9 in Fcatch ()
#127 0x0100e60d in eval_sub ()
#128 0x0100e810 in Fprogn ()
#129 0x0100eaff in funcall_lambda ()
#130 0x0100ed43 in Ffuncall ()
#131 0x0100fcd5 in Fapply ()
#132 0x0100e5db in eval_sub ()
#133 0x0100e810 in Fprogn ()
#134 0x0100e60d in eval_sub ()
#135 0x0100e810 in Fprogn ()

---Type <return> to continue, or q <return> to quit---

#136 0x0100e60d in eval_sub ()
#137 0x0100e810 in Fprogn ()
#138 0x0101145d in Flet ()
#139 0x0100e60d in eval_sub ()
#140 0x0100e810 in Fprogn ()
#141 0x0100eaff in funcall_lambda ()
#142 0x0100ed43 in Ffuncall ()
#143 0x0100fcd5 in Fapply ()
#144 0x0100e5db in eval_sub ()
#145 0x0100e810 in Fprogn ()
#146 0x0100eaff in funcall_lambda ()
#147 0x0100ed43 in Ffuncall ()
#148 0x0100e5db in eval_sub ()
#149 0x0101120e in Funwind_protect ()
#150 0x0100e60d in eval_sub ()
#151 0x0100e810 in Fprogn ()
#152 0x0100eaff in funcall_lambda ()
#153 0x0100dfa2 in apply_lambda ()
#154 0x0100e216 in eval_sub ()
#155 0x0100e60d in eval_sub ()
#156 0x0100e810 in Fprogn ()
#157 0x0100e60d in eval_sub ()
#158 0x0100e810 in Fprogn ()
#159 0x0101145d in Flet ()
#160 0x0100e60d in eval_sub ()
#161 0x0100e810 in Fprogn ()
#162 0x0100eaff in funcall_lambda ()
#163 0x0100dfa2 in apply_lambda ()
#164 0x0100e216 in eval_sub ()
#165 0x0100e810 in Fprogn ()
#166 0x0100eaff in funcall_lambda ()
#167 0x0100dfa2 in apply_lambda ()
#168 0x0100e216 in eval_sub ()
#169 0x0100e810 in Fprogn ()
#170 0x0101145d in Flet ()
#171 0x0100e60d in eval_sub ()
#172 0x0100e810 in Fprogn ()
#173 0x0100eaff in funcall_lambda ()
#174 0x0100ed43 in Ffuncall ()
#175 0x0100f2e7 in apply1 ()
#176 0x0107230b in Fcall_interactively ()
#177 0x0100eed9 in Ffuncall ()
#178 0x0100f1a0 in call3 ()
#179 0x010259e5 in command_loop_1 ()
#180 0x0100d5b1 in internal_condition_case ()
#181 0x0101cf14 in command_loop_2 ()
#182 0x0100d4fb in internal_catch ()

---Type <return> to continue, or q <return> to quit---

#183 0x0101dc8c in recursive_edit_1 ()
#184 0x0101df14 in Frecursive_edit ()
#185 0x011a1c47 in main ()
(gdb)
(gdb) xbactrace
(gdb) Undefined command: "xbactrace". Try "help".
(gdb) finish
Run till exit from #0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) finish
Run till exit from #0 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
Warning:
(gdb) Cannot insert breakpoint 0.
Error accessing memory address 0x5: Input/output error.


Run till exit from #0 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x5: Input/output error.

finish
Run till exit from #0 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x5: Input/output error.

(gdb) finish
Run till exit from #0 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
Warning:
Cannot insert breakpoint 0.
Error accessing memory address 0x5: Input/output error.

(gdb) q

A debugging session is active.

Inferior 1 [process 7864] will be detached.

Quit anyway? (y or n) y

Detaching from program: /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe, Pid 7864
--8<---------------cut here---------------end--------------->8---

Is this what you need?

BTW, you asked me to go there, to find the .gdbinit file in some /src
directory; but I don't find where... Could you show me where?

Best regards,

[Fabrice Niessen]

Eli,

> I've been running Emacs 24.2 for 1.5 day so far with no crash... This is with
> the version I got from
> ftp://ftp.gnu.org/gnu/emacs/windows/emacs-24.2-bin-i386.zip, dated 7th of
> October. So, clearly, one of the most often occurring reason for crashing has
> been fixed. That's pretty good news.

Just got a crash now...

> BTW, you asked me to go there, to find the .gdbinit file in some /src
> directory; but I don't find where... Could you show me where?

I didn't have a .gdbinit file for that Emacs 24.2, so I could not do the
"xbacktrace" command. Still, here, the other commands.

Please note that I directly typed "thread apply all backtrace" before the
"continue". When I became aware of that, I typed "continue" at the first GDB
prompt, and then once again "thread apply all backtrace". I hope you still
will find relevant information.

--8<---------------cut here---------------start------------->8---
$ gdb -p 8092

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 8092
[New Thread 8092.0x77c]
[New Thread 8092.0x14dc]
[New Thread 8092.0x1acc]
[New Thread 8092.0x57c]
[New Thread 8092.0x14d4]
[New Thread 8092.0xc24]
[New Thread 8092.0x11ec]
[New Thread 8092.0x1a4]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.
(gdb) thread apply all backtrace

Thread 8 (Thread 8092.0x1a4):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x72daffd0 in ?? ()

#6 0x00000000 in ?? ()

Thread 7 (Thread 8092.0x11ec):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000002c0 in ?? ()

#4 0x00000000 in ?? ()

Thread 6 (Thread 8092.0xc24):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x725a402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x725a57c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x724f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0102f9f2 in _sys_read_ahead ()
#6 0x0105dc16 in reader_thread@4 ()
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 5 (Thread 8092.0x14d4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x725a402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x725a57c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x724f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0102f9f2 in _sys_read_ahead ()
#6 0x0105dc16 in reader_thread@4 ()
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 4 (Thread 8092.0x57c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000002c8 in ?? ()

#4 0x00000000 in ?? ()

Thread 3 (Thread 8092.0x1acc):

---Type <return> to continue, or q <return> to quit---

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x725a402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x725a57c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x724f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0102f9f2 in _sys_read_ahead ()
#6 0x0105dc16 in reader_thread@4 ()
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 2 (Thread 8092.0x14dc):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3a776b in USER32!GetMessageA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x010bb5b3 in w32_msg_pump.isra.14 ()

#4 0x010bbc23 in w32_msg_worker@4 ()
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Thread 1 (Thread 8092.0x77c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7e399418 in WaitMessage () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3a770a in USER32!CallMsgFilterW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x7e3a49c4 in USER32!GetCursorFrameInfo () from /cygdrive/c/WINDOWS/system32/USER32.dll
#4 0x7e3ba956 in USER32!SoftModalMessageBox () from /cygdrive/c/WINDOWS/system32/USER32.dll
#5 0x7e3ba2bc in USER32!MessageBoxIndirectA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#6 0x7e3e63fd in USER32!MessageBoxTimeoutW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#7 0x7e3e64a2 in USER32!MessageBoxTimeoutA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#8 0x7e3d0877 in USER32!MessageBoxExA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#9 0x7e3d082f in USER32!MessageBoxA () from /cygdrive/c/WINDOWS/system32/USER32.dll
#10 0x010ba6e0 in w32_abort ()
#11 0x0117fec9 in relinquish ()
#12 0x011805b6 in r_alloc_sbrk ()
#13 0x010f5b51 in _free_internal_nolock ()
#14 0x01009a3a in emacs_blocked_free ()
#15 0x01007640 in xfree ()
#16 0x01007a79 in safe_alloca_unwind ()
#17 0x0100dc77 in unbind_to ()
#18 0x01149c75 in load_charset ()
#19 0x0114bd16 in decode_char ()
#20 0x0114bf5e in Fmake_char ()
#21 0x0100e44a in eval_sub ()
#22 0x0100e359 in eval_sub ()
#23 0x0100e359 in eval_sub ()

#24 0x0100e810 in Fprogn ()

#25 0x01010fa1 in Fwhile ()
#26 0x0100e60d in eval_sub ()

---Type <return> to continue, or q <return> to quit---

#27 0x0100e810 in Fprogn ()
#28 0x0101145d in Flet ()
#29 0x0100e60d in eval_sub ()
#30 0x0100e810 in Fprogn ()
#31 0x0100d4fb in internal_catch ()
#32 0x0100e6b9 in Fcatch ()

#33 0x0100e60d in eval_sub ()

#34 0x0100e359 in eval_sub ()
#35 0x0100e3a7 in eval_sub ()
#36 0x0100e3a7 in eval_sub ()
#37 0x0100e810 in Fprogn ()
#38 0x0101145d in Flet ()
#39 0x0100e60d in eval_sub ()
#40 0x01010b8a in Fdefconst ()
#41 0x0100e60d in eval_sub ()
#42 0x01035cf0 in readevalloop ()
#43 0x0103640e in Feval_buffer ()
#44 0x0100ee96 in Ffuncall ()
#45 0x0107139d in exec_byte_code ()
#46 0x0100e9ec in funcall_lambda ()
#47 0x0100ed43 in Ffuncall ()
#48 0x0100f165 in call4 ()
#49 0x010368f0 in Fload ()
#50 0x0104f995 in Frequire ()
#51 0x0100e48d in eval_sub ()
#52 0x0100e6eb in Fsetq ()
#53 0x0100e60d in eval_sub ()
#54 0x0100e810 in Fprogn ()
#55 0x0101145d in Flet ()
#56 0x0100e60d in eval_sub ()
#57 0x0100e810 in Fprogn ()
#58 0x0101145d in Flet ()
#59 0x0100e60d in eval_sub ()
#60 0x0100e810 in Fprogn ()
#61 0x0100e60d in eval_sub ()
#62 0x0100e810 in Fprogn ()
#63 0x01011638 in FletX ()
#64 0x0100e60d in eval_sub ()
#65 0x0100e810 in Fprogn ()
#66 0x0101145d in Flet ()
#67 0x0100e60d in eval_sub ()
#68 0x0100e810 in Fprogn ()
#69 0x0100eaff in funcall_lambda ()

#70 0x0100ed43 in Ffuncall ()

#71 0x0107139d in exec_byte_code ()
#72 0x0100e9ec in funcall_lambda ()
#73 0x0100ed43 in Ffuncall ()

---Type <return> to continue, or q <return> to quit---

#74 0x0107139d in exec_byte_code ()
#75 0x0100e9ec in funcall_lambda ()
#76 0x0100ed43 in Ffuncall ()
#77 0x0107139d in exec_byte_code ()
#78 0x0100e9ec in funcall_lambda ()
#79 0x0100ed43 in Ffuncall ()
#80 0x0107139d in exec_byte_code ()
#81 0x0100e9ec in funcall_lambda ()
#82 0x0100ed43 in Ffuncall ()
#83 0x0107139d in exec_byte_code ()
#84 0x0100e9ec in funcall_lambda ()
#85 0x0100ed43 in Ffuncall ()
#86 0x0107139d in exec_byte_code ()
#87 0x01071f9a in Fbyte_code ()
#88 0x0100e48d in eval_sub ()
#89 0x0100d4fb in internal_catch ()
#90 0x01070b2b in exec_byte_code ()
#91 0x0100e9ec in funcall_lambda ()
#92 0x0100ed43 in Ffuncall ()
#93 0x0107139d in exec_byte_code ()
#94 0x0100e9ec in funcall_lambda ()
#95 0x0100ed43 in Ffuncall ()
#96 0x0107139d in exec_byte_code ()
#97 0x0100e9ec in funcall_lambda ()
#98 0x0100ed43 in Ffuncall ()
#99 0x0107139d in exec_byte_code ()
#100 0x0100e9ec in funcall_lambda ()
#101 0x0100ed43 in Ffuncall ()
#102 0x0107139d in exec_byte_code ()
#103 0x0100e9ec in funcall_lambda ()
#104 0x0100ed43 in Ffuncall ()
#105 0x0107139d in exec_byte_code ()
#106 0x0100e9ec in funcall_lambda ()
#107 0x0100ed43 in Ffuncall ()
#108 0x0107139d in exec_byte_code ()
#109 0x0100e9ec in funcall_lambda ()
#110 0x0100ed43 in Ffuncall ()
#111 0x0107139d in exec_byte_code ()
#112 0x0100e9ec in funcall_lambda ()
#113 0x0100ed43 in Ffuncall ()
#114 0x010728ec in Fcall_interactively ()
#115 0x0100eed9 in Ffuncall ()
#116 0x0100f1a0 in call3 ()
#117 0x010259e5 in command_loop_1 ()
#118 0x0100d5b1 in internal_condition_case ()
#119 0x0101cf14 in command_loop_2 ()
#120 0x0100d4fb in internal_catch ()

---Type <return> to continue, or q <return> to quit---

#121 0x0101dc8c in recursive_edit_1 ()
#122 0x0101df14 in Frecursive_edit ()
#123 0x011a1c47 in main ()
(gdb)

(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

[Switching to Thread 8092.0x77c]

0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) thread apply all backtrace

Thread 7 (Thread 8092.0x11ec):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000002c0 in ?? ()

#4 0x00000000 in ?? ()

Thread 6 (Thread 8092.0xc24):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x725a402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x725a57c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x724f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0102f9f2 in _sys_read_ahead ()
#6 0x0105dc16 in reader_thread@4 ()
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 5 (Thread 8092.0x14d4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x725a402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x725a57c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x724f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0102f9f2 in _sys_read_ahead ()
#6 0x0105dc16 in reader_thread@4 ()
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 4 (Thread 8092.0x57c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000002c8 in ?? ()

#4 0x00000000 in ?? ()

Thread 3 (Thread 8092.0x1acc):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x725a402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x725a57c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x724f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0102f9f2 in _sys_read_ahead ()
#6 0x0105dc16 in reader_thread@4 ()
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

---Type <return> to continue, or q <return> to quit---

Thread 2 (Thread 8092.0x14dc):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7e3acc11 in USER32!DrawIconEx () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x00fa5ff1 in UxTheme!SetThemeAppProperties () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#3 0x00fa6485 in UxTheme!SetThemeAppProperties () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#4 0x00fbc4b9 in UxTheme!GetThemeTextMetrics () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#5 0x00fa1ac7 in ?? () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#6 0x00fbc2b1 in UxTheme!GetThemeTextMetrics () from /cygdrive/c/WINDOWS/system32/uxtheme.dll
#7 0x7e3af15c in USER32!SendInput () from /cygdrive/c/WINDOWS/system32/USER32.dll
#8 0x09200156 in ?? ()
#9 0x00000085 in ?? ()
#10 0x330413c4 in ?? ()
#11 0x00000000 in ?? ()

Thread 1 (Thread 8092.0x77c):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x010ba6f2 in w32_abort ()
#2 0x0117fec9 in relinquish ()
#3 0x011805b6 in r_alloc_sbrk ()
#4 0x010f5b51 in _free_internal_nolock ()
#5 0x01009a3a in emacs_blocked_free ()
#6 0x01007640 in xfree ()
#7 0x01007a79 in safe_alloca_unwind ()
#8 0x0100dc77 in unbind_to ()
#9 0x01149c75 in load_charset ()
#10 0x0114bd16 in decode_char ()
#11 0x0114bf5e in Fmake_char ()
#12 0x0100e44a in eval_sub ()
#13 0x0100e359 in eval_sub ()
#14 0x0100e359 in eval_sub ()
#15 0x0100e810 in Fprogn ()
#16 0x01010fa1 in Fwhile ()
#17 0x0100e60d in eval_sub ()
#18 0x0100e810 in Fprogn ()
#19 0x0101145d in Flet ()
#20 0x0100e60d in eval_sub ()
#21 0x0100e810 in Fprogn ()
#22 0x0100d4fb in internal_catch ()
#23 0x0100e6b9 in Fcatch ()
#24 0x0100e60d in eval_sub ()
#25 0x0100e359 in eval_sub ()
#26 0x0100e3a7 in eval_sub ()
#27 0x0100e3a7 in eval_sub ()

#28 0x0100e810 in Fprogn ()

#29 0x0101145d in Flet ()
#30 0x0100e60d in eval_sub ()

---Type <return> to continue, or q <return> to quit---

#31 0x01010b8a in Fdefconst ()
#32 0x0100e60d in eval_sub ()
#33 0x01035cf0 in readevalloop ()
#34 0x0103640e in Feval_buffer ()
#35 0x0100ee96 in Ffuncall ()
#36 0x0107139d in exec_byte_code ()
#37 0x0100e9ec in funcall_lambda ()
#38 0x0100ed43 in Ffuncall ()
#39 0x0100f165 in call4 ()
#40 0x010368f0 in Fload ()
#41 0x0104f995 in Frequire ()
#42 0x0100e48d in eval_sub ()
#43 0x0100e6eb in Fsetq ()
#44 0x0100e60d in eval_sub ()
#45 0x0100e810 in Fprogn ()
#46 0x0101145d in Flet ()
#47 0x0100e60d in eval_sub ()
#48 0x0100e810 in Fprogn ()
#49 0x0101145d in Flet ()
#50 0x0100e60d in eval_sub ()
#51 0x0100e810 in Fprogn ()
#52 0x0100e60d in eval_sub ()
#53 0x0100e810 in Fprogn ()
#54 0x01011638 in FletX ()
#55 0x0100e60d in eval_sub ()
#56 0x0100e810 in Fprogn ()
#57 0x0101145d in Flet ()
#58 0x0100e60d in eval_sub ()

#59 0x0100e810 in Fprogn ()
#60 0x0100eaff in funcall_lambda ()
#61 0x0100ed43 in Ffuncall ()

#62 0x0107139d in exec_byte_code ()
#63 0x0100e9ec in funcall_lambda ()
#64 0x0100ed43 in Ffuncall ()
#65 0x0107139d in exec_byte_code ()
#66 0x0100e9ec in funcall_lambda ()
#67 0x0100ed43 in Ffuncall ()
#68 0x0107139d in exec_byte_code ()

#69 0x0100e9ec in funcall_lambda ()
#70 0x0100ed43 in Ffuncall ()

#71 0x0107139d in exec_byte_code ()
#72 0x0100e9ec in funcall_lambda ()
#73 0x0100ed43 in Ffuncall ()
#74 0x0107139d in exec_byte_code ()
#75 0x0100e9ec in funcall_lambda ()
#76 0x0100ed43 in Ffuncall ()
#77 0x0107139d in exec_byte_code ()

---Type <return> to continue, or q <return> to quit---

#78 0x01071f9a in Fbyte_code ()
#79 0x0100e48d in eval_sub ()
#80 0x0100d4fb in internal_catch ()
#81 0x01070b2b in exec_byte_code ()
#82 0x0100e9ec in funcall_lambda ()
#83 0x0100ed43 in Ffuncall ()
#84 0x0107139d in exec_byte_code ()
#85 0x0100e9ec in funcall_lambda ()
#86 0x0100ed43 in Ffuncall ()
#87 0x0107139d in exec_byte_code ()
#88 0x0100e9ec in funcall_lambda ()
#89 0x0100ed43 in Ffuncall ()
#90 0x0107139d in exec_byte_code ()
#91 0x0100e9ec in funcall_lambda ()
#92 0x0100ed43 in Ffuncall ()
#93 0x0107139d in exec_byte_code ()
#94 0x0100e9ec in funcall_lambda ()
#95 0x0100ed43 in Ffuncall ()
#96 0x0107139d in exec_byte_code ()
#97 0x0100e9ec in funcall_lambda ()
#98 0x0100ed43 in Ffuncall ()
#99 0x0107139d in exec_byte_code ()
#100 0x0100e9ec in funcall_lambda ()
#101 0x0100ed43 in Ffuncall ()
#102 0x0107139d in exec_byte_code ()
#103 0x0100e9ec in funcall_lambda ()
#104 0x0100ed43 in Ffuncall ()
#105 0x010728ec in Fcall_interactively ()
#106 0x0100eed9 in Ffuncall ()
#107 0x0100f1a0 in call3 ()
#108 0x010259e5 in command_loop_1 ()
#109 0x0100d5b1 in internal_condition_case ()
#110 0x0101cf14 in command_loop_2 ()
#111 0x0100d4fb in internal_catch ()
#112 0x0101dc8c in recursive_edit_1 ()
#113 0x0101df14 in Frecursive_edit ()
#114 0x011a1c47 in main ()
(gdb)

(gdb) q
A debugging session is active.

Inferior 1 [process 8092] will be detached.

Quit anyway? (y or n) y

Detaching from program: /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe, Pid 8092
--8<---------------cut here---------------end--------------->8---

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com

> Date: Fri, 12 Oct 2012 16:57:07 +0200

>
> #10 0x010ba6e0 in w32_abort ()
> #11 0x0117fec9 in relinquish ()
> #12 0x011805b6 in r_alloc_sbrk ()
> #13 0x010f5b51 in _free_internal_nolock ()
> #14 0x01009a3a in emacs_blocked_free ()
> #15 0x01007640 in xfree ()

Thanks, this is a known problem, for which a fix already exists in the
development sources.

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com

> Date: Fri, 12 Oct 2012 14:20:04 +0200
>
> Thread 1 (Thread 7864.0x17ac):

> #0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

> #2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll
> #4 0x00a41fe0 in ?? ()
> #5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll
> #6 0x00000005 in ?? ()
> #7 0x013deddc in fd_info ()
> #8 0x013df250 in child_procs ()
> #9 0x00000005 in ?? ()
> #10 0x0141f81a in __register_frame_info ()
> #11 0x0102f72b in sys_close ()
> #12 0x010c2b6c in emacs_close ()
> #13 0x0101204c in deactivate_process ()
> #14 0x010141f2 in status_notify ()
> #15 0x010147cc in Fdelete_process ()

We are again in delete-process.

> (gdb) finish
> Run till exit from #0 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll

> Warning:
> Cannot insert breakpoint 0.
> Error accessing memory address 0x5: Input/output error.
>

> (gdb) q
> A debugging session is active.
>

> Inferior 1 [process 7864] will be detached.

>
> Quit anyway? (y or n) y

> Detaching from program: /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe, Pid 7864
> --8<---------------cut here---------------end--------------->8---
>
> Is this what you need?

Yes, but unfortunately it looks like GDB is unable to get out of the
system calls where Emacs is stuck.

> BTW, you asked me to go there, to find the .gdbinit file in some /src
> directory; but I don't find where... Could you show me where?

In the source distribution. Where that is depends on what binary you
use. Where did you get the binary?

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

> We are again in delete-process.
>
>> (gdb) finish
>> Run till exit from #0 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
>> Warning:
>> Cannot insert breakpoint 0.
>> Error accessing memory address 0x5: Input/output error.
>>

>> Is this what you need?
>
> Yes, but unfortunately it looks like GDB is unable to get out of the
> system calls where Emacs is stuck.
>
>> BTW, you asked me to go there, to find the .gdbinit file in some /src
>> directory; but I don't find where... Could you show me where?
>
> In the source distribution. Where that is depends on what binary you
> use. Where did you get the binary?

As I wrote in the preamble of the email:

>> I've been running Emacs 24.2 for 1.5 day so far with no crash... This is with
>> the version I got from
>> ftp://ftp.gnu.org/gnu/emacs/windows/emacs-24.2-bin-i386.zip, dated 7th of
>> October.

Wouldn't it be wise to always include the right .gdbinit file in every
compiled Emacs, even in release versions? That way, "you" (in the broad
sense) would always be sure users could give you the information you need to
further debug problems...

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com

> Date: Sat, 13 Oct 2012 09:45:50 +0200

>
> Eli Zaretskii wrote:
> > We are again in delete-process.

Btw, did you try to see if there's a Cygwin Bash process, which is a
sub-process of Emacs, at this point?

> Wouldn't it be wise to always include the right .gdbinit file in every
> compiled Emacs, even in release versions? That way, "you" (in the broad
> sense) would always be sure users could give you the information you need to
> further debug problems...

Official releases are provided with stripped executables, so a
.gdbinit file there will not help. Development snapshots (on the
http://alpha.gnu.org/gnu/emacs/windows/ page) and pretest binaries
(http://alpha.gnu.org/gnu/emacs/pretest/windows/), which are not
stripped of the debug info, already include .gdbinit to go with them.

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

>> Wouldn't it be wise to always include the right .gdbinit file in every
>> compiled Emacs, even in release versions? That way, "you" (in the broad
>> sense) would always be sure users could give you the information you need
>> to further debug problems...
>
> Official releases are provided with stripped executables, so a .gdbinit
> file there will not help.
> Development snapshots (on the http://alpha.gnu.org/gnu/emacs/windows/ page)
> and pretest binaries (http://alpha.gnu.org/gnu/emacs/pretest/windows/),
> which are not stripped of the debug info, already include .gdbinit to go
> with them.

Nope, pretest binaries found on
http://alpha.gnu.org/gnu/emacs/pretest/windows/ do not have any .gdbinit file
provided with them. That was my problem.

Development snapshots do well have a .gdbinit file but the latest binary
available is almost one month old (17th of Sep), and, as you said, I can't use
that .gdbinit file for the pretest binary of Emacs 24.2.

Is there any other, more recent, version of Emacs 24.1 or 2 which I could use,
avoiding the bugs which have been fixed in the last days or weeks?

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org, thierry....@gmail.com

> Date: Sun, 14 Oct 2012 10:23:41 +0200

>
> Eli Zaretskii wrote:
> >> Wouldn't it be wise to always include the right .gdbinit file in every
> >> compiled Emacs, even in release versions? That way, "you" (in the broad
> >> sense) would always be sure users could give you the information you need
> >> to further debug problems...
> >
> > Official releases are provided with stripped executables, so a .gdbinit
> > file there will not help.
> > Development snapshots (on the http://alpha.gnu.org/gnu/emacs/windows/ page)
> > and pretest binaries (http://alpha.gnu.org/gnu/emacs/pretest/windows/),
> > which are not stripped of the debug info, already include .gdbinit to go
> > with them.
>
> Nope, pretest binaries found on
> http://alpha.gnu.org/gnu/emacs/pretest/windows/ do not have any .gdbinit file
> provided with them. That was my problem.

Sorry, the pretest binaries are stripped as well, so .gdbinit is not
provided.

In a nutshell, a pretest is exactly like an official release, as long
as contents and stripped/non-stripped issues are concerned.

> Development snapshots do well have a .gdbinit file but the latest binary
> available is almost one month old (17th of Sep), and, as you said, I can't use
> that .gdbinit file for the pretest binary of Emacs 24.2.
>
> Is there any other, more recent, version of Emacs 24.1 or 2 which I could use,
> avoiding the bugs which have been fixed in the last days or weeks?

The most recent version is always the latest development snapshot.

[Dmitry Antipov]

This should be fixed in 110562.

Dmitry

[Drew Adams]

Another FYI/FWIW: I'm still getting seemingly random crashes frequently.

It does not seem to have anything to do with what I am doing, and seems
unrelated to anything special related to my setup (e.g. frames).

I can, for instance, perform a simple sequence of the same operations (e.g. M-x
set-variable foo) a few times in a row, and one of those times it might crash.

HTH.

[Eli Zaretskii]

> From: "Drew Adams" <drew....@oracle.com>
> Cc: <lek...@gmail.com>, <12...@debbugs.gnu.org>
> Date: Sat, 20 Oct 2012 16:45:49 -0700

As I already wrote so many times, without a meaningful backtrace this
doesn't help at all.

The original bug was reported to be fixed in revision 110562, 4 days
ago, so if you don't have a binary which includes that revision,
please wait until you do.

[Drew Adams]

> The original bug was reported to be fixed in revision 110562, 4 days
> ago, so if you don't have a binary which includes that revision,
> please wait until you do.

OK. FYI, the latest build I have, which still crashes, is from 10/15, which
presumably is a day older than that revision. (`emacs-version' gives no version
information, AFAICT.)

[Eli Zaretskii]

> From: "Drew Adams" <drew....@oracle.com>
> Cc: <f...@missioncriticalit.com>, <lek...@gmail.com>, <12...@debbugs.gnu.org>
> Date: Sun, 21 Oct 2012 09:15:05 -0700

>
> `emacs-version' gives no version information, AFAICT.

Try this:

M-: emacs-bzr-version RET

[Drew Adams]

> > `emacs-version' gives no version information, AFAICT.
>
> Try this:
> M-: emacs-bzr-version RET

Emacs tells me there is no such command. There are two functions that start
with that prefix: `emacs-bzr-version-bzr' and `emacs-bzr-version-dirstate', each
of which requires a DIR argument.

But it seems I can get the BZR version from starting a bug report:

110553 mon...@iro.umontreal.ca-20121015164957-6zms5w2js1xkldtg

So no, this version does not reflect your fix.

[Eli Zaretskii]

> From: "Drew Adams" <drew....@oracle.com>
> Cc: <f...@missioncriticalit.com>, <lek...@gmail.com>, <12...@debbugs.gnu.org>

> Date: Sun, 21 Oct 2012 11:10:24 -0700

>
> > > `emacs-version' gives no version information, AFAICT.
> >
> > Try this:
> > M-: emacs-bzr-version RET
>
> Emacs tells me there is no such command.

It's a variable, not a command or function.

> 110553 mon...@iro.umontreal.ca-20121015164957-6zms5w2js1xkldtg
>
> So no, this version does not reflect your fix.

It's not my fix, it's Dmitry's:

110562: Dmitry Antipov 2012-10-17 Do not verify indirection counters of killed buffers (Bug#12579).

[Drew Adams]

> > > M-: emacs-bzr-version RET

>
> It's a variable, not a command or function.

Oops. I mistook M-: for M-x.

> It's not my fix, it's Dmitry's:

Mille excuses. And thanks for the fix, Dmitry.

[Fabrice Niessen]

Hi Eli,

"Drew Adams" wrote:
>> > > M-: emacs-bzr-version RET
>>
>> It's a variable, not a command or function.
>
> Oops. I mistook M-: for M-x.

I don't have that in my Emacs version (taken from the FTP site of gnu.org):

GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600) of 2012-08-29 on MARVIN

Normal?

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: "'Eli Zaretskii'" <el...@gnu.org>, <lek...@gmail.com>, <12...@debbugs.gnu.org>
> Date: Sun, 21 Oct 2012 22:23:01 +0200

>
> "Drew Adams" wrote:
> >> > > M-: emacs-bzr-version RET
> >>
> >> It's a variable, not a command or function.
> >
> > Oops. I mistook M-: for M-x.
>
> I don't have that in my Emacs version (taken from the FTP site of gnu.org):
>
> GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600) of 2012-08-29 on MARVIN
>
> Normal?

Yes, this variable was introduced after 24.2 was released.

[Fabrice Niessen]

Hi Eli, hi Thierry,

Eli Zaretskii wrote:
> Btw, did you try to see if there's a Cygwin Bash process, which is a
> sub-process of Emacs, at this point?

I just got another infloop when completing the pattern in `helm-for-files'.

With the Emacs version:

GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-10-22 on DANI-PC

downloaded almost 2 weeks ago, and used since then, I can say I've dropped the
Emacs crash rate slightly under 1 per day.

In fact, IIRC, the problem is not even crashes, but infloops, mainly when
using Helm-for-files.

Here a backtrace:

--8<---------------cut here---------------start------------->8---
$ gdb -p 1400

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 1400
[New Thread 1400.0xedc]
[New Thread 1400.0x1a10]
[New Thread 1400.0x1a2c]
[New Thread 1400.0x20b8]
[New Thread 1400.0x1b10]
[New Thread 1400.0x52c]
[New Thread 1400.0x15b8]
[New Thread 1400.0x233c]
[New Thread 1400.0xb60]
[New Thread 1400.0xc88]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.
(gdb) thread apply all backtrace

Thread 10 (Thread 1400.0xc88):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x5b05ffd0 in ?? ()

#6 0x00000000 in ?? ()

Thread 9 (Thread 1400.0xb60):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000003bc in ?? ()

#4 0x00000000 in ?? ()

Thread 8 (Thread 1400.0x233c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
#5 0x0108d925 in _sys_read_ahead (fd=8) at w32.c:6079
#6 0x01033127 in reader_thread (arg=0x167dda0) at w32proc.c:838

#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 7 (Thread 1400.0x15b8):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
#5 0x0108d925 in _sys_read_ahead (fd=5) at w32.c:6079
#6 0x01033127 in reader_thread (arg=0x167dcf0) at w32proc.c:838

#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 6 (Thread 1400.0x52c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
#5 0x0108d925 in _sys_read_ahead (fd=7) at w32.c:6079
#6 0x01033127 in reader_thread (arg=0x167dd48) at w32proc.c:838

---Type <return> to continue, or q <return> to quit---

#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Thread 5 (Thread 1400.0x1b10):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000544 in ?? ()

#4 0x00000000 in ?? ()

Thread 4 (Thread 1400.0x20b8):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000664 in ?? ()

#4 0x00000000 in ?? ()

Thread 3 (Thread 1400.0x1a2c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll

#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x01148948 in w32_msg_pump (msg_buf=0x5b8cff54) at w32fns.c:2375
#4 0x01148b86 in w32_msg_worker@4 (arg=0x0) at w32fns.c:2601

#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Thread 2 (Thread 1400.0x1a10):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d21a in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8023f1 in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x00000000 in ?? ()

Thread 1 (Thread 1400.0xedc):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#4 0x00a42070 in ?? ()

#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll

#6 0x00000009 in ?? ()
#7 0x0000000c in ?? ()
#8 0x00000009 in ?? ()
#9 0x070686e0 in ?? ()
#10 0x0108d41e in sys_close (fd=9) at w32.c:5918
#11 0x011452a8 in emacs_close (fd=9) at sysdep.c:2082
#12 0x01029ce4 in deactivate_process (proc=117868261) at process.c:3924
#13 0x01022d92 in remove_process (proc=117868261) at process.c:735

---Type <return> to continue, or q <return> to quit---

#14 0x0102ffff in status_notify (deleting_process=0x70686e0) at process.c:6606
#15 0x01023263 in Fdelete_process (process=117868261) at process.c:850
#16 0x01013174 in eval_sub (form=61338758) at eval.c:2139
#17 0x0100f0aa in Fprogn (args=61037974) at eval.c:359
#18 0x01015cf1 in funcall_lambda (fun=61037910, nargs=1, arg_vector=0x829de0) at eval.c:2999
#19 0x01015600 in apply_lambda (fun=61037910, args=65551702) at eval.c:2883
#20 0x0101375b in eval_sub (form=65551678) at eval.c:2214
#21 0x0100f0aa in Fprogn (args=65551710) at eval.c:359
#22 0x01010582 in Fwhile (args=65551670) at eval.c:935
#23 0x01012d3c in eval_sub (form=65551662) at eval.c:2087
#24 0x0100f0aa in Fprogn (args=65551854) at eval.c:359
#25 0x01015cf1 in funcall_lambda (fun=65551910, nargs=0, arg_vector=0x82a160) at eval.c:2999
#26 0x01015600 in apply_lambda (fun=65551910, args=57358362) at eval.c:2883
#27 0x0101375b in eval_sub (form=65486334) at eval.c:2214
#28 0x0100f0aa in Fprogn (args=65484454) at eval.c:359
#29 0x01015cf1 in funcall_lambda (fun=65484422, nargs=0, arg_vector=0x82a360) at eval.c:2999
#30 0x01015600 in apply_lambda (fun=65484422, args=57358362) at eval.c:2883
#31 0x0101375b in eval_sub (form=65415350) at eval.c:2214
#32 0x0100f0aa in Fprogn (args=65415590) at eval.c:359
#33 0x0100ef2e in Fif (args=65415790) at eval.c:310
#34 0x01012d3c in eval_sub (form=65415782) at eval.c:2087
#35 0x0100f0aa in Fprogn (args=65415926) at eval.c:359
#36 0x01015cf1 in funcall_lambda (fun=65415902, nargs=1, arg_vector=0x82a6c0) at eval.c:2999
#37 0x01015600 in apply_lambda (fun=65415902, args=65416390) at eval.c:2883
#38 0x0101375b in eval_sub (form=65416374) at eval.c:2214
#39 0x0100f0aa in Fprogn (args=65416726) at eval.c:359
#40 0x01012d3c in eval_sub (form=65416782) at eval.c:2087
#41 0x01010a4e in Funwind_protect (args=65416790) at eval.c:1147
#42 0x01012d3c in eval_sub (form=65416798) at eval.c:2087
#43 0x0100f0aa in Fprogn (args=65416806) at eval.c:359
#44 0x01103187 in Fsave_current_buffer (args=65416806) at editfns.c:962
#45 0x01012d3c in eval_sub (form=65416814) at eval.c:2087
#46 0x0100f0aa in Fprogn (args=65416822) at eval.c:359
#47 0x010104e9 in Flet (args=65416830) at eval.c:913
#48 0x01012d3c in eval_sub (form=65416838) at eval.c:2087
#49 0x0100f0aa in Fprogn (args=65416974) at eval.c:359
#50 0x01012d3c in eval_sub (form=65416966) at eval.c:2087
#51 0x01010da4 in internal_lisp_condition_case (var=59048394, bodyform=65416966, handlers=65304670) at eval.c:1242
#52 0x01010abe in Fcondition_case (args=65417030) at eval.c:1183
#53 0x01012d3c in eval_sub (form=65417038) at eval.c:2087
#54 0x0100f0aa in Fprogn (args=65417046) at eval.c:359
#55 0x010104e9 in Flet (args=65417054) at eval.c:913
#56 0x01012d3c in eval_sub (form=65417062) at eval.c:2087
#57 0x0100f0aa in Fprogn (args=65417094) at eval.c:359
#58 0x01015cf1 in funcall_lambda (fun=65417070, nargs=0, arg_vector=0x82b4ec) at eval.c:2999
#59 0x01015391 in Ffuncall (nargs=1, args=0x82b4e8) at eval.c:2835
#60 0x0101385e in Fapply (nargs=2, args=0x82b4e8) at eval.c:2251

---Type <return> to continue, or q <return> to quit---

#61 0x01014c0e in Ffuncall (nargs=3, args=0x82b4e4) at eval.c:2755
#62 0x010e0f13 in exec_byte_code (bytestr=20931649, vector=20931701, maxdepth=16, args_template=57358362, nargs=0, args=0x0)
at bytecode.c:899
#63 0x010e02da in Fbyte_code (bytestr=20931649, vector=20931701, maxdepth=16) at bytecode.c:474
#64 0x01013258 in eval_sub (form=20931638) at eval.c:2145
#65 0x01010da4 in internal_lisp_condition_case (var=57358362, bodyform=20931638, handlers=20115822) at eval.c:1242
#66 0x010e1b50 in exec_byte_code (bytestr=20931393, vector=20931525, maxdepth=20, args_template=57358362, nargs=0, args=0x0)
at bytecode.c:1095
#67 0x01015e26 in funcall_lambda (fun=20931365, nargs=1, arg_vector=0x36b381a <__register_frame_info+57358362>) at eval.c:3006
#68 0x010152bf in Ffuncall (nargs=2, args=0x82bbd8) at eval.c:2823
#69 0x01014661 in call1 (fn=57400610, arg1=125161357) at eval.c:2568
#70 0x01040874 in timer_check_2 (timers=123649678, idle_timers=123649630) at keyboard.c:4386
#71 0x0104095d in timer_check () at keyboard.c:4453
#72 0x0103e7e6 in readable_events (flags=1) at keyboard.c:3350
#73 0x010472bb in get_input_pending (flags=1) at keyboard.c:6679
#74 0x01052a98 in detect_input_pending_run_timers (do_display=true) at keyboard.c:10272
#75 0x0102b77f in wait_reading_process_output (time_limit=8, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=57358362,
wait_proc=0x0, just_wait_proc=0) at process.c:4749
#76 0x010fb997 in sit_for (timeout=32, reading=true, display_option=1) at dispnew.c:5977
#77 0x0103baf8 in read_char (commandflag=1, nmaps=2, maps=0x82c070, prev_event=57358362, used_mouse_menu=0x82c143, end_time=0x0)
at keyboard.c:2668
#78 0x0104eef4 in read_key_sequence (keybuf=0x82c2c0, bufsize=30, prompt=57358362, dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9230
#79 0x010385c4 in command_loop_1 () at keyboard.c:1458
#80 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>, handlers=57408946, hfun=0x10378fd <cmd_error>)
at eval.c:1288
#81 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
#82 0x010108e3 in internal_catch (tag=57462578, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
#83 0x01037cc0 in command_loop () at keyboard.c:1138
#84 0x010372cb in recursive_edit_1 () at keyboard.c:778
#85 0x010be480 in read_minibuf (map=65516694, initial=57358362, prompt=65408209, expflag=false, histvar=57480154, histpos=0,
defalt=113852065, allow_props=false, inherit_input_method=true) at minibuf.c:674
#86 0x010bf18a in Fread_from_minibuffer (prompt=65408209, initial_contents=57358362, keymap=65516694, sys_read=57358362,
hist=57358362, default_value=113852065, inherit_input_method=57358386) at minibuf.c:976
#87 0x010134c8 in eval_sub (form=65375678) at eval.c:2163
#88 0x0100f0aa in Fprogn (args=65375766) at eval.c:359
#89 0x010104e9 in Flet (args=65374798) at eval.c:913
#90 0x01012d3c in eval_sub (form=65374806) at eval.c:2087
#91 0x0100f0aa in Fprogn (args=65374822) at eval.c:359
#92 0x0100eff8 in Fcond (args=65374846) at eval.c:337
#93 0x01012d3c in eval_sub (form=65374854) at eval.c:2087
#94 0x0100f0aa in Fprogn (args=65374862) at eval.c:359
#95 0x01010051 in FletX (args=65374870) at eval.c:843
#96 0x01012d3c in eval_sub (form=65374878) at eval.c:2087
#97 0x0100f0aa in Fprogn (args=65374902) at eval.c:359
#98 0x01103187 in Fsave_current_buffer (args=65374894) at editfns.c:962
#99 0x01012d3c in eval_sub (form=65374886) at eval.c:2087

---Type <return> to continue, or q <return> to quit---

#100 0x0100f0aa in Fprogn (args=65374942) at eval.c:359
#101 0x01015cf1 in funcall_lambda (fun=65374910, nargs=7, arg_vector=0x82ce40) at eval.c:2999
#102 0x01015600 in apply_lambda (fun=65374910, args=65342902) at eval.c:2883
#103 0x0101375b in eval_sub (form=65342894) at eval.c:2214
#104 0x01010a4e in Funwind_protect (args=65342966) at eval.c:1147
#105 0x01012d3c in eval_sub (form=65342958) at eval.c:2087
#106 0x0100f0aa in Fprogn (args=65343014) at eval.c:359
#107 0x01012d3c in eval_sub (form=65342982) at eval.c:2087
#108 0x01010a4e in Funwind_protect (args=65343030) at eval.c:1147
#109 0x01012d3c in eval_sub (form=65343022) at eval.c:2087
#110 0x0100f0aa in Fprogn (args=65340750) at eval.c:359
#111 0x010104e9 in Flet (args=65340758) at eval.c:913
#112 0x01012d3c in eval_sub (form=65340766) at eval.c:2087
#113 0x0100f0aa in Fprogn (args=65340774) at eval.c:359
#114 0x010104e9 in Flet (args=65340926) at eval.c:913
#115 0x01012d3c in eval_sub (form=65340934) at eval.c:2087
#116 0x01010da4 in internal_lisp_condition_case (var=59048394, bodyform=65340934, handlers=65343758) at eval.c:1242
#117 0x01010abe in Fcondition_case (args=65341014) at eval.c:1183
#118 0x01012d3c in eval_sub (form=65341022) at eval.c:2087
#119 0x01010a4e in Funwind_protect (args=65341038) at eval.c:1147
#120 0x01012d3c in eval_sub (form=65341030) at eval.c:2087
#121 0x0100f0aa in Fprogn (args=65341142) at eval.c:359
#122 0x010104e9 in Flet (args=65341150) at eval.c:913
#123 0x01012d3c in eval_sub (form=65341158) at eval.c:2087
#124 0x0100f0aa in Fprogn (args=65341166) at eval.c:359
#125 0x010108e3 in internal_catch (tag=57462578, func=0x100f055 <Fprogn>, arg=65344270) at eval.c:1059
#126 0x01010849 in Fcatch (args=65344262) at eval.c:1030
#127 0x01012d3c in eval_sub (form=65344254) at eval.c:2087
#128 0x0100f0aa in Fprogn (args=65341198) at eval.c:359
#129 0x01015cf1 in funcall_lambda (fun=65341174, nargs=9, arg_vector=0x82df04) at eval.c:2999
#130 0x01015391 in Ffuncall (nargs=10, args=0x82df00) at eval.c:2835
#131 0x010140a8 in Fapply (nargs=2, args=0x82dfb0) at eval.c:2308
#132 0x01012fcd in eval_sub (form=65349942) at eval.c:2111
#133 0x0100f0aa in Fprogn (args=65349966) at eval.c:359
#134 0x0100ef2e in Fif (args=65348614) at eval.c:310
#135 0x01012d3c in eval_sub (form=65350622) at eval.c:2087
#136 0x0100f0aa in Fprogn (args=65348678) at eval.c:359
#137 0x0100ef2e in Fif (args=65348662) at eval.c:310
#138 0x01012d3c in eval_sub (form=65348654) at eval.c:2087
#139 0x0100f0aa in Fprogn (args=65348686) at eval.c:359
#140 0x010104e9 in Flet (args=65348694) at eval.c:913
#141 0x01012d3c in eval_sub (form=65348702) at eval.c:2087
#142 0x0100f0aa in Fprogn (args=65348734) at eval.c:359
#143 0x01015cf1 in funcall_lambda (fun=65348710, nargs=9, arg_vector=0x82e674) at eval.c:2999
#144 0x01015391 in Ffuncall (nargs=10, args=0x82e670) at eval.c:2835
#145 0x010140a8 in Fapply (nargs=2, args=0x82e720) at eval.c:2308
#146 0x01012fcd in eval_sub (form=65349798) at eval.c:2111

---Type <return> to continue, or q <return> to quit---

#147 0x0100f0aa in Fprogn (args=65350494) at eval.c:359
#148 0x01015cf1 in funcall_lambda (fun=65350510, nargs=0, arg_vector=0x82e964) at eval.c:2999
#149 0x01015391 in Ffuncall (nargs=1, args=0x82e960) at eval.c:2835
#150 0x01012fcd in eval_sub (form=65316782) at eval.c:2111
#151 0x01010a4e in Funwind_protect (args=65316798) at eval.c:1147
#152 0x01012d3c in eval_sub (form=65316774) at eval.c:2087
#153 0x0100f0aa in Fprogn (args=65314910) at eval.c:359
#154 0x01015cf1 in funcall_lambda (fun=65314974, nargs=2, arg_vector=0x82ec20) at eval.c:2999
#155 0x01015600 in apply_lambda (fun=65314974, args=65350606) at eval.c:2883
#156 0x0101375b in eval_sub (form=65350598) at eval.c:2214
#157 0x0100ef11 in Fif (args=65348614) at eval.c:309
#158 0x01012d3c in eval_sub (form=65350622) at eval.c:2087
#159 0x0100f0aa in Fprogn (args=65348678) at eval.c:359
#160 0x0100ef2e in Fif (args=65348662) at eval.c:310
#161 0x01012d3c in eval_sub (form=65348654) at eval.c:2087
#162 0x0100f0aa in Fprogn (args=65348686) at eval.c:359
#163 0x010104e9 in Flet (args=65348694) at eval.c:913
#164 0x01012d3c in eval_sub (form=65348702) at eval.c:2087
#165 0x0100f0aa in Fprogn (args=65348734) at eval.c:359
#166 0x01015cf1 in funcall_lambda (fun=65348710, nargs=4, arg_vector=0x82f290) at eval.c:2999
#167 0x01015600 in apply_lambda (fun=65348710, args=65337494) at eval.c:2883
#168 0x0101375b in eval_sub (form=65337486) at eval.c:2214
#169 0x0100f0aa in Fprogn (args=65337614) at eval.c:359
#170 0x01015cf1 in funcall_lambda (fun=65337670, nargs=2, arg_vector=0x82f4a0) at eval.c:2999
#171 0x01015600 in apply_lambda (fun=65337670, args=67190814) at eval.c:2883
#172 0x0101375b in eval_sub (form=67190830) at eval.c:2214
#173 0x0100f0aa in Fprogn (args=67190798) at eval.c:359
#174 0x010104e9 in Flet (args=67190878) at eval.c:913
#175 0x01012d3c in eval_sub (form=67193438) at eval.c:2087
#176 0x0100f0aa in Fprogn (args=64965230) at eval.c:359
#177 0x01015cf1 in funcall_lambda (fun=60034390, nargs=0, arg_vector=0x82f954) at eval.c:2999
#178 0x01015391 in Ffuncall (nargs=1, args=0x82f950) at eval.c:2835
#179 0x010145d8 in apply1 (fn=60953962, arg=57358362) at eval.c:2535
#180 0x010e4c85 in Fcall_interactively (function=60953962, record_flag=57358362, keys=57379757) at callint.c:377
#181 0x01014f7d in Ffuncall (nargs=4, args=0x82fb60) at eval.c:2781
#182 0x010146db in call3 (fn=57469674, arg1=60953962, arg2=57358362, arg3=57358362) at eval.c:2599
#183 0x010529fe in Fcommand_execute (cmd=60953962, record_flag=57358362, keys=57358362, special=57358362) at keyboard.c:10240
#184 0x01038e13 in command_loop_1 () at keyboard.c:1586
#185 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>, handlers=57408946, hfun=0x10378fd <cmd_error>)
at eval.c:1288
#186 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
#187 0x010108e3 in internal_catch (tag=57398802, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
#188 0x01037d11 in command_loop () at keyboard.c:1146
#189 0x010372cb in recursive_edit_1 () at keyboard.c:778
#190 0x010375f8 in Frecursive_edit () at keyboard.c:842
#191 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552
(gdb) thread 1
[Switching to thread 1 (Thread 1400.0xedc)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) finish
Run till exit from #0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(No answer until I killed emacs.exe from the Task Manager)

[Inferior 1 (process 1400) exited with code 01]
(gdb)
--8<---------------cut here---------------end--------------->8---

A side-note about some processes running at the time of the problem:

| | Before killing Emacs | After killing Emacs | Size per process (in KB) |
|----------------+----------------------+---------------------+--------------------------|
| es.exe | 7 | 7 | 72 |
| Everything.exe | 1 | 1 | 20652 |
| screen.exe | 2 | 2 | 3800 |
| zsh.exe | 2 | 2 | 5400 |

I was expecting differences as I killed the Emacs process (89000 KB) along
with its "process subtree", but no...

I don't understand the 2 screen processes (I just see 1), but that must
explain the 2 zsh processes...

HTH all of us...

Best regards,
Fabrice

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Mon, 05 Nov 2012 16:48:04 +0100

>
> (gdb) thread apply all backtrace

This indicates you had 3 network streams that Emacs was reading from.
Any idea which connections were those?

> #10 0x0108d41e in sys_close (fd=9) at w32.c:5918
> #11 0x011452a8 in emacs_close (fd=9) at sysdep.c:2082
> #12 0x01029ce4 in deactivate_process (proc=117868261) at process.c:3924
> #13 0x01022d92 in remove_process (proc=117868261) at process.c:735

Same as before: Emacs waits for some subprocess to shut down.

Next time, please type "xbacktrace" and show the Lisp backtrace it
produces. (You will need the .gdbinit file from the source
repository, and you will need to type "source .gdbinit" before
invoking "xbacktrace".)

> I don't understand the 2 screen processes (I just see 1), but that must
> explain the 2 zsh processes...

I don't understand even the single screen.exe: what does that do?

[Fabrice Niessen]

Hello Eli,

Eli Zaretskii wrote:
>> (gdb) thread apply all backtrace
>
> This indicates you had 3 network streams that Emacs was reading from.
> Any idea which connections were those?

The "only" things I use Emacs for are:

- editing local files (found on my computer, not on a network share)
- reading and composing mails with Gnus

I'm not using W3M nor IRC nor ...

However, if process communications are seen as network streams, then some of
them could be used for talking to the "es.exe" process ("Everything", used by
Helm-for-files, as a replacement for the Unix "locate" command).

>> #10 0x0108d41e in sys_close (fd=9) at w32.c:5918
>> #11 0x011452a8 in emacs_close (fd=9) at sysdep.c:2082
>> #12 0x01029ce4 in deactivate_process (proc=117868261) at process.c:3924
>> #13 0x01022d92 in remove_process (proc=117868261) at process.c:735
>
> Same as before: Emacs waits for some subprocess to shut down.
>
> Next time, please type "xbacktrace" and show the Lisp backtrace it
> produces. (You will need the .gdbinit file from the source
> repository, and you will need to type "source .gdbinit" before
> invoking "xbacktrace".)

I just downloaded the .gdbinit found in
http://ftp.gnu.org/gnu/emacs/emacs-24.2.tar.xz (from... 27-Aug-2012), as I
just had a similar problem (infloop when filling Helm-for-files pattern).

QUESTION -- Is it therein I'm supposed to fetch the .gdbinit from?

However, it does not seem that I can do that as easily: this ain't compatible
with the GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-10-22 on DANI-PC.

But I had to take a recently compiled Emacs from
https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 (to be exact, the
version emacs-trunk-r110618-w32-i386.zip, on 22-Oct-2012), as there is no new
official version of Emacs for Windows since a while...

- On http://alpha.gnu.org/gnu/emacs/pretest/windows/
Latest is from 26-Aug-2012, but STRIPPED

- On http://alpha.gnu.org/gnu/emacs/windows/
Latest is from 17-Sep-2012, but does not contain the fixes for the often
occurring crashes

- On ftp://ftp.gnu.org/gnu/emacs/windows/
Latest is from 07-Oct-2012, but STRIPPED anyway

Here the trace... disappointing...

--8<---------------cut here---------------start------------->8---
$ gdb -p 6156

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 6156
[New Thread 6156.0x5a4]
[New Thread 6156.0x2190]
[New Thread 6156.0x1ee0]
[New Thread 6156.0xef4]
[New Thread 6156.0x1028]
[New Thread 6156.0x2350]
[New Thread 6156.0x1ae0]
[New Thread 6156.0x17f8]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

warning: Expression is not an assignment (and might have no effect)
warning: Expression is not an assignment (and might have no effect)
Warning: /cygdrive/c/Program Files/Emacs-24.2/bin/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
.gdbinit:1273: Error in sourced command file:
No symbol "gdb_gctypebits" in current context.

(gdb) thread apply all backtrace

Thread 8 (Thread 6156.0x17f8):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()
#5 0x5b05ffd0 in ?? ()
#6 0x00000000 in ?? ()

Lisp Backtrace:
(gdb) No symbol "gdb_use_union" in current context.


Thread 8 (Thread 6156.0x17f8):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()
#5 0x5b05ffd0 in ?? ()
#6 0x00000000 in ?? ()

Lisp Backtrace:
(gdb) No symbol "gdb_use_union" in current context.
xbacktrace
(gdb) No symbol "gdb_use_union" in current context.

(gdb) No symbol "gdb_use_union" in current context.

q
A debugging session is active.

Inferior 1 [process 6156] will be detached.

Quit anyway? (y or n) y

error return /netrel/src/gdb-7.5.50-1/gdb/windows-nat.c:1392 was 31
Quitting: Can't detach process 6156 (error 5)
--8<---------------cut here---------------end--------------->8---

>> I don't understand the 2 screen processes (I just see 1), but that must
>> explain the 2 zsh processes...
>
> I don't understand even the single screen.exe: what does that do?

GNU screen is a terminal multiplexer: it's like having multiple "zsh" windows
open, but there are here seen as kind of tabs. You have on screen process and
switch between different terminal windows.

It's a bit like StumpWM, if you know it, but for shell windows.

Best regards,
Fabrice Niessen

[Fabrice Niessen]

Eli, Thierry,

> Eli Zaretskii wrote:
>>> (gdb) thread apply all backtrace
>>
>> This indicates you had 3 network streams that Emacs was reading from.
>> Any idea which connections were those?
>
> The "only" things I use Emacs for are:
>
> - editing local files (found on my computer, not on a network share)
> - reading and composing mails with Gnus
>
> I'm not using W3M nor IRC nor ...
>
> However, if process communications are seen as network streams, then some of
> them could be used for talking to the "es.exe" process ("Everything", used by
> Helm-for-files, as a replacement for the Unix "locate" command).

Got once again an infloop. Once again when completing the pattern for
Helm-for-files.

Though, now, I've added some extra tracing to try and understand what's
happening: I run the following command in a terminal window

while true; do ps aux | grep "/es"; sleep 1; echo ""; done

I get such "logs":

--8<---------------cut here---------------start------------->8---
7108 1 7108 6464 ? 1007 11:37:22 /cygdrive/d/home/sva/winbin/es
7108 1 7108 6464 ? 1007 11:37:22 /cygdrive/d/home/sva/winbin/es
7108 1 7108 6464 ? 1007 11:37:22 /cygdrive/d/home/sva/winbin/es

(nothing for several minutes)

8036 1 8036 7164 ? 1007 11:49:01 /cygdrive/d/home/sva/winbin/es
--8<---------------cut here---------------end--------------->8---

Sometimes, "es" lines are duplicated, meaning that the "es" process is running
for more than one second.

--8<---------------cut here---------------start------------->8---
(nothing for several minutes)

5620 1 5620 5756 ? 1007 11:49:38 /cygdrive/d/home/sva/winbin/es

(infloop)
--8<---------------cut here---------------end--------------->8---

Now, I got the infloop with the above last line: "es" disappeared while I was
still (trying to) complete the filename at the pattern prompt. That must
explain, somehow, the problem: "es" is not there anymore, but Emacs still
waits on it.

More hints? I don't have right now: the file pattern has nothing special, is
not always the same, etc.

>>> I don't understand the 2 screen processes (I just see 1), but that must
>>> explain the 2 zsh processes...

I've just seen that it's "normal" to get 2 screen processes, and 2 zsh
processes per tab. No weirdness there, thus.

Best regards,
Fabrice Niessen

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: thierry....@gmail.com, drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Tue, 06 Nov 2012 10:42:37 +0100
>
> Hello Eli,

>
> Eli Zaretskii wrote:
> >> (gdb) thread apply all backtrace
> >
> > This indicates you had 3 network streams that Emacs was reading from.
> > Any idea which connections were those?
>
> The "only" things I use Emacs for are:
>
> - editing local files (found on my computer, not on a network share)
> - reading and composing mails with Gnus

Strange.

> However, if process communications are seen as network streams

No, the backtrace clearly shows that we are communicating via Winsock:

#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
#5 0x0108d925 in _sys_read_ahead (fd=8) at w32.c:6079
#6 0x01033127 in reader_thread (arg=0x167dda0) at w32proc.c:838

See that call to WSACancelAsyncRequest?

> > Next time, please type "xbacktrace" and show the Lisp backtrace it
> > produces. (You will need the .gdbinit file from the source
> > repository, and you will need to type "source .gdbinit" before
> > invoking "xbacktrace".)
>
> I just downloaded the .gdbinit found in
> http://ftp.gnu.org/gnu/emacs/emacs-24.2.tar.xz (from... 27-Aug-2012), as I
> just had a similar problem (infloop when filling Helm-for-files pattern).
>
> QUESTION -- Is it therein I'm supposed to fetch the .gdbinit from?

You need to get it from the same source distribution as the one used
for building Emacs. If you are using v24.2 (not 24.2.50 or some
such), then the above is indeed the right .gdbinit.

> However, it does not seem that I can do that as easily: this ain't compatible
> with the GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-10-22 on DANI-PC.

I don't expect it to be: 24.2.50 is a development snapshot, and a lot
was changed in the internal data structures since 24.2 was released.

> But I had to take a recently compiled Emacs from
> https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 (to be exact, the
> version emacs-trunk-r110618-w32-i386.zip, on 22-Oct-2012), as there is no new
> official version of Emacs for Windows since a while...

Then you can get a matching .gdbinit from the bzr repository here:

http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/src/.gdbinit

> >> I don't understand the 2 screen processes (I just see 1), but that must
> >> explain the 2 zsh processes...
> >

> > I don't understand even the single screen.exe: what does that do?
>
> GNU screen is a terminal multiplexer

I know what GNU screen is, I just didn't expect to see it on a Windows
machine that uses a native Windows build of Emacs. Is screen.exe a
Cygwin build of screen? Are you using it to run several versions of
Emacs?

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>

>> Eli Zaretskii wrote:
>> >> (gdb) thread apply all backtrace
>> >
>> > This indicates you had 3 network streams that Emacs was reading from.
>> > Any idea which connections were those?
>>
>> The "only" things I use Emacs for are:
>>
>> - editing local files (found on my computer, not on a network share)
>> - reading and composing mails with Gnus
>
> Strange.
>
>> However, if process communications are seen as network streams
>
> No, the backtrace clearly shows that we are communicating via Winsock:
>
> #4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
> #5 0x0108d925 in _sys_read_ahead (fd=8) at w32.c:6079
> #6 0x01033127 in reader_thread (arg=0x167dda0) at w32proc.c:838
>
> See that call to WSACancelAsyncRequest?

No idea on how to interpret that... I really use Emacs for the above usage...

>> > Next time, please type "xbacktrace" and show the Lisp backtrace it
>> > produces. (You will need the .gdbinit file from the source
>> > repository, and you will need to type "source .gdbinit" before
>> > invoking "xbacktrace".)
>>
>> I just downloaded the .gdbinit found in
>> http://ftp.gnu.org/gnu/emacs/emacs-24.2.tar.xz (from... 27-Aug-2012), as I
>> just had a similar problem (infloop when filling Helm-for-files pattern).
>>
>> QUESTION -- Is it therein I'm supposed to fetch the .gdbinit from?
>
> You need to get it from the same source distribution as the one used
> for building Emacs. If you are using v24.2 (not 24.2.50 or some
> such), then the above is indeed the right .gdbinit.
>
>> However, it does not seem that I can do that as easily: this ain't compatible
>> with the GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-10-22 on DANI-PC.
>
> I don't expect it to be: 24.2.50 is a development snapshot, and a lot
> was changed in the internal data structures since 24.2 was released.
>
>> But I had to take a recently compiled Emacs from
>> https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8 (to be exact, the
>> version emacs-trunk-r110618-w32-i386.zip, on 22-Oct-2012), as there is no new
>> official version of Emacs for Windows since a while...
>
> Then you can get a matching .gdbinit from the bzr repository here:
>
> http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/src/.gdbinit

Thanks for giving me the pointer to the right file!

>> >> I don't understand the 2 screen processes (I just see 1), but that must
>> >> explain the 2 zsh processes...
>> >
>> > I don't understand even the single screen.exe: what does that do?
>>
>> GNU screen is a terminal multiplexer
>
> I know what GNU screen is, I just didn't expect to see it on a Windows
> machine that uses a native Windows build of Emacs. Is screen.exe a
> Cygwin build of screen? Are you using it to run several versions of
> Emacs?

Of course you know it.

Why mentioning it? Because screen runs Z shells, and I sometimes had shell
messages (already mentioned in the past) when using Helm-for-files.

But, here, no, I don't use Emacs in screen in any form. I only use screen for
shell windows, no more.

Best regards,
Fabrice

[Fabrice Niessen]

Hi Eli,

New infloop. Same context (completing pattern for Helm-for-files). This time,
with a correct .gdbinit file.

--8<---------------cut here---------------start------------->8---
$ gdb -p 3956

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 3956
[New Thread 3956.0x1fbc]
[New Thread 3956.0xc28]
[New Thread 3956.0x984]
[New Thread 3956.0x2224]
[New Thread 3956.0x1674]
[New Thread 3956.0x74]
[New Thread 3956.0x568]
[New Thread 3956.0x22ac]
[New Thread 3956.0x15c4]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Warning: /cygdrive/c/Program Files/Emacs-24.2/bin/../lwlib: No such file or directory.

Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x10013b6: file emacs.c, line 317.
Temporary breakpoint 2 at 0x11441d5: file sysdep.c, line 794.

(gdb) thread apply all backtrace

Thread 9 (Thread 3956.0x15c4):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x5ae3ffd0 in ?? ()

#6 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)

---Type <return> to continue, or q <return> to quit---

"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 8 (Thread 3956.0x22ac):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000158 in ?? ()
#4 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)

---Type <return> to continue, or q <return> to quit---

"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 7 (Thread 3956.0x568):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x77dc8631 in WmiFreeBuffer () from /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL
#4 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#5 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)

---Type <return> to continue, or q <return> to quit---

"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 6 (Thread 3956.0x74):

---Type <return> to continue, or q <return> to quit---

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000005ac in ?? ()
#4 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)

---Type <return> to continue, or q <return> to quit---

0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 5 (Thread 3956.0x1674):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll

#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0108d925 in _sys_read_ahead (fd=5) at w32.c:6079
#6 0x01033127 in reader_thread (arg=0x167dcf0) at w32proc.c:838
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#8 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)

---Type <return> to continue, or q <return> to quit---

"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 4 (Thread 3956.0x2224):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000658 in ?? ()
#4 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)

---Type <return> to continue, or q <return> to quit---

"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 3 (Thread 3956.0x984):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

---Type <return> to continue, or q <return> to quit---

#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x01148948 in w32_msg_pump (msg_buf=0x5b8cff54) at w32fns.c:2375
#4 0x01148b86 in w32_msg_worker@4 (arg=0x0) at w32fns.c:2601
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#6 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)

---Type <return> to continue, or q <return> to quit---

"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 2 (Thread 3956.0xc28):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91d21a in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8023f1 in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000000 in ?? ()

Lisp Backtrace:
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)

---Type <return> to continue, or q <return> to quit---

"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 1 (Thread 3956.0x1fbc):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#4 0x00a41fbc in ?? ()

#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll

#6 0x00000004 in ?? ()
#7 0x00000009 in ?? ()
#8 0x00000004 in ?? ()
#9 0x03e25e70 in ?? ()
#10 0x0108d41e in sys_close (fd=4) at w32.c:5918
#11 0x011452a8 in emacs_close (fd=4) at sysdep.c:2082
#12 0x01029ce4 in deactivate_process (proc=65166965) at process.c:3924
#13 0x01022d92 in remove_process (proc=65166965) at process.c:735
#14 0x0102ffff in status_notify (deleting_process=0x3e25e70) at process.c:6606
#15 0x01023263 in Fdelete_process (process=65166965) at process.c:850
#16 0x01013174 in eval_sub (form=61248718) at eval.c:2139
#17 0x0100f0aa in Fprogn (args=82271118) at eval.c:359
#18 0x01015cf1 in funcall_lambda (fun=82271182, nargs=1, arg_vector=0x829de0) at eval.c:2999

---Type <return> to continue, or q <return> to quit---

#19 0x01015600 in apply_lambda (fun=82271182, args=81429566) at eval.c:2883
#20 0x0101375b in eval_sub (form=81429542) at eval.c:2214
#21 0x0100f0aa in Fprogn (args=81429574) at eval.c:359
#22 0x01010582 in Fwhile (args=81429534) at eval.c:935
#23 0x01012d3c in eval_sub (form=81429526) at eval.c:2087
#24 0x0100f0aa in Fprogn (args=81429718) at eval.c:359
#25 0x01015cf1 in funcall_lambda (fun=81429774, nargs=0, arg_vector=0x82a160) at eval.c:2999
#26 0x01015600 in apply_lambda (fun=81429774, args=57358362) at eval.c:2883
#27 0x0101375b in eval_sub (form=81116406) at eval.c:2214
#28 0x0100f0aa in Fprogn (args=81109406) at eval.c:359
#29 0x01015cf1 in funcall_lambda (fun=81109374, nargs=0, arg_vector=0x82a360) at eval.c:2999
#30 0x01015600 in apply_lambda (fun=81109374, args=57358362) at eval.c:2883
#31 0x0101375b in eval_sub (form=73914550) at eval.c:2214
#32 0x0100f0aa in Fprogn (args=73914790) at eval.c:359
#33 0x0100ef2e in Fif (args=73914990) at eval.c:310
#34 0x01012d3c in eval_sub (form=73914982) at eval.c:2087
#35 0x0100f0aa in Fprogn (args=73915126) at eval.c:359
#36 0x01015cf1 in funcall_lambda (fun=73915102, nargs=1, arg_vector=0x82a6c0) at eval.c:2999
#37 0x01015600 in apply_lambda (fun=73915102, args=73915590) at eval.c:2883
#38 0x0101375b in eval_sub (form=73915574) at eval.c:2214
#39 0x0100f0aa in Fprogn (args=73915926) at eval.c:359
#40 0x01012d3c in eval_sub (form=73915982) at eval.c:2087
#41 0x01010a4e in Funwind_protect (args=73915990) at eval.c:1147
#42 0x01012d3c in eval_sub (form=73915998) at eval.c:2087
#43 0x0100f0aa in Fprogn (args=73916006) at eval.c:359
#44 0x01103187 in Fsave_current_buffer (args=73916006) at editfns.c:962
#45 0x01012d3c in eval_sub (form=73916014) at eval.c:2087
#46 0x0100f0aa in Fprogn (args=73916022) at eval.c:359
#47 0x010104e9 in Flet (args=73916030) at eval.c:913
#48 0x01012d3c in eval_sub (form=73916038) at eval.c:2087
#49 0x0100f0aa in Fprogn (args=73916174) at eval.c:359
#50 0x01012d3c in eval_sub (form=73916166) at eval.c:2087
#51 0x01010da4 in internal_lisp_condition_case (var=59048394, bodyform=73916166, handlers=83243014) at eval.c:1242
#52 0x01010abe in Fcondition_case (args=73916230) at eval.c:1183
#53 0x01012d3c in eval_sub (form=73916238) at eval.c:2087
#54 0x0100f0aa in Fprogn (args=73916246) at eval.c:359
#55 0x010104e9 in Flet (args=73916254) at eval.c:913
#56 0x01012d3c in eval_sub (form=73916262) at eval.c:2087
#57 0x0100f0aa in Fprogn (args=73916294) at eval.c:359
#58 0x01015cf1 in funcall_lambda (fun=73916270, nargs=0, arg_vector=0x82b4ec) at eval.c:2999

#59 0x01015391 in Ffuncall (nargs=1, args=0x82b4e8) at eval.c:2835
#60 0x0101385e in Fapply (nargs=2, args=0x82b4e8) at eval.c:2251

#61 0x01014c0e in Ffuncall (nargs=3, args=0x82b4e4) at eval.c:2755
#62 0x010e0f13 in exec_byte_code (bytestr=20931649, vector=20931701, maxdepth=16, args_template=57358362, nargs=0, args=0x0)
at bytecode.c:899
#63 0x010e02da in Fbyte_code (bytestr=20931649, vector=20931701, maxdepth=16) at bytecode.c:474
#64 0x01013258 in eval_sub (form=20931638) at eval.c:2145

---Type <return> to continue, or q <return> to quit---

#65 0x01010da4 in internal_lisp_condition_case (var=57358362, bodyform=20931638, handlers=20115822) at eval.c:1242
#66 0x010e1b50 in exec_byte_code (bytestr=20931393, vector=20931525, maxdepth=20, args_template=57358362, nargs=0, args=0x0)
at bytecode.c:1095
#67 0x01015e26 in funcall_lambda (fun=20931365, nargs=1, arg_vector=0x36b381a <__register_frame_info+57358362>) at eval.c:3006
#68 0x010152bf in Ffuncall (nargs=2, args=0x82bbd8) at eval.c:2823

#69 0x01014661 in call1 (fn=57400610, arg1=68836981) at eval.c:2568
#70 0x01040874 in timer_check_2 (timers=110430494, idle_timers=103429038) at keyboard.c:4386

#71 0x0104095d in timer_check () at keyboard.c:4453
#72 0x0103e7e6 in readable_events (flags=1) at keyboard.c:3350
#73 0x010472bb in get_input_pending (flags=1) at keyboard.c:6679
#74 0x01052a98 in detect_input_pending_run_timers (do_display=true) at keyboard.c:10272
#75 0x0102b77f in wait_reading_process_output (time_limit=8, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=57358362,
wait_proc=0x0, just_wait_proc=0) at process.c:4749
#76 0x010fb997 in sit_for (timeout=32, reading=true, display_option=1) at dispnew.c:5977
#77 0x0103baf8 in read_char (commandflag=1, nmaps=2, maps=0x82c070, prev_event=57358362, used_mouse_menu=0x82c143, end_time=0x0)
at keyboard.c:2668
#78 0x0104eef4 in read_key_sequence (keybuf=0x82c2c0, bufsize=30, prompt=57358362, dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9230
#79 0x010385c4 in command_loop_1 () at keyboard.c:1458
#80 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>, handlers=57408946, hfun=0x10378fd <cmd_error>)
at eval.c:1288
#81 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
#82 0x010108e3 in internal_catch (tag=57462578, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
#83 0x01037cc0 in command_loop () at keyboard.c:1138
#84 0x010372cb in recursive_edit_1 () at keyboard.c:778

#85 0x010be480 in read_minibuf (map=78807830, initial=57358362, prompt=76689313, expflag=false, histvar=57480154, histpos=0,
defalt=113959521, allow_props=false, inherit_input_method=true) at minibuf.c:674
#86 0x010bf18a in Fread_from_minibuffer (prompt=76689313, initial_contents=57358362, keymap=78807830, sys_read=57358362,
hist=57358362, default_value=113959521, inherit_input_method=57358386) at minibuf.c:976
#87 0x010134c8 in eval_sub (form=80489918) at eval.c:2163
#88 0x0100f0aa in Fprogn (args=80490006) at eval.c:359
#89 0x010104e9 in Flet (args=80489038) at eval.c:913
#90 0x01012d3c in eval_sub (form=80489046) at eval.c:2087
#91 0x0100f0aa in Fprogn (args=80489062) at eval.c:359
#92 0x0100eff8 in Fcond (args=80489086) at eval.c:337
#93 0x01012d3c in eval_sub (form=80489094) at eval.c:2087
#94 0x0100f0aa in Fprogn (args=80489102) at eval.c:359
#95 0x01010051 in FletX (args=80489110) at eval.c:843
#96 0x01012d3c in eval_sub (form=80489118) at eval.c:2087
#97 0x0100f0aa in Fprogn (args=80489142) at eval.c:359
#98 0x01103187 in Fsave_current_buffer (args=80489134) at editfns.c:962
#99 0x01012d3c in eval_sub (form=80489126) at eval.c:2087
#100 0x0100f0aa in Fprogn (args=80489182) at eval.c:359
#101 0x01015cf1 in funcall_lambda (fun=80489150, nargs=7, arg_vector=0x82ce40) at eval.c:2999
#102 0x01015600 in apply_lambda (fun=80489150, args=83389990) at eval.c:2883
#103 0x0101375b in eval_sub (form=83389998) at eval.c:2214
#104 0x01010a4e in Funwind_protect (args=83389926) at eval.c:1147

---Type <return> to continue, or q <return> to quit---

#105 0x01012d3c in eval_sub (form=83389934) at eval.c:2087
#106 0x0100f0aa in Fprogn (args=83389878) at eval.c:359
#107 0x01012d3c in eval_sub (form=83389910) at eval.c:2087
#108 0x01010a4e in Funwind_protect (args=83389862) at eval.c:1147
#109 0x01012d3c in eval_sub (form=83389870) at eval.c:2087
#110 0x0100f0aa in Fprogn (args=81915262) at eval.c:359
#111 0x010104e9 in Flet (args=81915270) at eval.c:913
#112 0x01012d3c in eval_sub (form=81915278) at eval.c:2087
#113 0x0100f0aa in Fprogn (args=81915286) at eval.c:359
#114 0x010104e9 in Flet (args=81915438) at eval.c:913
#115 0x01012d3c in eval_sub (form=81915446) at eval.c:2087
#116 0x01010da4 in internal_lisp_condition_case (var=59048394, bodyform=81915446, handlers=83391758) at eval.c:1242
#117 0x01010abe in Fcondition_case (args=81915526) at eval.c:1183
#118 0x01012d3c in eval_sub (form=81915534) at eval.c:2087
#119 0x01010a4e in Funwind_protect (args=81915550) at eval.c:1147
#120 0x01012d3c in eval_sub (form=81915542) at eval.c:2087
#121 0x0100f0aa in Fprogn (args=81915654) at eval.c:359
#122 0x010104e9 in Flet (args=81915662) at eval.c:913
#123 0x01012d3c in eval_sub (form=81915670) at eval.c:2087
#124 0x0100f0aa in Fprogn (args=81915678) at eval.c:359
#125 0x010108e3 in internal_catch (tag=57462578, func=0x100f055 <Fprogn>, arg=83390926) at eval.c:1059
#126 0x01010849 in Fcatch (args=83390934) at eval.c:1030
#127 0x01012d3c in eval_sub (form=83390942) at eval.c:2087
#128 0x0100f0aa in Fprogn (args=81915710) at eval.c:359
#129 0x01015cf1 in funcall_lambda (fun=81915686, nargs=9, arg_vector=0x82df04) at eval.c:2999

#130 0x01015391 in Ffuncall (nargs=10, args=0x82df00) at eval.c:2835
#131 0x010140a8 in Fapply (nargs=2, args=0x82dfb0) at eval.c:2308

#132 0x01012fcd in eval_sub (form=83317262) at eval.c:2111
#133 0x0100f0aa in Fprogn (args=83317230) at eval.c:359
#134 0x0100ef2e in Fif (args=83345062) at eval.c:310
#135 0x01012d3c in eval_sub (form=83345070) at eval.c:2087
#136 0x0100f0aa in Fprogn (args=83344998) at eval.c:359
#137 0x0100ef2e in Fif (args=83345014) at eval.c:310
#138 0x01012d3c in eval_sub (form=83345022) at eval.c:2087
#139 0x0100f0aa in Fprogn (args=83344990) at eval.c:359
#140 0x010104e9 in Flet (args=83344982) at eval.c:913
#141 0x01012d3c in eval_sub (form=83344974) at eval.c:2087
#142 0x0100f0aa in Fprogn (args=83344942) at eval.c:359
#143 0x01015cf1 in funcall_lambda (fun=83344966, nargs=9, arg_vector=0x82e674) at eval.c:2999

#144 0x01015391 in Ffuncall (nargs=10, args=0x82e670) at eval.c:2835
#145 0x010140a8 in Fapply (nargs=2, args=0x82e720) at eval.c:2308

#146 0x01012fcd in eval_sub (form=83317406) at eval.c:2111
#147 0x0100f0aa in Fprogn (args=83345198) at eval.c:359
#148 0x01015cf1 in funcall_lambda (fun=83345182, nargs=0, arg_vector=0x82e964) at eval.c:2999

#149 0x01015391 in Ffuncall (nargs=1, args=0x82e960) at eval.c:2835

#150 0x01012fcd in eval_sub (form=83157662) at eval.c:2111
#151 0x01010a4e in Funwind_protect (args=83157646) at eval.c:1147

---Type <return> to continue, or q <return> to quit---

#152 0x01012d3c in eval_sub (form=83157670) at eval.c:2087
#153 0x0100f0aa in Fprogn (args=83157510) at eval.c:359
#154 0x01015cf1 in funcall_lambda (fun=83157446, nargs=2, arg_vector=0x82ec20) at eval.c:2999
#155 0x01015600 in apply_lambda (fun=83157446, args=83345086) at eval.c:2883
#156 0x0101375b in eval_sub (form=83345094) at eval.c:2214
#157 0x0100ef11 in Fif (args=83345062) at eval.c:309
#158 0x01012d3c in eval_sub (form=83345070) at eval.c:2087
#159 0x0100f0aa in Fprogn (args=83344998) at eval.c:359
#160 0x0100ef2e in Fif (args=83345014) at eval.c:310
#161 0x01012d3c in eval_sub (form=83345022) at eval.c:2087
#162 0x0100f0aa in Fprogn (args=83344990) at eval.c:359
#163 0x010104e9 in Flet (args=83344982) at eval.c:913
#164 0x01012d3c in eval_sub (form=83344974) at eval.c:2087
#165 0x0100f0aa in Fprogn (args=83344942) at eval.c:359
#166 0x01015cf1 in funcall_lambda (fun=83344966, nargs=4, arg_vector=0x82f290) at eval.c:2999
#167 0x01015600 in apply_lambda (fun=83344966, args=80062622) at eval.c:2883
#168 0x0101375b in eval_sub (form=80062614) at eval.c:2214
#169 0x0100f0aa in Fprogn (args=80062742) at eval.c:359
#170 0x01015cf1 in funcall_lambda (fun=80062798, nargs=2, arg_vector=0x82f4a0) at eval.c:2999
#171 0x01015600 in apply_lambda (fun=80062798, args=81180374) at eval.c:2883
#172 0x0101375b in eval_sub (form=81180382) at eval.c:2214
#173 0x0100f0aa in Fprogn (args=81180358) at eval.c:359
#174 0x010104e9 in Flet (args=81180390) at eval.c:913
#175 0x01012d3c in eval_sub (form=81180422) at eval.c:2087
#176 0x0100f0aa in Fprogn (args=81180214) at eval.c:359
#177 0x01015cf1 in funcall_lambda (fun=81180102, nargs=0, arg_vector=0x82f954) at eval.c:2999

#178 0x01015391 in Ffuncall (nargs=1, args=0x82f950) at eval.c:2835

#179 0x010145d8 in apply1 (fn=60929386, arg=57358362) at eval.c:2535
#180 0x010e4c85 in Fcall_interactively (function=60929386, record_flag=57358362, keys=57379757) at callint.c:377

#181 0x01014f7d in Ffuncall (nargs=4, args=0x82fb60) at eval.c:2781

#182 0x010146db in call3 (fn=57469674, arg1=60929386, arg2=57358362, arg3=57358362) at eval.c:2599
#183 0x010529fe in Fcommand_execute (cmd=60929386, record_flag=57358362, keys=57358362, special=57358362) at keyboard.c:10240

#184 0x01038e13 in command_loop_1 () at keyboard.c:1586
#185 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>, handlers=57408946, hfun=0x10378fd <cmd_error>)
at eval.c:1288
#186 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
#187 0x010108e3 in internal_catch (tag=57398802, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
#188 0x01037d11 in command_loop () at keyboard.c:1146
#189 0x010372cb in recursive_edit_1 () at keyboard.c:778
#190 0x010375f8 in Frecursive_edit () at keyboard.c:842
#191 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552

Lisp Backtrace:
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)

---Type <return> to continue, or q <return> to quit---

"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)

---Type <return> to continue, or q <return> to quit---

"call-interactively" (0x82fb64)
(gdb) thread 1
[Switching to thread 1 (Thread 3956.0x1fbc)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) xbacktrace
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)

---Type <return> to continue, or q <return> to quit---

"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)
(gdb) thread apply all xbacktrace

Thread 9 (Thread 3956.0x15c4):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)

---Type <return> to continue, or q <return> to quit---

"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 8 (Thread 3956.0x22ac):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)

---Type <return> to continue, or q <return> to quit---

"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 7 (Thread 3956.0x568):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)

---Type <return> to continue, or q <return> to quit---

"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 6 (Thread 3956.0x74):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)

---Type <return> to continue, or q <return> to quit---

"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 5 (Thread 3956.0x1674):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)

---Type <return> to continue, or q <return> to quit---

"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 4 (Thread 3956.0x2224):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)

---Type <return> to continue, or q <return> to quit---

"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 3 (Thread 3956.0x984):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)

---Type <return> to continue, or q <return> to quit---

"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)

---Type <return> to continue, or q <return> to quit---

"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 2 (Thread 3956.0xc28):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)
"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)

---Type <return> to continue, or q <return> to quit---

"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)

Thread 1 (Thread 3956.0x1fbc):
"delete-process" (0x829c9c)
"helm-kill-async-process" (0x829de0)
"while" (0x82a074)
"helm-kill-async-processes" (0x82a160)
"helm-update" (0x82a360)
"if" (0x82a5d4)
"helm-check-new-input" (0x82a6c0)
"progn" (0x82a914)
"unwind-protect" (0x82aa44)
"save-current-buffer" (0x82aba4)
"let" (0x82ad74)
"progn" (0x82aea4)
"condition-case" (0x82b084)
"let" (0x82b254)
"helm-check-minibuffer-input-1" (0x82b4ec)
"apply" (0x82b4e8)
"byte-code" (0x82b75c)
"timer-event-handler" (0x82bbdc)
"read-from-minibuffer" (0x82c6dc)
"let" (0x82c904)
"cond" (0x82ca64)
"let*" (0x82cbf4)
"save-current-buffer" (0x82cd54)
"helm-read-pattern-maybe" (0x82ce40)
"unwind-protect" (0x82d0a4)
"progn" (0x82d1d4)
"unwind-protect" (0x82d304)
"let" (0x82d4d4)
"let" (0x82d6a4)
"condition-case" (0x82d884)
"unwind-protect" (0x82d9b4)
"let" (0x82db84)
"catch" (0x82dd74)
"helm-internal" (0x82df04)
"apply" (0x82dfb0)
"if" (0x82e1b4)

---Type <return> to continue, or q <return> to quit---

"if" (0x82e314)
"let" (0x82e4e4)
"helm" (0x82e674)
"apply" (0x82e720)
0x4f7bf18 Lisp type 6
"funcall" (0x82e960)
"unwind-protect" (0x82eb34)
"helm-let-internal" (0x82ec20)
"if" (0x82ee74)
"if" (0x82efd4)
"let" (0x82f1a4)
"helm" (0x82f290)
"helm-other-buffer" (0x82f4a0)
"let" (0x82f794)
"helm-for-files" (0x82f954)
"call-interactively" (0x82fb64)
(gdb) thread 1
[Switching to thread 1 (Thread 3956.0x1fbc)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) finish
Run till exit from #0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

<< waited for more than 1 minute. Nothing happened. Killed Emacs >>

[Inferior 1 (process 3956) exited with code 01]
(gdb) exit
Undefined command: "exit". Try "help".
(gdb) quit
--8<---------------cut here---------------end--------------->8---

I hope you'll see some interesting information in there...

However, I'm surprised that `finish' never does something sensible here. It
simply is stuck as well...

Best regards,
Fabrice Niessen

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: thierry....@gmail.com, drew....@oracle.com, lek...@gmail.com, 12...@debbugs.gnu.org

> Date: Wed, 07 Nov 2012 11:52:18 +0100

>
> New infloop. Same context (completing pattern for Helm-for-files). This time,
> with a correct .gdbinit file.

OK, thanks.

I think you can stop posting the backtraces, they all look the same.

Next, I'd like to see which process is being waited for. To this end,
next time you have an infloop, go to this stack frame:

#14 0x0102ffff in status_notify (deleting_process=0x3e25e70) at process.c:6606

and display the details of the process being deleted. Like this:

(gdb) frame 14

(The number 14 comes from #14 on the above line from backtrace. It
could be a different number, so please look up the frame which is
inside status_notify function at line 6606 of process.c.)

(gdb) print *p
(gdb) print p->name
(gdb) xstring
(gdb) print p->command
(gdb) xtype

If the last command says p->command is a symbol, type "xsymbol" to
show it; otherwise it will probably say it's a string, and then
"xstring" will display it.

Thanks.

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

>> New infloop. Same context (completing pattern for Helm-for-files). This time,
>> with a correct .gdbinit file.
>
> OK, thanks.
>
> I think you can stop posting the backtraces, they all look the same.

OK.

> Next, I'd like to see which process is being waited for. To this end,
> next time you have an infloop, go to this stack frame:
>
> #14 0x0102ffff in status_notify (deleting_process=0x3e25e70) at process.c:6606
>
> and display the details of the process being deleted. Like this:
>
> (gdb) frame 14
>
> (The number 14 comes from #14 on the above line from backtrace. It
> could be a different number, so please look up the frame which is
> inside status_notify function at line 6606 of process.c.)
>
> (gdb) print *p
> (gdb) print p->name
> (gdb) xstring
> (gdb) print p->command
> (gdb) xtype
>
> If the last command says p->command is a symbol, type "xsymbol" to
> show it; otherwise it will probably say it's a string, and then
> "xstring" will display it.

--8<---------------cut here---------------start------------->8---
$ gdb -p 6196
[...]

(gdb) thread apply all backtrace

[...]
Thread 1 (Thread 6196.0x580):

---Type <return> to continue, or q <return> to quit---
#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#4 0x00a41fe0 in ?? ()

#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll

#6 0x00000005 in ?? ()

#7 0x00000009 in ?? ()

#8 0x00000005 in ?? ()
#9 0x08802920 in ?? ()
#10 0x0108d41e in sys_close (fd=5) at w32.c:5918
#11 0x011452a8 in emacs_close (fd=5) at sysdep.c:2082
#12 0x01029ce4 in deactivate_process (proc=142616869) at process.c:3924
#13 0x01022d92 in remove_process (proc=142616869) at process.c:735
#14 0x0102ffff in status_notify (deleting_process=0x8802920) at process.c:6606
#15 0x01023263 in Fdelete_process (process=142616869) at process.c:850
#16 0x01013174 in eval_sub (form=58276094) at eval.c:2139
[...]

#190 0x010375f8 in Frecursive_edit () at keyboard.c:842
#191 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552

(gdb) thread 1
[Switching to thread 1 (Thread 6196.0x580)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) frame 14
#14 0x0102ffff in status_notify (deleting_process=0x8802920) at process.c:6606
(gdb) 6606 process.c: No such file or directory.
print *p
$1 = {header = {size = 1073872914, next = {nbytes = 144, buffer = 0x90, vector = 0x90}}, tty_name = 57358362, name = 64171793,
command = 135560334, filter = 57358386, sentinel = 65761430, log = 57358362, buffer = 79997445, childp = 57358386,
plist = 57358362, type = 57481914, mark = 97021099, status = 136598966, decode_coding_system = 59149866,
decoding_buf = 20036945, encode_coding_system = 59149842, encoding_buf = 20036945, write_queue = 57358362,
gnutls_cred_type = 57358362, pid = 7912, infd = 5, outfd = 9, tick = 43, update_tick = 43, decoding_carryover = 0,
read_output_delay = 0, adaptive_read_buffering = 1, read_output_skip = 0, kill_without_query = 0, pty_flag = 0,
inherit_coding_system_flag = 0, raw_status_new = 0, raw_status = 0, gnutls_initstage = GNUTLS_STAGE_EMPTY, gnutls_state = 0x0,
gnutls_x509_cred = 0x0, gnutls_anon_cred = 0x0, gnutls_log_level = 0, gnutls_handshakes_tried = 0, gnutls_p = 0}
(gdb) print p->name
$2 = 64171793
(gdb) xstring
Undefined command: "xstring". Try "help".
(gdb) source /cygdrive/c/Program Files/Emacs-24.2/bin/.gdbinit
Warning: /cygdrive/d/home/sva/src/org-config/../lwlib: No such file or directory.

SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]

Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x10013b6: file emacs.c, line 317.
Temporary breakpoint 2 at 0x11441d5: file sysdep.c, line 794.

(gdb) xstring
$3 = (struct Lisp_String *) 0x3d32f10
"locate-process"
(gdb) print p->command
$4 = 135560334
(gdb) xtype
Lisp_Cons
(gdb) xsymbol
$5 = (struct Lisp_Symbol *) 0x8147c88
0
(gdb) xstring
Argument to arithmetic operation not a number or boolean.
(gdb) xcons
Argument to arithmetic operation not a number or boolean.
(gdb) nextcons
There is no member named u.
(gdb) xcar
Argument to arithmetic operation not a number or boolean.
--8<---------------cut here---------------end--------------->8---

Thanks to you...
Fabrice

[Fabrice Niessen]

Eli, Thierry,

"Fabrice Niessen" wrote:
> Eli Zaretskii wrote:
>>> New infloop. Same context (completing pattern for Helm-for-files). This time,
>>> with a correct .gdbinit file.
>>

>> Next, I'd like to see which process is being waited for. To this end,
>> next time you have an infloop, go to this stack frame:
>>
>> #14 0x0102ffff in status_notify (deleting_process=0x3e25e70) at process.c:6606
>>
>> and display the details of the process being deleted.
>

> (gdb) xstring
> $3 = (struct Lisp_String *) 0x3d32f10
> "locate-process"
> (gdb) print p->command
> $4 = 135560334
> (gdb) xtype
> Lisp_Cons
> (gdb) xsymbol
> $5 = (struct Lisp_Symbol *) 0x8147c88
> 0
> (gdb) xstring
> Argument to arithmetic operation not a number or boolean.
> (gdb) xcons
> Argument to arithmetic operation not a number or boolean.
> (gdb) nextcons
> There is no member named u.
> (gdb) xcar
> Argument to arithmetic operation not a number or boolean.

For your information,

- I use a version of Helm from 2 days ago

--8<---------------cut here---------------start------------->8---
commit 336e7de7e21f6bf1f9163458e34e79407553b8c2
Author: Thierry Volpiatto <thierry....@gmail.com>
Date: Tue Nov 6 20:24:24 2012 +0100

* helm-files.el: Fix ffap stuff.
--8<---------------cut here---------------end--------------->8---

That one is not important per se, the infloop occurred with earlier versions
as well. Just for the sake of completeness.

- I do use Thierry's test fix in my .emacs file, that is:

--8<---------------cut here---------------start------------->8---
;; TEMP test from Thierry Volpiatto (email from 2012-10-10 Wed 08:47)
(defun helm-kill-async-process (process)
"Stop output from `helm-output-filter' and kill associated PROCESS."
(set-process-filter process t)
(delete-process process))
--8<---------------cut here---------------end--------------->8---

Best regards,
Fabrice

[Thierry Volpiatto]

Hi Fabrice, Eli,

"Fabrice Niessen" <f...@missioncriticalit.com> writes:

> For your information,
>
> - I use a version of Helm from 2 days ago
>

> commit 336e7de7e21f6bf1f9163458e34e79407553b8c2
> Author: Thierry Volpiatto <thierry....@gmail.com>
> Date: Tue Nov 6 20:24:24 2012 +0100
>
> * helm-files.el: Fix ffap stuff.
>

> That one is not important per se, the infloop occurred with earlier versions
> as well. Just for the sake of completeness.

You should now narrow the problem by setting
`helm-for-files-preferred-list'.

Just remove locate source from this list and see what happen, you should
not have crashes.

Then if you have no more crash, try to use M-x helm-locate alone and see
if you experiment crashes.

If not add again the locate source to `helm-for-files-preferred-list'
and again see what happen.

I am pretty sure your crashes come from locate source, more precisely
the es.exe backend that is for some reasons bad supported by start-process.

> - I do use Thierry's test fix in my .emacs file, that is:
>

> ;; TEMP test from Thierry Volpiatto (email from 2012-10-10 Wed 08:47)
> (defun helm-kill-async-process (process)
> "Stop output from `helm-output-filter' and kill associated PROCESS."
> (set-process-filter process t)
> (delete-process process))

You can remove this from your .emacs, it is already in the helm version
you use.

Also, when you have done all the tests above, you can try the last
dev version (after 1.4.7), which don't use anymore `post-command-hook'.

Thanks.

--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry....@gmail.com>

> Cc: Eli Zaretskii <el...@gnu.org>, lek...@gmail.com, 12...@debbugs.gnu.org

> Date: Thu, 08 Nov 2012 16:58:50 +0100

>
> the es.exe backend that is for some reasons bad supported by start-process.

Any details about this?

[Thierry Volpiatto]

Unfortunately no, I use rarely Windows and BTW es.exe, it is just a
guess.

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry....@gmail.com>
> Cc: f...@missioncriticalit.com, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Thu, 08 Nov 2012 18:34:00 +0100

>
> Eli Zaretskii <el...@gnu.org> writes:
>
> >> From: Thierry Volpiatto <thierry....@gmail.com>
> >> Cc: Eli Zaretskii <el...@gnu.org>, lek...@gmail.com, 12...@debbugs.gnu.org
> >> Date: Thu, 08 Nov 2012 16:58:50 +0100
> >>
> >> the es.exe backend that is for some reasons bad supported by start-process.
> >
> > Any details about this?
> Unfortunately no, I use rarely Windows and BTW es.exe, it is just a
> guess.

What is this guess based on? What incidents did you witness that led
you to this guess?

[Thierry Volpiatto]

Eli Zaretskii <el...@gnu.org> writes:

>> From: Thierry Volpiatto <thierry....@gmail.com>
>> Cc: f...@missioncriticalit.com, lek...@gmail.com, 12...@debbugs.gnu.org
>> Date: Thu, 08 Nov 2012 18:34:00 +0100
>>
>> Eli Zaretskii <el...@gnu.org> writes:
>>
>> >> From: Thierry Volpiatto <thierry....@gmail.com>
>> >> Cc: Eli Zaretskii <el...@gnu.org>, lek...@gmail.com, 12...@debbugs.gnu.org
>> >> Date: Thu, 08 Nov 2012 16:58:50 +0100
>> >>
>> >> the es.exe backend that is for some reasons bad supported by start-process.
>> >
>> > Any details about this?
>> Unfortunately no, I use rarely Windows and BTW es.exe, it is just a
>> guess.
>
> What is this guess based on? What incidents did you witness that led
> you to this guess?

Because it is the only async process that run in helm-for-files, and
every time the crash come from this; On GNU/Linux helm-for-files use
locate and nobody reported crash on this platform.
It is why I asked Fabrice to remove this source from helm-for-files to
see what happen. I am nearly sure the crashes will stop.
Using helm-locate alone (outside of helm-for-files) should also crash
emacs (on Windows I mean).
So maybe es.exe, with specific settings in Everything could cause a
crash?
But as I said it is just supposition so take this with care.

[Fabrice Niessen]

Hi Thierry and Eli,

Thierry Volpiatto wrote:
> Eli Zaretskii <el...@gnu.org> writes:
>>> From: Thierry Volpiatto <thierry....@gmail.com>
>>> Eli Zaretskii <el...@gnu.org> writes:
>>>>> From: Thierry Volpiatto <thierry....@gmail.com>
>>>>>

>>>>> the es.exe backend that is for some reasons bad supported by start-process.
>>>>
>>>> Any details about this?
>>>
>>> Unfortunately no, I use rarely Windows and BTW es.exe, it is just a
>>> guess.
>>
>> What is this guess based on? What incidents did you witness that led
>> you to this guess?
>
> Because it is the only async process that run in helm-for-files, and
> every time the crash come from this; On GNU/Linux helm-for-files use
> locate and nobody reported crash on this platform.
> It is why I asked Fabrice to remove this source from helm-for-files to
> see what happen. I am nearly sure the crashes will stop.
> Using helm-locate alone (outside of helm-for-files) should also crash
> emacs (on Windows I mean).
> So maybe es.exe, with specific settings in Everything could cause a
> crash?

My gut feeling is also that `es.exe' is (co-)responsible. In fact, this is more
than a gut feeling, as it's somehow based on a beam of presumptions:

- with the latest versions of Emacs, the infloop always occur when using
helm-for-files (never, for example, when using helm-M-x, which is the other
tool I'm using, as frequently, from Helm)

- `es.exe' is launched after having typed at least 3 characters in the prompt,
and I've never seen an infloop with less characters (that is, only one or
two) typed at the prompt: I always have typed a pattern of at least 5 to 6
chars before the freeze occurs (sometimes, even much more, when being
deleting many characters because I typed an fault in the filename I'm after)

- on Monday, after having gotten several frozen Emacs (since the last reboot
of Windows -- once every 3 weeks or so), I had noticed up to 7 instances of
`es.exe' (I guess they were hanging as some zombies, though I don't know to
prove this -- any idea?)

- from the latest backtrace I sent today, you can see, IIUC, that frame #14
identifies `locate-process' as the one we're waiting on

- the default `locate' command used by Helm, when on Windows, is `es.exe' (the
command line version of "Everything", some sort of realtime `locate', much
more powerful IMHO then than the real `locate' itself, because of that
realtime aspect)

Does this give you more trust into Thierry's assumption?

Anyway, we'll be able to compare: I'm currently only running helm-M-x, waiting
for the next infloop. Then, I'll use helm-for-files without the locate process
for as long as needed to get an infloop. After one week, we should have a
rather solid comparison basis, based on the occurrence frequency of my
problem...

Best regards,
Fabrice

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Thu, 08 Nov 2012 23:04:40 +0100

>
> My gut feeling is also that `es.exe' is (co-)responsible. In fact, this is more
> than a gut feeling, as it's somehow based on a beam of presumptions:
>
> - with the latest versions of Emacs, the infloop always occur when using
> helm-for-files (never, for example, when using helm-M-x, which is the other
> tool I'm using, as frequently, from Helm)
>
> - `es.exe' is launched after having typed at least 3 characters in the prompt,
> and I've never seen an infloop with less characters (that is, only one or
> two) typed at the prompt: I always have typed a pattern of at least 5 to 6
> chars before the freeze occurs (sometimes, even much more, when being
> deleting many characters because I typed an fault in the filename I'm after)
>
> - on Monday, after having gotten several frozen Emacs (since the last reboot
> of Windows -- once every 3 weeks or so), I had noticed up to 7 instances of
> `es.exe' (I guess they were hanging as some zombies, though I don't know to
> prove this -- any idea?)

How (with what compiler) was es.exe compiled? Was MinGW GCC, Cygwin
GCC, MSVC, something else?

> Does this give you more trust into Thierry's assumption?

Not really. I'd need to know much more about es.exe, like how it
communicates with Emacs, and how it differs from any other
garden-variety of console programs, like locate.exe itself, before I
could make up my mind about this.

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>>

>> My gut feeling is also that `es.exe' is (co-)responsible. In fact, this is more
>> than a gut feeling, as it's somehow based on a beam of presumptions:
>>
>> - with the latest versions of Emacs, the infloop always occur when using
>> helm-for-files (never, for example, when using helm-M-x, which is the other
>> tool I'm using, as frequently, from Helm)
>>
>> - `es.exe' is launched after having typed at least 3 characters in the prompt,
>> and I've never seen an infloop with less characters (that is, only one or
>> two) typed at the prompt: I always have typed a pattern of at least 5 to 6
>> chars before the freeze occurs (sometimes, even much more, when being
>> deleting many characters because I typed an fault in the filename I'm after)
>>
>> - on Monday, after having gotten several frozen Emacs (since the last reboot
>> of Windows -- once every 3 weeks or so), I had noticed up to 7 instances of
>> `es.exe' (I guess they were hanging as some zombies, though I don't know to
>> prove this -- any idea?)
>
> How (with what compiler) was es.exe compiled? Was MinGW GCC, Cygwin
> GCC, MSVC, something else?

I don't know the details, but I downloaded `es.exe' (53 KB) from
http://www.voidtools.com/download.php, months ago: apparently, in December
2010 if I can trust the modification date on my file system -- this seems just
right, btw.

It does seem to me to be a pure Win32 application, but maybe you know how to
know more?

>> Does this give you more trust into Thierry's assumption?
>
> Not really. I'd need to know much more about es.exe, like how it
> communicates with Emacs, and how it differs from any other
> garden-variety of console programs, like locate.exe itself, before I
> could make up my mind about this.

I'll let Thierry comment on this...

Best regards,
Fabrice

[Fabrice Niessen]

Hi Eli and Thierry,

Got a new one...

"Fabrice Niessen" wrote:
> "Fabrice Niessen" wrote:
>> Eli Zaretskii wrote:
>>>> New infloop. Same context (completing pattern for Helm-for-files). This time,
>>>> with a correct .gdbinit file.
>>>
>>> Next, I'd like to see which process is being waited for. To this end,
>>> next time you have an infloop, go to this stack frame:
>>>
>>> #14 0x0102ffff in status_notify (deleting_process=0x3e25e70) at process.c:6606
>>>
>>> and display the details of the process being deleted.
>>
>> (gdb) xstring
>> $3 = (struct Lisp_String *) 0x3d32f10
>> "locate-process"
>> (gdb) print p->command
>> $4 = 135560334
>> (gdb) xtype
>> Lisp_Cons
>

> For your information,

Same version of Emacs:

GNU Emacs 24.2.50.1 (i386-mingw-nt5.1.2600) of 2012-10-22 on DANI-PC

> - I use a version of Helm from 2 days ago

Still the same version.

> - I do use Thierry's test fix in my .emacs file, that is:

Removed (as adviced by Thierry), but already in Helm code...

What is well changed: I know only used `helm-locate', instead of
`helm-for-files'; that is one of the two tests asked by Thierry.
Conclusion is: it freezes with `helm-locate'. I will know test with
`helm-for-files' configured without the use of the locate feature.

Here the backtrace (with different results):

--8<---------------cut here---------------start------------->8---
Warning: /cygdrive/c/Program Files/Emacs-24.2/bin/../lwlib: No such file or directory.
--8<---------------cut here---------------end--------------->8---

BTW, is this important (does it have impacts of the usefulness of the backtrace)?

--8<---------------cut here---------------start------------->8---

(gdb) thread apply all backtrace

Thread 8 (Thread 2156.0x18e4):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x5ad2ffd0 in ?? ()

#6 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x4900ad8 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)

Thread 7 (Thread 2156.0xcfc):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000488 in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x4900ad8 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)

Thread 6 (Thread 2156.0x159c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000004ac in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x4900ad8 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)

Thread 5 (Thread 2156.0x1220):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x0000048c in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x4900ad8 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)

Thread 4 (Thread 2156.0x107c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0108d925 in _sys_read_ahead (fd=4) at w32.c:6079
#6 0x01033127 in reader_thread (arg=0x167dc98) at w32proc.c:838

#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x4900ad8 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)

Thread 3 (Thread 2156.0xef4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7e3991be in USER32!GetProcessWindowStation () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3991f1 in USER32!GetMessageW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x01148948 in w32_msg_pump (msg_buf=0x5b8cff54) at w32fns.c:2375
#4 0x01148b86 in w32_msg_worker@4 (arg=0x0) at w32fns.c:2601
#5 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#6 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x4900ad8 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)

Thread 2 (Thread 2156.0x2b4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d21a in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8023f1 in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x00000000 in ?? ()

Lisp Backtrace:

"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x4900ad8 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)

Thread 1 (Thread 2156.0xde8):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#4 0x00a41fe0 in ?? ()
#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll
#6 0x00000005 in ?? ()

#7 0x0000000a in ?? ()

#8 0x00000005 in ?? ()

#9 0x05c6f620 in ?? ()

#10 0x0108d41e in sys_close (fd=5) at w32.c:5918
#11 0x011452a8 in emacs_close (fd=5) at sysdep.c:2082

#12 0x01029ce4 in deactivate_process (proc=96925221) at process.c:3924
#13 0x01022d92 in remove_process (proc=96925221) at process.c:735
#14 0x0102ffff in status_notify (deleting_process=0x5c6f620) at process.c:6606
#15 0x01023263 in Fdelete_process (process=96925221) at process.c:850
#16 0x01013174 in eval_sub (form=84808006) at eval.c:2139
#17 0x0100f0aa in Fprogn (args=84808110) at eval.c:359
#18 0x01015cf1 in funcall_lambda (fun=84808174, nargs=1, arg_vector=0x829b70) at eval.c:2999
#19 0x01015600 in apply_lambda (fun=84808174, args=84809582) at eval.c:2883
#20 0x0101375b in eval_sub (form=84809558) at eval.c:2214
#21 0x0100f0aa in Fprogn (args=84809590) at eval.c:359
#22 0x01010582 in Fwhile (args=84809550) at eval.c:935
#23 0x01012d3c in eval_sub (form=84809542) at eval.c:2087
#24 0x0100f0aa in Fprogn (args=84807718) at eval.c:359
#25 0x01015cf1 in funcall_lambda (fun=84807774, nargs=0, arg_vector=0x829ef0) at eval.c:2999
#26 0x01015600 in apply_lambda (fun=84807774, args=57358362) at eval.c:2883
#27 0x0101375b in eval_sub (form=83918918) at eval.c:2214
#28 0x0100f0aa in Fprogn (args=83917038) at eval.c:359
#29 0x01015cf1 in funcall_lambda (fun=83917006, nargs=0, arg_vector=0x82a0f0) at eval.c:2999
#30 0x01015600 in apply_lambda (fun=83917006, args=57358362) at eval.c:2883
#31 0x0101375b in eval_sub (form=76664790) at eval.c:2214
#32 0x0100f0aa in Fprogn (args=76663014) at eval.c:359
#33 0x0100ef2e in Fif (args=76663214) at eval.c:310
#34 0x01012d3c in eval_sub (form=76663206) at eval.c:2087
#35 0x0100f0aa in Fprogn (args=76663350) at eval.c:359
#36 0x01015cf1 in funcall_lambda (fun=76663326, nargs=1, arg_vector=0x82a450) at eval.c:2999
#37 0x01015600 in apply_lambda (fun=76663326, args=76663814) at eval.c:2883
#38 0x0101375b in eval_sub (form=76612566) at eval.c:2214
#39 0x0100f0aa in Fprogn (args=76664150) at eval.c:359
#40 0x01012d3c in eval_sub (form=76664206) at eval.c:2087
#41 0x01010a4e in Funwind_protect (args=76664214) at eval.c:1147
#42 0x01012d3c in eval_sub (form=76664222) at eval.c:2087
#43 0x0100f0aa in Fprogn (args=76664230) at eval.c:359
#44 0x01103187 in Fsave_current_buffer (args=76664230) at editfns.c:962
#45 0x01012d3c in eval_sub (form=76664238) at eval.c:2087
#46 0x0100f0aa in Fprogn (args=76664246) at eval.c:359
#47 0x010104e9 in Flet (args=76664254) at eval.c:913
#48 0x01012d3c in eval_sub (form=76664262) at eval.c:2087
#49 0x0100f0aa in Fprogn (args=76664398) at eval.c:359
#50 0x01012d3c in eval_sub (form=76664390) at eval.c:2087
#51 0x01010da4 in internal_lisp_condition_case (var=59048394, bodyform=76664390, handlers=76554158) at eval.c:1242
#52 0x01010abe in Fcondition_case (args=76664454) at eval.c:1183
#53 0x01012d3c in eval_sub (form=76664462) at eval.c:2087
#54 0x0100f0aa in Fprogn (args=76664470) at eval.c:359
#55 0x010104e9 in Flet (args=76664478) at eval.c:913
#56 0x01012d3c in eval_sub (form=76664486) at eval.c:2087
#57 0x0100f0aa in Fprogn (args=76664518) at eval.c:359
#58 0x01015cf1 in funcall_lambda (fun=76664494, nargs=0, arg_vector=0x82b27c) at eval.c:2999
#59 0x01015391 in Ffuncall (nargs=1, args=0x82b278) at eval.c:2835
#60 0x0101385e in Fapply (nargs=2, args=0x82b278) at eval.c:2251
#61 0x01014c0e in Ffuncall (nargs=3, args=0x82b274) at eval.c:2755

#62 0x010e0f13 in exec_byte_code (bytestr=20931649, vector=20931701, maxdepth=16, args_template=57358362, nargs=0, args=0x0)
at bytecode.c:899
#63 0x010e02da in Fbyte_code (bytestr=20931649, vector=20931701, maxdepth=16) at bytecode.c:474
#64 0x01013258 in eval_sub (form=20931638) at eval.c:2145

#65 0x01010da4 in internal_lisp_condition_case (var=57358362, bodyform=20931638, handlers=20115822) at eval.c:1242
#66 0x010e1b50 in exec_byte_code (bytestr=20931393, vector=20931525, maxdepth=20, args_template=57358362, nargs=0, args=0x0)
at bytecode.c:1095
#67 0x01015e26 in funcall_lambda (fun=20931365, nargs=1, arg_vector=0x36b381a <__register_frame_info+57358362>) at eval.c:3006

#68 0x010152bf in Ffuncall (nargs=2, args=0x82b968) at eval.c:2823
#69 0x01014661 in call1 (fn=57400610, arg1=96925573) at eval.c:2568
#70 0x01040874 in timer_check_2 (timers=99298190, idle_timers=99298230) at keyboard.c:4386

#71 0x0104095d in timer_check () at keyboard.c:4453
#72 0x0103e7e6 in readable_events (flags=1) at keyboard.c:3350
#73 0x010472bb in get_input_pending (flags=1) at keyboard.c:6679
#74 0x01052a98 in detect_input_pending_run_timers (do_display=true) at keyboard.c:10272

#75 0x0102b77f in wait_reading_process_output (time_limit=16, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=57358362,

wait_proc=0x0, just_wait_proc=0) at process.c:4749

#76 0x010fb997 in sit_for (timeout=64, reading=true, display_option=1) at dispnew.c:5977
#77 0x0103baf8 in read_char (commandflag=1, nmaps=2, maps=0x82be00, prev_event=57358362, used_mouse_menu=0x82bed3, end_time=0x0)
at keyboard.c:2668
#78 0x0104eef4 in read_key_sequence (keybuf=0x82c050, bufsize=30, prompt=57358362, dont_downcase_last=false,

can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9230
#79 0x010385c4 in command_loop_1 () at keyboard.c:1458
#80 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>, handlers=57408946, hfun=0x10378fd <cmd_error>)
at eval.c:1288
#81 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
#82 0x010108e3 in internal_catch (tag=57462578, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
#83 0x01037cc0 in command_loop () at keyboard.c:1138
#84 0x010372cb in recursive_edit_1 () at keyboard.c:778

#85 0x010be480 in read_minibuf (map=76294318, initial=57358362, prompt=76634321, expflag=false, histvar=95220242, histpos=0,
defalt=95385729, allow_props=false, inherit_input_method=true) at minibuf.c:674
#86 0x010bf18a in Fread_from_minibuffer (prompt=76634321, initial_contents=57358362, keymap=76294318, sys_read=57358362,
hist=95220242, default_value=95385729, inherit_input_method=57358386) at minibuf.c:976
#87 0x010134c8 in eval_sub (form=76623102) at eval.c:2163
#88 0x0100f0aa in Fprogn (args=76623190) at eval.c:359
#89 0x010104e9 in Flet (args=76622222) at eval.c:913
#90 0x01012d3c in eval_sub (form=76622230) at eval.c:2087
#91 0x0100f0aa in Fprogn (args=76622246) at eval.c:359
#92 0x0100eff8 in Fcond (args=76622270) at eval.c:337
#93 0x01012d3c in eval_sub (form=76622278) at eval.c:2087
#94 0x0100f0aa in Fprogn (args=76622286) at eval.c:359
#95 0x01010051 in FletX (args=76622294) at eval.c:843
#96 0x01012d3c in eval_sub (form=76622302) at eval.c:2087
#97 0x0100f0aa in Fprogn (args=76622326) at eval.c:359
#98 0x01103187 in Fsave_current_buffer (args=76622318) at editfns.c:962
#99 0x01012d3c in eval_sub (form=76622310) at eval.c:2087
#100 0x0100f0aa in Fprogn (args=76622366) at eval.c:359
#101 0x01015cf1 in funcall_lambda (fun=76622334, nargs=7, arg_vector=0x82cbd0) at eval.c:2999
#102 0x01015600 in apply_lambda (fun=76622334, args=76594470) at eval.c:2883
#103 0x0101375b in eval_sub (form=76594462) at eval.c:2214
#104 0x01010a4e in Funwind_protect (args=76594534) at eval.c:1147
#105 0x01012d3c in eval_sub (form=76594526) at eval.c:2087
#106 0x0100f0aa in Fprogn (args=76594582) at eval.c:359
#107 0x01012d3c in eval_sub (form=76594550) at eval.c:2087
#108 0x01010a4e in Funwind_protect (args=76594598) at eval.c:1147
#109 0x01012d3c in eval_sub (form=76594590) at eval.c:2087
#110 0x0100f0aa in Fprogn (args=76592318) at eval.c:359
#111 0x010104e9 in Flet (args=76592326) at eval.c:913
#112 0x01012d3c in eval_sub (form=76592334) at eval.c:2087
#113 0x0100f0aa in Fprogn (args=76592342) at eval.c:359
#114 0x010104e9 in Flet (args=76592494) at eval.c:913
#115 0x01012d3c in eval_sub (form=76592502) at eval.c:2087
#116 0x01010da4 in internal_lisp_condition_case (var=59048394, bodyform=76592502, handlers=76542078) at eval.c:1242
#117 0x01010abe in Fcondition_case (args=76592582) at eval.c:1183
#118 0x01012d3c in eval_sub (form=76592590) at eval.c:2087
#119 0x01010a4e in Funwind_protect (args=76592606) at eval.c:1147
#120 0x01012d3c in eval_sub (form=76592598) at eval.c:2087
#121 0x0100f0aa in Fprogn (args=76592710) at eval.c:359
#122 0x010104e9 in Flet (args=76592718) at eval.c:913
#123 0x01012d3c in eval_sub (form=76592726) at eval.c:2087
#124 0x0100f0aa in Fprogn (args=76592734) at eval.c:359
#125 0x010108e3 in internal_catch (tag=57462578, func=0x100f055 <Fprogn>, arg=76542590) at eval.c:1059
#126 0x01010849 in Fcatch (args=76542582) at eval.c:1030
#127 0x01012d3c in eval_sub (form=76542574) at eval.c:2087
#128 0x0100f0aa in Fprogn (args=76592766) at eval.c:359
#129 0x01015cf1 in funcall_lambda (fun=76592742, nargs=9, arg_vector=0x82dc94) at eval.c:2999
#130 0x01015391 in Ffuncall (nargs=10, args=0x82dc90) at eval.c:2835
#131 0x010140a8 in Fapply (nargs=2, args=0x82dd40) at eval.c:2308
#132 0x01012fcd in eval_sub (form=76548262) at eval.c:2111
#133 0x0100f0aa in Fprogn (args=76548286) at eval.c:359
#134 0x0100ef2e in Fif (args=76548950) at eval.c:310
#135 0x01012d3c in eval_sub (form=76548942) at eval.c:2087
#136 0x0100f0aa in Fprogn (args=76549014) at eval.c:359
#137 0x0100ef2e in Fif (args=76548998) at eval.c:310
#138 0x01012d3c in eval_sub (form=76548990) at eval.c:2087
#139 0x0100f0aa in Fprogn (args=76549022) at eval.c:359
#140 0x010104e9 in Flet (args=76549030) at eval.c:913
#141 0x01012d3c in eval_sub (form=76549038) at eval.c:2087
#142 0x0100f0aa in Fprogn (args=76549070) at eval.c:359
#143 0x01015cf1 in funcall_lambda (fun=76549046, nargs=9, arg_vector=0x82e404) at eval.c:2999
#144 0x01015391 in Ffuncall (nargs=10, args=0x82e400) at eval.c:2835
#145 0x010140a8 in Fapply (nargs=2, args=0x82e4b0) at eval.c:2308
#146 0x01012fcd in eval_sub (form=76548118) at eval.c:2111
#147 0x0100f0aa in Fprogn (args=76548814) at eval.c:359
#148 0x01015cf1 in funcall_lambda (fun=76548830, nargs=0, arg_vector=0x82e6f4) at eval.c:2999
#149 0x01015391 in Ffuncall (nargs=1, args=0x82e6f0) at eval.c:2835
#150 0x01012fcd in eval_sub (form=76523310) at eval.c:2111
#151 0x01010a4e in Funwind_protect (args=76523326) at eval.c:1147
#152 0x01012d3c in eval_sub (form=76523302) at eval.c:2087
#153 0x0100f0aa in Fprogn (args=76523454) at eval.c:359
#154 0x01015cf1 in funcall_lambda (fun=76521502, nargs=2, arg_vector=0x82e9b0) at eval.c:2999
#155 0x01015600 in apply_lambda (fun=76521502, args=76548926) at eval.c:2883
#156 0x0101375b in eval_sub (form=76548918) at eval.c:2214
#157 0x0100ef11 in Fif (args=76548950) at eval.c:309
#158 0x01012d3c in eval_sub (form=76548942) at eval.c:2087
#159 0x0100f0aa in Fprogn (args=76549014) at eval.c:359
#160 0x0100ef2e in Fif (args=76548998) at eval.c:310
#161 0x01012d3c in eval_sub (form=76548990) at eval.c:2087
#162 0x0100f0aa in Fprogn (args=76549022) at eval.c:359
#163 0x010104e9 in Flet (args=76549030) at eval.c:913
#164 0x01012d3c in eval_sub (form=76549038) at eval.c:2087
#165 0x0100f0aa in Fprogn (args=76549070) at eval.c:359
#166 0x01015cf1 in funcall_lambda (fun=76549046, nargs=10, arg_vector=0x82f020) at eval.c:2999
#167 0x01015600 in apply_lambda (fun=76549046, args=94382742) at eval.c:2883
#168 0x0101375b in eval_sub (form=94382734) at eval.c:2214
#169 0x0100f0aa in Fprogn (args=94382854) at eval.c:359
#170 0x010104e9 in Flet (args=94622046) at eval.c:913
#171 0x01012d3c in eval_sub (form=94622054) at eval.c:2087
#172 0x0100f0aa in Fprogn (args=94622070) at eval.c:359
#173 0x01015cf1 in funcall_lambda (fun=94630030, nargs=3, arg_vector=0x82f420) at eval.c:2999
#174 0x01015600 in apply_lambda (fun=94630030, args=92924774) at eval.c:2883
#175 0x0101375b in eval_sub (form=92924190) at eval.c:2214
#176 0x0100f0aa in Fprogn (args=92924886) at eval.c:359
#177 0x01015cf1 in funcall_lambda (fun=94391350, nargs=1, arg_vector=0x82f630) at eval.c:2999
#178 0x01015600 in apply_lambda (fun=94391350, args=95770398) at eval.c:2883
#179 0x0101375b in eval_sub (form=95770390) at eval.c:2214
#180 0x0100f0aa in Fprogn (args=95770494) at eval.c:359
#181 0x01015cf1 in funcall_lambda (fun=95770566, nargs=1, arg_vector=0x82f934) at eval.c:2999
#182 0x01015391 in Ffuncall (nargs=2, args=0x82f930) at eval.c:2835
#183 0x010e69b0 in Fcall_interactively (function=60950914, record_flag=57358362, keys=57379757) at callint.c:852
#184 0x01014f7d in Ffuncall (nargs=4, args=0x82fb60) at eval.c:2781
#185 0x010146db in call3 (fn=57469674, arg1=60950914, arg2=57358362, arg3=57358362) at eval.c:2599
#186 0x010529fe in Fcommand_execute (cmd=60950914, record_flag=57358362, keys=57358362, special=57358362) at keyboard.c:10240
#187 0x01038e13 in command_loop_1 () at keyboard.c:1586
#188 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>, handlers=57408946, hfun=0x10378fd <cmd_error>)
at eval.c:1288
#189 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
#190 0x010108e3 in internal_catch (tag=57398802, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
#191 0x01037d11 in command_loop () at keyboard.c:1146
#192 0x010372cb in recursive_edit_1 () at keyboard.c:778
#193 0x010375f8 in Frecursive_edit () at keyboard.c:842
#194 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552

Lisp Backtrace:
"delete-process" (0x829a2c)
"helm-kill-async-process" (0x829b70)
"while" (0x829e04)
"helm-kill-async-processes" (0x829ef0)
"helm-update" (0x82a0f0)
"if" (0x82a364)
"helm-check-new-input" (0x82a450)
"progn" (0x82a6a4)
"unwind-protect" (0x82a7d4)
"save-current-buffer" (0x82a934)
"let" (0x82ab04)
"progn" (0x82ac34)
"condition-case" (0x82ae14)
"let" (0x82afe4)
"helm-check-minibuffer-input-1" (0x82b27c)
"apply" (0x82b278)
"byte-code" (0x82b4ec)
"timer-event-handler" (0x82b96c)
"read-from-minibuffer" (0x82c46c)
"let" (0x82c694)
"cond" (0x82c7f4)
"let*" (0x82c984)
"save-current-buffer" (0x82cae4)
"helm-read-pattern-maybe" (0x82cbd0)
"unwind-protect" (0x82ce34)
"progn" (0x82cf64)
"unwind-protect" (0x82d094)
"let" (0x82d264)
"let" (0x82d434)
"condition-case" (0x82d614)
"unwind-protect" (0x82d744)
"let" (0x82d914)
"catch" (0x82db04)
"helm-internal" (0x82dc94)
"apply" (0x82dd40)
"if" (0x82df44)
"if" (0x82e0a4)
"let" (0x82e274)
"helm" (0x82e404)
"apply" (0x82e4b0)
0x4900ad8 Lisp type 6
"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)
(gdb) thread 1
[Switching to thread 1 (Thread 2156.0xde8)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) frame 14

#14 0x0102ffff in status_notify (deleting_process=0x5c6f620) at process.c:6606

6606 process.c: No such file or directory.

(gdb) print *p

$1 = {
header = {
size = 1073872914,
next = {
nbytes = 144,
buffer = 0x90,
vector = 0x90
}
},
tty_name = 57358362,

name = 95268961,
command = 99165854,
filter = 57358386,
sentinel = 95441550,
log = 57358362,
buffer = 72508421,

childp = 57358386,
plist = 57358362,
type = 57481914,

mark = 96614195,
status = 99296310,

decode_coding_system = 59149866,
decoding_buf = 20036945,
encode_coding_system = 59149842,
encoding_buf = 20036945,
write_queue = 57358362,
gnutls_cred_type = 57358362,

pid = 3552,
infd = 5,
outfd = 10,
tick = 16,
update_tick = 16,

decoding_carryover = 0,
read_output_delay = 0,
adaptive_read_buffering = 1,
read_output_skip = 0,
kill_without_query = 0,
pty_flag = 0,
inherit_coding_system_flag = 0,
raw_status_new = 0,
raw_status = 0,
gnutls_initstage = GNUTLS_STAGE_EMPTY,
gnutls_state = 0x0,
gnutls_x509_cred = 0x0,
gnutls_anon_cred = 0x0,
gnutls_log_level = 0,
gnutls_handshakes_tried = 0,
gnutls_p = 0
}
(gdb) print p->name

$2 = 95268961
(gdb) xstring
$3 = (struct Lisp_String *) 0x5adb060

"locate-process"
(gdb) print p->command

$4 = 99165854
(gdb) xtype
Lisp_Cons
(gdb) xcons
$5 = (struct Lisp_Cons *) 0x5e92698
{
car = 0x379c271,
u = {
cdr = 0x5e92696,
chain = 0x5e92696
}
}
(gdb) xsymbol

Argument to arithmetic operation not a number or boolean.

--8<---------------cut here---------------end--------------->8---

BTW, is this the right thing to do: typing `xcons' when type is Lisp_Cons?

Best regards,
Fabrice

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: lek...@gmail.com, 12...@debbugs.gnu.org

> Date: Fri, 09 Nov 2012 10:19:46 +0100

>
> --8<---------------cut here---------------start------------->8---
> Warning: /cygdrive/c/Program Files/Emacs-24.2/bin/../lwlib: No such file or directory.
> --8<---------------cut here---------------end--------------->8---
>
> BTW, is this important (does it have impacts of the usefulness of the backtrace)?

No.

> (gdb) print p->name
> $2 = 95268961
> (gdb) xstring
> $3 = (struct Lisp_String *) 0x5adb060
> "locate-process"

Is this process still running, or did it exit already?

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>>

>> (gdb) print p->name
>> $2 = 95268961
>> (gdb) xstring
>> $3 = (struct Lisp_String *) 0x5adb060
>> "locate-process"
>
> Is this process still running, or did it exit already?

I can't tell you exactly, even if I noticed an es.exe still there when Emacs
was frozen. But I can't tell you with certitude if it was already there before
I even launched Emacs, for example.

Do you want me to test this, trying to follow up any process creation (with a
`ps' running every second), or do you prefer that I test helm-for-files
without any locate call?

Best regards,
Fabrice Niessen

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: thierry....@gmail.com, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Fri, 09 Nov 2012 11:59:05 +0100

>
> Eli Zaretskii wrote:
> >> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> >>
> >> (gdb) print p->name
> >> $2 = 95268961
> >> (gdb) xstring
> >> $3 = (struct Lisp_String *) 0x5adb060
> >> "locate-process"
> >
> > Is this process still running, or did it exit already?
>
> I can't tell you exactly, even if I noticed an es.exe still there when Emacs
> was frozen. But I can't tell you with certitude if it was already there before
> I even launched Emacs, for example.

If you install Process Explorer from here:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

you will be able to display the processes in a tree-like display, so
you will see whether es.exe is a child process of Emacs. And in frame
14, you can see the PID of the process Emacs is waiting for:

Then compare this PID with all the processes that are children of
Emacs, or all the processes on your system, and you will know for
sure.

> Do you want me to test this, trying to follow up any process creation (with a
> `ps' running every second), or do you prefer that I test helm-for-files
> without any locate call?

Start the Process Explorer before the hang, and it will show the new
processes as they are born.

[Thierry Volpiatto]

Eli Zaretskii <el...@gnu.org> writes:

>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>> Cc: thierry....@gmail.com, lek...@gmail.com, 12...@debbugs.gnu.org
>> Date: Fri, 09 Nov 2012 11:59:05 +0100
>>
>> Eli Zaretskii wrote:
>> >> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>> >>
>> >> (gdb) print p->name
>> >> $2 = 95268961
>> >> (gdb) xstring
>> >> $3 = (struct Lisp_String *) 0x5adb060
>> >> "locate-process"
>> >
>> > Is this process still running, or did it exit already?
>>
>> I can't tell you exactly, even if I noticed an es.exe still there when Emacs
>> was frozen. But I can't tell you with certitude if it was already there before
>> I even launched Emacs, for example.
>
> If you install Process Explorer from here:
>
> http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
>
> you will be able to display the processes in a tree-like display, so
> you will see whether es.exe is a child process of Emacs. And in frame
> 14, you can see the PID of the process Emacs is waiting for:

When running helm-for-files in WindowsXP in VirtualBox, I don't see the
"es.exe" running, only "cmdproxy.exe" which exit quickly as soon as
candidates are found.
No crash happen as always.

[Fabrice Niessen]

Hello Thierry,

Thierry Volpiatto wrote:
> Eli Zaretskii <el...@gnu.org> writes:

>> Fabrice Niessen wrote:
>>> Eli Zaretskii wrote:
>>>>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>>>>>

>>>>> $3 = (struct Lisp_String *) 0x5adb060
>>>>> "locate-process"
>>>>
>>>> Is this process still running, or did it exit already?
>>>
>>> I can't tell you exactly, even if I noticed an es.exe still there when
>>> Emacs was frozen. But I can't tell you with certitude if it was already
>>> there before I even launched Emacs, for example.
>>
>> If you install Process Explorer from here:
>>
>> http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
>>
>> you will be able to display the processes in a tree-like display, so you
>> will see whether es.exe is a child process of Emacs. And in frame 14, you
>> can see the PID of the process Emacs is waiting for:
>
> When running helm-for-files in WindowsXP in VirtualBox, I don't see the
> "es.exe" running, only "cmdproxy.exe" which exit quickly as soon as
> candidates are found.

I don't use cmdproxy.exe; I use Cygwin bash for all my shell calls:

--8<---------------cut here---------------start------------->8---
;; for single shell commands
(setq shell-file-name
(cond
((executable-find "bash") "bash")
((executable-find "cmdproxy.exe") "cmdproxy.exe")
(t "cmd.exe"))) ;; = system shell

;; use `shell-file-name' as the default shell
(setenv "SHELL" shell-file-name)

;; switch used to have the shell execute its command line argument
;; (`/c' does not work with XEmacs)
(setq shell-command-switch
(cond ((eq shell-file-name "cmd.exe") "/c") ;; using a system shell
(t "-c")))

;; quote process arguments to ensure correct parsing on Windows
(setq w32-quote-process-args
(cond ((eq shell-file-name "cmd.exe") nil) ;; using a system shell
(t t)))

;; for the interactive (sub)shell (and AUCTeX compilation?)
(setq explicit-shell-file-name shell-file-name)
--8<---------------cut here---------------end--------------->8---

But I definitely (re-)confirm that I see es.exe processes in the ps command:

1. I type up to 2 chars in the prompt, nothing yet
2. As soon as I type a 3rd one, there is a es.exe process launched...
3. ... running for between a (sub-)second to 27 seconds (when I typed "eee" as
the pattern, for the first time)
4. es.exe disappears from the ps list without me doing anything else (no extra
char typed).

If I, then, type a 4th char, another instance of es.exe is launched.

In fact, Emacs launches a bash which launches a es.exe process. To prove my
saying, just have a look at the small screencast I just uploaded on
http://screencast.com/t/djlwcojnw.

> No crash happen as always.

I guess you don't use it for long enough -- sometimes, it takes me a day (of
real work) to get it crash. And I guess I use `helm-for-files' every 10
minutes or so (even, to switch between buffers). Maybe even more frequently...

... or there are other differences coming into play (like reactiveness of my
old laptop, or ...)

Best regards,
Fabrice Niessen

[Eli Zaretskii]

> From: Thierry Volpiatto <thierry....@gmail.com>
> Cc: Fabrice Niessen <f...@missioncriticalit.com>, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Fri, 09 Nov 2012 13:17:24 +0100

>
> > If you install Process Explorer from here:
> >
> > http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
> >
> > you will be able to display the processes in a tree-like display, so
> > you will see whether es.exe is a child process of Emacs. And in frame
> > 14, you can see the PID of the process Emacs is waiting for:
> When running helm-for-files in WindowsXP in VirtualBox, I don't see the
> "es.exe" running, only "cmdproxy.exe" which exit quickly as soon as
> candidates are found.

Maybe es.exe exits too quickly for Process Explorer to be able to
catch that. But this case, where no hangs happen, is not the one we
want to investigate. We want to see what processes are still running
when Emacs does hang.

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: Eli Zaretskii <el...@gnu.org>, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Fri, 09 Nov 2012 14:51:39 +0100

>
> I don't use cmdproxy.exe; I use Cygwin bash for all my shell calls:

Which could be the reason for the problem, btw, because Cygwin console
programs work differently wrt their standard streams than native
Windows programs.

> But I definitely (re-)confirm that I see es.exe processes in the ps command:
>
> 1. I type up to 2 chars in the prompt, nothing yet
> 2. As soon as I type a 3rd one, there is a es.exe process launched...
> 3. ... running for between a (sub-)second to 27 seconds (when I typed "eee" as
> the pattern, for the first time)
> 4. es.exe disappears from the ps list without me doing anything else (no extra
> char typed).
>
> If I, then, type a 4th char, another instance of es.exe is launched.

This is normal: I guess es.exe exits when it's done doing whatever it
was that helm-for-files invokes it.

> In fact, Emacs launches a bash which launches a es.exe process.

If helm-for-files uses shell-command or its ilk to invoke es.exe, then
this is normal.

The question is, what do you see in Emacs subprocesses when Emacs
hangs.

[Fabrice Niessen]

Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>>

>> I don't use cmdproxy.exe; I use Cygwin bash for all my shell calls:
>
> Which could be the reason for the problem, btw, because Cygwin console
> programs work differently wrt their standard streams than native
> Windows programs.

*I won't do it now*, then, but would that mean that I should use:

- cmdproxy for single shell commands, and
- bash for the interactive shell?

that is:

--8<---------------cut here---------------start------------->8---
;; for single shell commands

(setq shell-file-name "cmdproxy.exe")

;; for the interactive (sub)shell
(setq explicit-shell-file-name "bash")
--8<---------------cut here---------------end--------------->8---

However, if I do that, I loose `sort', `grep', etc. that I can call on
buffers, interactively.

Or is there some third "shell filename" which could be set only to call
external programs such as es.exe, letting me with bash tools for the subshell
in Emacs, and for commands on buffers?

>> But I definitely (re-)confirm that I see es.exe processes in the ps command.

>> In fact, Emacs launches a bash which launches a es.exe process.
>
> If helm-for-files uses shell-command or its ilk to invoke es.exe, then
> this is normal.
>
> The question is, what do you see in Emacs subprocesses when Emacs
> hangs.

I'm waiting for that... Should be known quite soon... ;-(

Best regards,
Fabrice

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: thierry....@gmail.com, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Fri, 09 Nov 2012 15:21:55 +0100

>
> Eli,
>
> Eli Zaretskii wrote:
> >> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> >>
> >> I don't use cmdproxy.exe; I use Cygwin bash for all my shell calls:
> >
> > Which could be the reason for the problem, btw, because Cygwin console
> > programs work differently wrt their standard streams than native
> > Windows programs.
>
> *I won't do it now*, then, but would that mean that I should use:
>
> - cmdproxy for single shell commands, and
> - bash for the interactive shell?
>
> that is:
>
> --8<---------------cut here---------------start------------->8---
> ;; for single shell commands
> (setq shell-file-name "cmdproxy.exe")
>
> ;; for the interactive (sub)shell
> (setq explicit-shell-file-name "bash")
> --8<---------------cut here---------------end--------------->8---

Yes, probably.

> However, if I do that, I loose `sort', `grep', etc. that I can call on
> buffers, interactively.

Why would you lose them? they are programs, not Bash scripts. Just
make sure your PATH is set up so that Emacs will find them.

[Fabrice Niessen]

Eli, Thierry,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>>

>> In fact, Emacs launches a bash which launches a es.exe process.
>
> If helm-for-files uses shell-command or its ilk to invoke es.exe, then
> this is normal.
>
> The question is, what do you see in Emacs subprocesses when Emacs
> hangs.

Got it! Same Emacs version, same shell config (bash), using only helm-locate.

http://screencast.com/t/D4zwLcdSCUzw

There is an es.exe process which is "suspended", whatever it means. Not shown
under Emacs, but maybe because it's suspended?

In my "ps" console, where I list, every second, the "es" processes (grep from
ps command), I did not see anything at the time I was filling the helm
pattern. I guess it was running for a so short amount of time (clearly less
than 1 second) that it wasn't outputted in the loop.

FYI, here the new traces...

--8<---------------cut here---------------start------------->8---
$ gdb -p 6284
[...]
Thread 1 (Thread 6284.0x1c54):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#4 0x00a41fe0 in ?? ()
#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll
#6 0x00000005 in ?? ()

#7 0x0000000b in ?? ()

#8 0x00000005 in ?? ()

#9 0x064a4e70 in ?? ()

#10 0x0108d41e in sys_close (fd=5) at w32.c:5918
#11 0x011452a8 in emacs_close (fd=5) at sysdep.c:2082

#12 0x01029ce4 in deactivate_process (proc=105533045) at process.c:3924
#13 0x01022d92 in remove_process (proc=105533045) at process.c:735
#14 0x0102ffff in status_notify (deleting_process=0x64a4e70) at process.c:6606
#15 0x01023263 in Fdelete_process (process=105533045) at process.c:850
#16 0x01013174 in eval_sub (form=65468094) at eval.c:2139
[...]
#511 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552
(gdb) thread 1
[Switching to thread 1 (Thread 6284.0x1c54)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) frame 14
#14 0x0102ffff in status_notify (deleting_process=0x64a4e70) at process.c:6606

6606 process.c: No such file or directory.
(gdb) print *p

$1 = {header = {size = 1073872914, next = {nbytes = 144, buffer = 0x90, vector = 0x90}}, tty_name = 57358362, name = 62312657,
command = 114553070, filter = 57358386, sentinel = 62592766, log = 57358362, buffer = 61535749, childp = 57358386,
plist = 57358362, type = 57481914, mark = 94066627, status = 113391638, decode_coding_system = 59149866,

decoding_buf = 20036945, encode_coding_system = 59149842, encoding_buf = 20036945, write_queue = 57358362,

gnutls_cred_type = 57358362, pid = 7108, infd = 5, outfd = 11, tick = 28, update_tick = 28, decoding_carryover = 0,

read_output_delay = 0, adaptive_read_buffering = 1, read_output_skip = 0, kill_without_query = 0, pty_flag = 0,
inherit_coding_system_flag = 0, raw_status_new = 0, raw_status = 0, gnutls_initstage = GNUTLS_STAGE_EMPTY, gnutls_state = 0x0,
gnutls_x509_cred = 0x0, gnutls_anon_cred = 0x0, gnutls_log_level = 0, gnutls_handshakes_tried = 0, gnutls_p = 0}

(gdb) print p->name
$2 = 62312657
(gdb) xstring
$3 = (struct Lisp_String *) 0x3b6d0d0

"locate-process"
(gdb) print p->command

$4 = 114553070

(gdb) xtype
Lisp_Cons
(gdb) xcons

$5 = (struct Lisp_Cons *) 0x6d3f0e8
{
car = 0x371f8b1,
u = {
cdr = 0x6d3f0e6,
chain = 0x6d3f0e6
}
}
(gdb)
--8<---------------cut here---------------end--------------->8---

Though, I've no process with PID 7108, as you can see on
http://screencast.com/t/q6AU8OZ2tk.

Does all of this help?

And what do you want me to do next?

Best regards,
Fabrice

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Fri, 09 Nov 2012 17:37:04 +0100

>
> Got it! Same Emacs version, same shell config (bash), using only helm-locate.
>
> http://screencast.com/t/D4zwLcdSCUzw
>
> There is an es.exe process which is "suspended", whatever it means. Not shown
> under Emacs, but maybe because it's suspended?

Its parent process, Bash, is not shown, so this process is an orphan.
Can you kill it from Process Explorer (by pressing Del)? If you can,
does Emacs get out of the lockup?

Next thing to try is to run es.exe from cmdproxy, not from the Cygwin
Bash.

> Though, I've no process with PID 7108, as you can see on
> http://screencast.com/t/q6AU8OZ2tk.

I think this is the PID of Bash that already exited.

> Does all of this help?

It does. We now know that Bash exits (or crashes?) and es.exe is left
behind.

> And what do you want me to do next?

Try without Bash.

[Fabrice Niessen]

Dear Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>> Cc: lek...@gmail.com, 12...@debbugs.gnu.org
>> Date: Fri, 09 Nov 2012 17:37:04 +0100
>>
>> Got it! Same Emacs version, same shell config (bash), using only helm-locate.

I was waiting for the next freeze while in Helm. It happened, but while
reading mails in Gnus. So, a different context -- though, I did not change
anything of the rest: same Emacs, same config, same Helm version, same Gnus
version, etc.

Hence, this time, there was no es.exe process involved in the problem.

Here the new backtrace:

--8<---------------cut here---------------start------------->8---
$ gdb -p 6696

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)
Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 6696
[New Thread 6696.0x4d0]
[New Thread 6696.0x1788]
[New Thread 6696.0xc28]
[New Thread 6696.0x15e4]
[New Thread 6696.0x2344]
[New Thread 6696.0x1114]
[New Thread 6696.0x4b8]
[New Thread 6696.0x20fc]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.

Warning: /cygdrive/c/Program Files/Emacs-24.2/bin/../lwlib: No such file or directory.

SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x10013b6: file emacs.c, line 317.
Temporary breakpoint 2 at 0x11441d5: file sysdep.c, line 794.

(gdb) thread apply all backtrace

Thread 8 (Thread 6696.0x20fc):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c962119 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x00000005 in ?? ()
#3 0x00000004 in ?? ()
#4 0x00000001 in ?? ()

#5 0x5adcffd0 in ?? ()

#6 0x00000000 in ?? ()

Lisp Backtrace:

"redisplay_internal (C function)" (0x167d33c)

Thread 7 (Thread 6696.0x4b8):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll
#5 0x0108d925 in _sys_read_ahead (fd=4) at w32.c:6079
#6 0x01033127 in reader_thread (arg=0x167dc98) at w32proc.c:838
#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

Lisp Backtrace:

"redisplay_internal (C function)" (0x167d33c)

Thread 6 (Thread 6696.0x1114):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d9da in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c801879 in ReadFile () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x000005fc in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:

"redisplay_internal (C function)" (0x167d33c)

Thread 5 (Thread 6696.0x2344):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7199402b in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#3 0x719957c9 in ?? () from /cygdrive/c/WINDOWS/System32/mswsock.dll
#4 0x719f67de in WSACancelAsyncRequest () from /cygdrive/c/WINDOWS/system32/Ws2_32.dll

#5 0x0108d925 in _sys_read_ahead (fd=5) at w32.c:6079
#6 0x01033127 in reader_thread (arg=0x167dc40) at w32proc.c:838

#7 0x7c80b729 in KERNEL32!GetModuleFileNameA () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#8 0x00000000 in ?? ()

---Type <return> to continue, or q <return> to quit---

Lisp Backtrace:
"redisplay_internal (C function)" (0x167d33c)

Thread 4 (Thread 6696.0x15e4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x0000060c in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:

"redisplay_internal (C function)" (0x167d33c)

Thread 3 (Thread 6696.0xc28):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#4 0x006811a0 in ?? ()
#5 0x012e871e in post_msg (lpmsg=0x5b8cfa94) at w32xfns.c:279
#6 0x01147b48 in my_post_msg (wmsg=0x5b8cfa94, hwnd=0x2cec0092, msg=0, wParam=103, lParam=2228225) at w32fns.c:1942
#7 0x01148c58 in post_character_message (hwnd=0x2cec0092, msg=0, wParam=103, lParam=2228225, modifiers=67108864) at w32fns.c:2686
#8 0x01149a12 in w32_wnd_proc (hwnd=0x2cec0092, msg=258, wParam=103, lParam=2228225) at w32fns.c:3064
#9 0x7e398734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/USER32.dll
#10 0x2cec0092 in ?? ()
#11 0x00000102 in ?? ()
#12 0x00000067 in ?? ()
#13 0x00220001 in ?? ()
#14 0x01148c5a in post_character_message (hwnd=0x0, msg=1535966776, wParam=18123866, lParam=1535966820, modifiers=2117699606)
at w32fns.c:2687
#15 0xdcbaabcd in ?? ()
#16 0x00000000 in ?? ()

Lisp Backtrace:
"redisplay_internal (C function)" (0x167d33c)

Thread 2 (Thread 6696.0x1788):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7c91d21a in ntdll!ZwDelayExecution () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c8023f1 in SleepEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll
#3 0x00000000 in ?? ()

Lisp Backtrace:

"redisplay_internal (C function)" (0x167d33c)

Thread 1 (Thread 6696.0x4d0):

---Type <return> to continue, or q <return> to quit---

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x7e3eceba in USER32!SetInternalWindowPos () from /cygdrive/c/WINDOWS/system32/USER32.dll
#2 0x7e3cf408 in USER32!SetMenu () from /cygdrive/c/WINDOWS/system32/USER32.dll
#3 0x012c6395 in set_frame_menubar (f=0x3926840 <__register_frame_info+59926592>, first_time=false, deep_p=false) at w32menu.c:610
#4 0x01200075 in update_menu_bar (f=0x3926840 <__register_frame_info+59926592>, save_match_data=0, hooks_run=1) at xdisp.c:11327
#5 0x011ffa95 in prepare_menu_bars () at xdisp.c:11205
#6 0x012055fa in redisplay_internal () at xdisp.c:13081
#7 0x012034a1 in redisplay () at xdisp.c:12653
#8 0x0103b2a2 in read_char (commandflag=1, nmaps=3, maps=0x82f9b0, prev_event=57358362, used_mouse_menu=0x82fa83, end_time=0x0)
at keyboard.c:2428
#9 0x0104eef4 in read_key_sequence (keybuf=0x82fc00, bufsize=30, prompt=57358362, dont_downcase_last=false,

can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9230

#10 0x010385c4 in command_loop_1 () at keyboard.c:1458
#11 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>, handlers=57408946, hfun=0x10378fd <cmd_error>)
at eval.c:1288
#12 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
#13 0x010108e3 in internal_catch (tag=57398802, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
#14 0x01037d11 in command_loop () at keyboard.c:1146
#15 0x010372cb in recursive_edit_1 () at keyboard.c:778
#16 0x010375f8 in Frecursive_edit () at keyboard.c:842
#17 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552

Lisp Backtrace:
"redisplay_internal (C function)" (0x167d33c)
(gdb)
(gdb) xbacktrace
"redisplay_internal (C function)" (0x167d33c)
(gdb) thread 1
[Switching to thread 1 (Thread 6696.0x4d0)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) finish
Run till exit from #0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
[Inferior 1 (process 6696) exited with code 01]

(gdb)
--8<---------------cut here---------------end--------------->8---

I tried the "finish dance" as you call it, but it never answered. I was forced
to kill Emacs by other means (here, DEL in the process explorer from
SysInternals).

Best regards,
Fabrice

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: thierry....@gmail.com, lek...@gmail.com, 12...@debbugs.gnu.org
> Date: Tue, 13 Nov 2012 09:46:14 +0100

>
> I was waiting for the next freeze while in Helm. It happened, but while
> reading mails in Gnus. So, a different context -- though, I did not change
> anything of the rest: same Emacs, same config, same Helm version, same Gnus
> version, etc.
>
> Hence, this time, there was no es.exe process involved in the problem.

This is a different problem. I think it's the same one as reported in
bug #12832, so I will reply there.

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>>

>> Got it! Same Emacs version, same shell config (bash), using only helm-locate.
>>

>> There is an es.exe process which is "suspended", whatever it means. Not shown
>> under Emacs, but maybe because it's suspended?
>
> Its parent process, Bash, is not shown, so this process is an orphan.

Got a new Emacs freeze. More info here! Read on...

Freeze just occurred:
http://content.screencast.com/users/fniessen/folders/Jing/media/8b0f5dfa-470d-4d49-a7fb-a86b8b1d9e04/2012-11-14_0932.png

One es.exe process hangin' around.

Classical GDB trace:

--8<---------------cut here---------------start------------->8---
$ gdb -p 9512

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)

[...]

Attaching to process 9512
[New Thread 9512.0x193c]
[New Thread 9512.0x1750]
[New Thread 9512.0x1c90]
[New Thread 9512.0x2714]
[New Thread 9512.0x1594]
[New Thread 9512.0x2110]
[New Thread 9512.0x1010]
[New Thread 9512.0x17c0]
[New Thread 9512.0x1998]
[New Thread 9512.0x1eec]

[...]

Thread 1 (Thread 9512.0x193c):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#4 0x00a41fbc in ?? ()

#5 0x77bfd114 in msvcrt!_close () from /cygdrive/c/WINDOWS/system32/msvcrt.dll

#6 0x00000004 in ?? ()

#7 0x0000000b in ?? ()

#8 0x00000004 in ?? ()
#9 0x037fb6f0 in __register_frame_info ()
#10 0x0108d41e in sys_close (fd=4) at w32.c:5918
#11 0x011452a8 in emacs_close (fd=4) at sysdep.c:2082
#12 0x01029ce4 in deactivate_process (proc=58701557) at process.c:3924
#13 0x01022d92 in remove_process (proc=58701557) at process.c:735
#14 0x0102ffff in status_notify (deleting_process=0x37fb6f0 <__register_frame_info+58701552>) at process.c:6606
#15 0x01023263 in Fdelete_process (process=58701557) at process.c:850
#16 0x01013174 in eval_sub (form=65502598) at eval.c:2139
[...]
#194 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552

Lisp Backtrace:

0x3e44988 Lisp type 6

"funcall" (0x82e6f0)
"unwind-protect" (0x82e8c4)
"helm-let-internal" (0x82e9b0)
"if" (0x82ec04)
"if" (0x82ed64)
"let" (0x82ef34)
"helm" (0x82f020)
"let" (0x82f334)
"helm-locate-with-db" (0x82f420)
"helm-locate-1" (0x82f630)
"helm-locate" (0x82f934)
"call-interactively" (0x82fb64)

(gdb) thread 1
[Switching to thread 1 (Thread 9512.0x193c)]

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) frame 14
#14 0x0102ffff in status_notify (deleting_process=0x37fb6f0 <__register_frame_info+58701552>) at process.c:6606

6606 process.c: No such file or directory.
(gdb) print *p
$1 = {
header = {
size = 1073872914,
next = {
nbytes = 144,
buffer = 0x90,
vector = 0x90
}
},
tty_name = 57358362,

name = 58410881,
command = 84995798,
filter = 57358386,
sentinel = 62531782,
log = 57358362,
buffer = 61534213,

childp = 57358386,
plist = 57358362,
type = 57481914,

mark = 79175683,
status = 85116598,

decode_coding_system = 59149866,
decoding_buf = 20036945,
encode_coding_system = 59149842,
encoding_buf = 20036945,
write_queue = 57358362,
gnutls_cred_type = 57358362,

pid = 6672,
infd = 4,
outfd = 11,
tick = 22,
update_tick = 22,

decoding_carryover = 0,
read_output_delay = 0,
adaptive_read_buffering = 1,
read_output_skip = 0,
kill_without_query = 0,
pty_flag = 0,
inherit_coding_system_flag = 0,
raw_status_new = 0,
raw_status = 0,
gnutls_initstage = GNUTLS_STAGE_EMPTY,
gnutls_state = 0x0,
gnutls_x509_cred = 0x0,
gnutls_anon_cred = 0x0,
gnutls_log_level = 0,
gnutls_handshakes_tried = 0,
gnutls_p = 0
}
(gdb) print p->name

$2 = 58410881
(gdb) xstring
$3 = (struct Lisp_String *) 0x37b4780 <__register_frame_info+58410880>

"locate-process"
(gdb) print p->command

$4 = 84995798

(gdb) xtype
Lisp_Cons
(gdb) xcons

$5 = (struct Lisp_Cons *) 0x510eed0
{
car = 0x3748091,
u = {
cdr = 0x510eede,
chain = 0x510eede
}
}
(gdb) quit
A debugging session is active.

Inferior 1 [process 9512] will be detached.

Quit anyway? (y or n) y
Detaching from program: /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe, Pid 9512
--8<---------------cut here---------------end--------------->8---

Though, I've no process with PID 6672, as you can see on the above screenshot.
As you say, it could be the PID of Bash that already exited.

> Can you kill it from Process Explorer (by pressing Del)? If you can,
> does Emacs get out of the lockup?

Now, killing es.exe from the Process Explorer *did unblock Emacs*, as you can
see on
http://content.screencast.com/users/fniessen/folders/Jing/media/fd8b4e53-5232-451a-9757-7623950365cd/2012-11-14_0938.png:
I just recovered where I was, in Helm, with the correct files show now -- I
had previously typed more characters in the pattern, when Emacs just froze...
Now, they reappeared, with correct results from the "locate" command.

Great news, I guess, in the understanding of what happens...

> Next thing to try is to run es.exe from cmdproxy, not from the Cygwin
> Bash.

Next thing for me, then, is to try without Bash for shell-file-name:

--8<---------------cut here---------------start------------->8---
(setq shell-file-name "cmdproxy")

(setq explicit-shell-file-name "bash")
--8<---------------cut here---------------end--------------->8---

Best regards,
Fabrice

[Fabrice Niessen]

Hi Eli,

"Fabrice Niessen" wrote:
> Eli Zaretskii wrote:

>> Can you kill it from Process Explorer (by pressing Del)? If you can,
>> does Emacs get out of the lockup?
>
> Now, killing es.exe from the Process Explorer *did unblock Emacs*, as you can
> see on
> http://content.screencast.com/users/fniessen/folders/Jing/media/fd8b4e53-5232-451a-9757-7623950365cd/2012-11-14_0938.png:
> I just recovered where I was, in Helm, with the correct files show now -- I
> had previously typed more characters in the pattern, when Emacs just froze...
> Now, they reappeared, with correct results from the "locate" command.
>
> Great news, I guess, in the understanding of what happens...

Did you see this? Does it tell you something more?

>> Next thing to try is to run es.exe from cmdproxy, not from the Cygwin
>> Bash.
>
> Next thing for me, then, is to try without Bash for shell-file-name:
>

> (setq shell-file-name "cmdproxy")
> (setq explicit-shell-file-name "bash")

As said, I'm in this latest configuration for a couple of days, now. I have
not yet had any other "freeze" while using helm's locate feature (es.exe).

... but I just go a real crash now.

Once again, nothing changed, except these 2 lines in my Emacs config file. For
the rest, still my Emacs version of 2012-10-22, same Helm, and, well,
up-to-date Org (version 7.9.2, release_7.9.2-604-ge507ef).

And the crash occurred while clicking on one Org agenda line. Something very
common, though...

--8<---------------cut here---------------start------------->8---
$ gdb -p 8964

GNU gdb (GDB) 7.5.50.20120815-cvs (cygwin-special)

Copyright (C) 2012 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 "i686-cygwin".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 8964
[New Thread 8964.0x16f0]
[New Thread 8964.0x1084]
[New Thread 8964.0x1c78]
[New Thread 8964.0x25b4]
[New Thread 8964.0x1378]

Reading symbols from /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe...done.
Warning: /cygdrive/c/Program Files/Emacs-24.2/bin/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
TERM = xterm-256color
Breakpoint 1 at 0x10013b6: file emacs.c, line 317.
Temporary breakpoint 2 at 0x11441d5: file sysdep.c, line 794.

(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 8964.0x16f0]

0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

(gdb) thread apply all backtrace

Thread 4 (Thread 8964.0x25b4):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000564 in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:
"redisplay_internal (C function)" (0x167d33c)

Thread 3 (Thread 8964.0x1c78):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#2 0x7c8025db in WaitForSingleObjectEx () from /cygdrive/c/WINDOWS/system32/kernel32.dll

#3 0x00000660 in ?? ()

#4 0x00000000 in ?? ()

Lisp Backtrace:
"redisplay_internal (C function)" (0x167d33c)

Thread 2 (Thread 8964.0x1084):

#0 0x7c91e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c91df5a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x7c929b23 in ntdll!RtlpWaitForCriticalSection () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#3 0x7c911046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#4 0x006811a0 in ?? ()

#5 0x01147b48 in my_post_msg (wmsg=0x5b8cfc78, hwnd=0x1ff091e, msg=6, wParam=0, lParam=0) at w32fns.c:1942
#6 0x0114bee0 in w32_wnd_proc (hwnd=0x1ff091e, msg=6, wParam=0, lParam=0) at w32fns.c:3634
#7 0x7e398734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/USER32.dll
#8 0x01ff091e in ?? ()
#9 0x7e398816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/USER32.dll
#10 0x01148c5a in post_character_message (hwnd=0x6, msg=0, wParam=0, lParam=0, modifiers=33491230) at w32fns.c:2687
#11 0x01ff091e in ?? ()
#12 0x7e3a8ea0 in USER32!DefWindowProcW () from /cygdrive/c/WINDOWS/system32/USER32.dll
#13 0x00000000 in ?? ()

Lisp Backtrace:
"redisplay_internal (C function)" (0x167d33c)

Thread 1 (Thread 8964.0x16f0):

#0 0x7c91120f in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll

#1 0x011546ce in emacs_abort () at w32fns.c:7706
#2 0x0100145d in terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:344
#3 0x010219af in die (msg=0x15cb402 "assertion failed: s->img", file=0x15bf3b0 "xdisp.c", line=22866) at alloc.c:6440
#4 0x01226d67 in fill_image_glyph_string (s=0x82eba0) at xdisp.c:22866
#5 0x01228070 in draw_glyphs (w=0x6d53da0, x=92, row=0x799f350, area=TEXT_AREA, start=0, end=119, hl=DRAW_NORMAL_TEXT, overlaps=0)

---Type <return> to continue, or q <return> to quit---

at xdisp.c:23444
#6 0x01230ef3 in x_write_glyphs (start=0x7a28000, len=119) at xdisp.c:25340
#7 0x010f54b3 in update_text_area (w=0x6d53da0, vpos=124) at dispnew.c:3718
#8 0x010f5ed6 in update_window_line (w=0x6d53da0, vpos=124, mouse_face_overwritten_p=0x82f107) at dispnew.c:3964
#9 0x010f4f45 in update_window (w=0x6d53da0, force_p=true) at dispnew.c:3520
#10 0x010f4688 in update_window_tree (w=0x6d53da0, force_p=true) at dispnew.c:3286
#11 0x010f45c7 in update_window_tree (w=0x556c358, force_p=true) at dispnew.c:3282
#12 0x010f43aa in update_frame (f=0x3926840 <__register_frame_info+59926592>, force_p=true, inhibit_hairy_id_p=false)
at dispnew.c:3215
#13 0x0120683b in redisplay_internal () at xdisp.c:13490
#14 0x011fc7ff in resize_echo_area_exactly () at xdisp.c:10270
#15 0x01038e6e in command_loop_1 () at keyboard.c:1605
#16 0x01010e86 in internal_condition_case (bfun=0x10380de <command_loop_1>, handlers=57408946, hfun=0x10378fd <cmd_error>)
at eval.c:1288
#17 0x01037d57 in command_loop_2 (ignore=57358362) at keyboard.c:1167
#18 0x010108e3 in internal_catch (tag=57398802, func=0x1037d33 <command_loop_2>, arg=57358362) at eval.c:1059
#19 0x01037d11 in command_loop () at keyboard.c:1146
#20 0x010372cb in recursive_edit_1 () at keyboard.c:778
#21 0x010375f8 in Frecursive_edit () at keyboard.c:842
#22 0x01002920 in main (argc=1, argv=0xa44480) at emacs.c:1552

Lisp Backtrace:

"redisplay_internal (C function)" (0x167d33c)
(gdb) xbacktrace
"redisplay_internal (C function)" (0x167d33c)

(gdb) quit
A debugging session is active.

Inferior 1 [process 8964] will be detached.

Quit anyway? (y or n) y

Detaching from program: /cygdrive/c/Program Files/Emacs-24.2/bin/emacs.exe, Pid 8964

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: thierry....@gmail.com, lek...@gmail.com, 12...@debbugs.gnu.org

> Date: Fri, 16 Nov 2012 10:21:06 +0100

>
> "Fabrice Niessen" wrote:
> > Eli Zaretskii wrote:
> >> Can you kill it from Process Explorer (by pressing Del)? If you can,
> >> does Emacs get out of the lockup?
> >
> > Now, killing es.exe from the Process Explorer *did unblock Emacs*, as you can
> > see on
> > http://content.screencast.com/users/fniessen/folders/Jing/media/fd8b4e53-5232-451a-9757-7623950365cd/2012-11-14_0938.png:
> > I just recovered where I was, in Helm, with the correct files show now -- I
> > had previously typed more characters in the pattern, when Emacs just froze...
> > Now, they reappeared, with correct results from the "locate" command.
> >
> > Great news, I guess, in the understanding of what happens...
>
> Did you see this? Does it tell you something more?

I did see it, but I'm waiting for your report on using es.exe from
cmdproxy.

> ... but I just go a real crash now.

This is an entirely different issue, please report it as a separate
bug. It is not right to lump every possible crash under the same bug
number.

Thanks.

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:

>> From: "Fabrice Niessen" <f...@missioncriticalit.com>
>> Cc: thierry....@gmail.com, lek...@gmail.com, 12...@debbugs.gnu.org
>> Date: Fri, 16 Nov 2012 10:21:06 +0100
>>
>> "Fabrice Niessen" wrote:
>> > Eli Zaretskii wrote:
>> >> Can you kill it from Process Explorer (by pressing Del)? If you can,
>> >> does Emacs get out of the lockup?
>> >
>> > Now, killing es.exe from the Process Explorer *did unblock Emacs*, as you can
>> > see on
>> > http://content.screencast.com/users/fniessen/folders/Jing/media/fd8b4e53-5232-451a-9757-7623950365cd/2012-11-14_0938.png:
>> > I just recovered where I was, in Helm, with the correct files show now -- I
>> > had previously typed more characters in the pattern, when Emacs just froze...
>> > Now, they reappeared, with correct results from the "locate" command.
>> >
>> > Great news, I guess, in the understanding of what happens...
>>
>> Did you see this? Does it tell you something more?
>
> I did see it, but I'm waiting for your report on using es.exe from
> cmdproxy.

Up to now, no freeze...

>> ... but I just go a real crash now.
>
> This is an entirely different issue, please report it as a separate
> bug. It is not right to lump every possible crash under the same bug
> number.

Done. Sorry.

Best regards,
Fabrice

[Fabrice Niessen]

Hi Eli,

Eli Zaretskii wrote:
>> From: "Fabrice Niessen" <f...@missioncriticalit.com>

>> "Fabrice Niessen" wrote:
>> > Eli Zaretskii wrote:
>> >> Can you kill it from Process Explorer (by pressing Del)? If you can,
>> >> does Emacs get out of the lockup?
>> >
>> > Now, killing es.exe from the Process Explorer *did unblock Emacs*, as you can
>> > see on
>> > http://content.screencast.com/users/fniessen/folders/Jing/media/fd8b4e53-5232-451a-9757-7623950365cd/2012-11-14_0938.png:
>> > I just recovered where I was, in Helm, with the correct files show now -- I
>> > had previously typed more characters in the pattern, when Emacs just froze...
>> > Now, they reappeared, with correct results from the "locate" command.
>> >
>> > Great news, I guess, in the understanding of what happens...
>>
>> Did you see this? Does it tell you something more?
>
> I did see it, but I'm waiting for your report on using es.exe from
> cmdproxy.

After many days of intensive Emacs use, I can tell that Everything does not
block Emacs anymore, when

(setq shell-file-name "cmdproxy") [1]

So, thanks to that (and to you), I don't have big problems anymore. GREAT.

Though, I inherit other problems due to bad handling of miscellaneous styles
of directory separator in the full filenames: among others, I now have
troubles launching my PDF viewer from AUCTeX.

The displayed command for the View action is:

"C:\Program Files/SumatraPDF/SumatraPDF.exe" "ecm.pdf"

When `shell-file-name' is `bash', SumatraPDF is launched normally.

When `shell-file-name' is `cmdproxy', nothing happens. Really nothing, btw:
not even a message in the echo area, nor in the Messages buffer. Same
behavior for `cmd'. No PDF viewer.

Okay, I admit the above command is a bit (or more?) awkward due to the mix of
slashes and (unescaped) backslashes. But this used to work before, and I'm
fearing to loose such working behaviors by fully switching from `bash' to
`cmdproxy'[2].

Why is the command that specially written? Because I tried to abstract the
definition of the localization of SumatraPDF so that it can work on my PC
(32-bit Win XP) and on my colleagues' PC (64-bit Win 7), automatically finding
out the correct path between `c:\Program Files' and potential differences
(`c:\Program Files (x86)' or some such differences in the future), by having:

--8<---------------cut here---------------start------------->8---
(defconst windows-program-files-dir
(concat (getenv "PROGRAMFILES") "/")
"Defines the default Windows Program Files folder.")

(defvar sumatrapdf-command
(concat windows-program-files-dir "SumatraPDF/SumatraPDF.exe")
"Path to the SumatraPDF executable.")
--8<---------------cut here---------------end--------------->8---

Is it that bad?

Hence, 2 questions:

- Is using `cmdproxy' really the only way to handle properly the communication
between Emacs and Everything?

- I see (in Process Explorer) that `cmdproxy' launches a `cmd' process: why
not directly setting up `shell-file-name' to `cmd'? Are there reasons not
to do so?

Best regards,
Fabrice

[1] FYI, I left explicit-shell-file-name as it was initially in my config:
(setq explicit-shell-file-name "bash").

[2] I loose, anyway, the ability to call personal (Bash) scripts on buffers or
regions from within Emacs, when switching to `cmdproxy'.

[Eli Zaretskii]

> From: "Fabrice Niessen" <f...@missioncriticalit.com>
> Cc: thierry....@gmail.com, lek...@gmail.com, 12...@debbugs.gnu.org

> Date: Wed, 21 Nov 2012 16:35:35 +0100

>
> After many days of intensive Emacs use, I can tell that Everything does not
> block Emacs anymore, when
>
> (setq shell-file-name "cmdproxy") [1]
>
> So, thanks to that (and to you), I don't have big problems anymore. GREAT.

This is good news. However, I would encourage you to try a newer
snapshot of the development trunk, where the way Emacs reaps its
subprocesses was enhanced, and the problems you saw with Bash might
disappear.

> Though, I inherit other problems due to bad handling of miscellaneous styles
> of directory separator in the full filenames: among others, I now have
> troubles launching my PDF viewer from AUCTeX.

Let's discuss these problems in a separate thread, or a separate bug
report.

[Stefan Monnier]

> (concat (getenv "PROGRAMFILES") "/")

Try (file-name-as-directory (getenv "PROGRAMFILES")).


Stefan

[Stefan Monnier]

> (defconst windows-program-files-dir

> (concat (getenv "PROGRAMFILES") "/")

> "Defines the default Windows Program Files folder.")

> (defvar sumatrapdf-command
> (concat windows-program-files-dir "SumatraPDF/SumatraPDF.exe")
> "Path to the SumatraPDF executable.")

If you replace (concat windows-program-files-dir "SumatraPDF/SumatraPDF.exe")
with (expand-file-name "SumatraPDF/SumatraPDF.exe" windows-program-files-dir)
it should work properly (and you can even just use (getenv
"PROGRAMFILES") for windows-program-files-dir, because expand-file-name
will add a slash if necessary).


Stefan