GNU bug report logs - #22301
25.1.50; Emacs crashes while lisp debugging

Previous Next

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

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

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
To: bug-gnu-emacs <at> gnu.org
Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Subject: 25.1.50; Emacs crashes while lisp debugging
Date: Sun, 03 Jan 2016 23:43:14 +0100

Here is the gdb backtrace which I got after attaching gdb to Emacs:

-8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----
Vincent <at> AIGLEROYAL /c/Programmes/installation/emacs-install/master/emacs/src
$ gdb -p 6556
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 6556
[New Thread 6556.0xedc]
[New Thread 6556.0x1b90]
[New Thread 6556.0x2654]
[New Thread 6556.0xfe8]
Reading symbols from C:\Nos_Programmes\GNU\Emacs\bin\emacs.exe...done.
To enable execution of this file add
	add-auto-load-safe-path c:\Programmes\installation\emacs-install\master\emacs\src\.gdbinit
line to your configuration file "c:/Users/Vincent/AppData/Roaming/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "c:/Users/Vincent/AppData/Roaming/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb) warning: File "c:\Programmes\installation\emacs-install\master\emacs\src\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load;C:\Programmes\installation\emacs-install\emacs\trunk\src\.gdbinit".

(gdb) 
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 6556.0xedc]
0x75fb82e3 in KERNELBASE!DebugBreak () from C:\WINDOWS\SYSTEM32\KernelBase.dll
(gdb) bt full
#0  0x75fb82e3 in KERNELBASE!DebugBreak ()
   from C:\WINDOWS\SYSTEM32\KernelBase.dll
No symbol table info available.
#1  0x0114d335 in emacs_abort () at w32fns.c:9780
        button = <optimized out>
#2  0x01095247 in terminate_due_to_signal (sig=sig <at> entry=11, 
    backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:398
No locals.
#3  0x010aa7f2 in handle_fatal_signal (sig=sig <at> entry=11) at sysdep.c:1591
No locals.
#4  0x010aa8ea in deliver_thread_signal (
    handler=0x10aa7db <handle_fatal_signal>, sig=11) at sysdep.c:1565
No locals.
#5  deliver_fatal_thread_signal (sig=11) at sysdep.c:1603
No locals.
#6  0x010010f9 in _gnu_exception_handler <at> 4 ()
No symbol table info available.
#7  0x75fbf462 in UnhandledExceptionFilter ()
   from C:\WINDOWS\SYSTEM32\KernelBase.dll
No symbol table info available.
#8  0x00bfdbb4 in ?? ()
No symbol table info available.
#9  0x771e2ccb in ntdll!WinSqmEventWrite () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#10 0x00bfdbb4 in ?? ()
No symbol table info available.
#11 0x771a568e in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#12 0xffffffff in ?? ()
No symbol table info available.
#13 0x771cb6df in ntdll!RtlCaptureContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.
(gdb) xbacktrace
(gdb) Undefined command: "xbacktrace".  Try "help".

quit
A debugging session is active.

	Inferior 1 [process 6556] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Detaching from program: C:\Nos_Programmes\GNU\Emacs\bin\emacs.exe, Pid 6556
-8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<----

The crash happened while I was debugging a modified version of SES. I
am not sure I can reproduce it.




In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2015-12-16
Repository revision: 23b5c22703eeee7b4fe6608ce12ffe3b87794933
Windowing system distributor 'Microsoft Corp.', version 10.0.10586
Configured using:
 'configure --prefix=c:/Nos_Programmes/GNU/Emacs --without-jpeg
 --without-tiff --without-gif --without-png 'CPPFLAGS= -DFOR_MSW=1 -I
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/include -I
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/src -L
 C:/Programmes/installation/emacs-install/libXpm-3.5.8/src''

Configured features:
XPM SOUND NOTIFY ACL TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: FRA
  locale-coding-system: cp1252

Major mode: Shell

Minor modes in effect:
  shell-dirtrack-mode: t
  recentf-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  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 messages:
]0;MINGW32:/c
[32mVincent <at> AIGLEROYAL [33m/c[0m
$ <=
bash refresh default directory ... done
c:/Programmes/installation/emacs-install/master/emacs/src 
Mark set
Making completion list...
Loading dired-x...done
Quit
GNU Emacs 25.1.50.1 (i686-pc-mingw32) of 2015-12-16

Load-path shadows:
c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs hides c:/Nos_Programmes/GNU/Emacs/share/emacs/25.1.50/lisp/loaddefs
c:/Programmes/installation/cedet-install/cedet-git/lisp/speedbar/loaddefs hides c:/Programmes/installation/cedet-install/cedet-git/lisp/cedet/loaddefs

Features:
(shadow sort bbdb-message gnus-util mail-extr emacsbug message dired-x
dired format-spec rfc822 mml mml-sec mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns help-mode mail-prsvr mail-utils
pcmpl-unix shell pcomplete comint ansi-color ring edmacro kmacro
skeleton calc-misc calc-arith calc-ext calc calc-loaddefs calc-macs
tex-mik preview-latex tex-site auto-loads bbdb bbdb-site timezone
bbdb-loaddefs template w32utils cl-seq cl-macs cl gv recentf tree-widget
wid-edit cl-loaddefs pcase cl-lib easymenu load-path-to-cedet-svn
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 8 138522 6955)
 (symbols 32 24625 0)
 (miscs 32 96 163)
 (strings 16 27894 4614)
 (string-bytes 1 825847)
 (vectors 8 15431)
 (vector-slots 4 460319 8130)
 (floats 8 153 185)
 (intervals 28 926 208)
 (buffers 516 14))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Mon, 04 Jan 2016 05:41:09 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
> Date: Sun, 03 Jan 2016 23:43:14 +0100
> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 6556.0xedc]
> 0x75fb82e3 in KERNELBASE!DebugBreak () from C:\WINDOWS\SYSTEM32\KernelBase.dll
> (gdb) bt full
> #0  0x75fb82e3 in KERNELBASE!DebugBreak ()
>    from C:\WINDOWS\SYSTEM32\KernelBase.dll
> No symbol table info available.
> #1  0x0114d335 in emacs_abort () at w32fns.c:9780
>         button = <optimized out>
> #2  0x01095247 in terminate_due_to_signal (sig=sig <at> entry=11, 
>     backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:398
> No locals.
> #3  0x010aa7f2 in handle_fatal_signal (sig=sig <at> entry=11) at sysdep.c:1591
> No locals.
> #4  0x010aa8ea in deliver_thread_signal (
>     handler=0x10aa7db <handle_fatal_signal>, sig=11) at sysdep.c:1565
> No locals.
> #5  deliver_fatal_thread_signal (sig=11) at sysdep.c:1603
> No locals.
> #6  0x010010f9 in _gnu_exception_handler <at> 4 ()
> No symbol table info available.
> #7  0x75fbf462 in UnhandledExceptionFilter ()
>    from C:\WINDOWS\SYSTEM32\KernelBase.dll
> No symbol table info available.
> #8  0x00bfdbb4 in ?? ()
> No symbol table info available.
> #9  0x771e2ccb in ntdll!WinSqmEventWrite () from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #10 0x00bfdbb4 in ?? ()
> No symbol table info available.
> #11 0x771a568e in ntdll!RtlUnicodeStringToInteger ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #12 0xffffffff in ?? ()
> No symbol table info available.
> #13 0x771cb6df in ntdll!RtlCaptureContext ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #14 0x00000000 in ?? ()
> No symbol table info available.
> (gdb) xbacktrace
> (gdb) Undefined command: "xbacktrace".  Try "help".

You attached the debugger too late, or maybe this is the wrong
thread.  The backtrace is not informative.

Also:

> (gdb) warning: File "c:\Programmes\installation\emacs-install\master\emacs\src\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load;C:\Programmes\installation\emacs-install\emacs\trunk\src\.gdbinit".

This needs to be fixed.

> The crash happened while I was debugging a modified version of SES. I
> am not sure I can reproduce it.

If you are unable to reproduce, there's nothing that can be done with
this report, sorry.

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>, 
Cc: 22301 <at> debbugs.gnu.org,
 Vincent Belaïche <vincent.belaiche <at> gmail.com>
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Mon, 04 Jan 2016 09:00:42 +0100

Well, I had another crash --- still debugging some SES functions as I
need to fix my own bugs... Here it is:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
Vincent <at> AIGLEROYAL /c/Programmes/installation/emacs-install/master/emacs/src
$ gdb -p 11676
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 11676
[New Thread 11676.0x1edc]
[New Thread 11676.0x2f4]
[New Thread 11676.0x2c48]
[New Thread 11676.0x1ec8]
[New Thread 11676.0x267c]
[New Thread 11676.0x2aa0]
[New Thread 11676.0xafc]
Reading symbols from C:\Nos_Programmes\GNU\Emacs\bin\emacs.exe...done.
To enable execution of this file add
	add-auto-load-safe-path c:\Programmes\installation\emacs-install\master\emacs\src\.gdbinit
line to your configuration file "c:/Users/Vincent/AppData/Roaming/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "c:/Users/Vincent/AppData/Roaming/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb) warning: File "c:\Programmes\installation\emacs-install\master\emacs\src\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load;C:\Programmes\installation\emacs-install\master\emacs\trunk\src\.gdbinit;C:\Programmes\installation\emacs-install\emacs-25\emacs\trunk\src\.gdbinit".
quit
A debugging session is active.

	Inferior 1 [process 11676] will be detached.

Quit anyway? (y or n) [answered Y; input not from terminal]
Detaching from program: C:\Nos_Programmes\GNU\Emacs\bin\emacs.exe, Pid 11676
]0;MINGW32:/c/Programmes/installation/emacs-install/master/emacs/src
Vincent <at> AIGLEROYAL /c/Programmes/installation/emacs-install/master/emacs/src
$ 
]0;MINGW32:/c/Programmes/installation/emacs-install/master/emacs/src
Vincent <at> AIGLEROYAL /c/Programmes/installation/emacs-install/master/emacs/src
$ gdb -p 11676
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 11676
[New Thread 11676.0x1edc]
[New Thread 11676.0x2f4]
[New Thread 11676.0x2c48]
[New Thread 11676.0x1ec8]
[New Thread 11676.0x267c]
[New Thread 11676.0x2aa0]
[New Thread 11676.0x430]
Reading symbols from C:\Nos_Programmes\GNU\Emacs\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]
DISPLAY = w32
TERM = emacs
Breakpoint 1 at 0x10951bb: file emacs.c, line 370.
Temporary breakpoint 2 at 0x10aabd6: file sysdep.c, line 901.
(gdb) bt full
#0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0xfb32daaf in ?? ()
No symbol table info available.
#3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
No symbol table info available.
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)
(gdb) xbacktrace
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)
(gdb)
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

The debugging session is still opened, so please feel free to give
instructions if you want further details.

VBR,
	Vincent

PS: The emacs.exe that causes the crash is not exactly what I have in
the src because I had done some git pull meanwhile after my latest
installation.

Le 04/01/2016 04:41, Eli Zaretskii a écrit :
>> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
>> Date: Sun, 03 Jan 2016 23:43:14 +0100
>> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
>>

[...]

>
> You attached the debugger too late, or maybe this is the wrong
> thread.  The backtrace is not informative.
>
> Also:
>
>> (gdb) warning: File "c:\Programmes\installation\emacs-install\master\emacs\src\.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load;C:\Programmes\installation\emacs-install\emacs\trunk\src\.gdbinit".
>
> This needs to be fixed.
>
>> The crash happened while I was debugging a modified version of SES. I
>> am not sure I can reproduce it.
>
> If you are unable to reproduce, there's nothing that can be done with
> this report, sorry.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Mon, 04 Jan 2016 17:54:59 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
> Cc: Vincent Belaïche <vincent.belaiche <at> gmail.com> ,
>  22301 <at> debbugs.gnu.org
> Date: Mon, 04 Jan 2016 09:00:42 +0100
> 
> Lisp Backtrace:
> "backtrace" (0xbfedac)
> "debugger-setup-buffer" (0xbfefe0)
> "debug" (0xbff1b4)
> "ses-relocate-all" (0xbff200)
> "let" (0xbff3bc)
> "ses-delete-row" (0xbff598)
> "funcall-interactively" (0xbff594)
> "call-interactively" (0xbff710)
> "command-execute" (0xbff8dc)
> (gdb) xbacktrace
> "backtrace" (0xbfedac)
> "debugger-setup-buffer" (0xbfefe0)
> "debug" (0xbff1b4)
> "ses-relocate-all" (0xbff200)
> "let" (0xbff3bc)
> "ses-delete-row" (0xbff598)
> "funcall-interactively" (0xbff594)
> "call-interactively" (0xbff710)
> "command-execute" (0xbff8dc)
> (gdb)
> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----
> 
> The debugging session is still opened, so please feel free to give
> instructions if you want further details.

Thanks.  Please type this at GDB prompt:

 (gdb) thread 1
 (gdb) thread apply all bt

and post here everything that GDB produces.

Please leave the debugging session running after you do that, in case
we will need to ask you to look around some more.

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>, 
Cc: 22301 <at> debbugs.gnu.org,
 Vincent Belaïche <vincent.belaiche <at> gmail.com>
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Mon, 04 Jan 2016 23:49:53 +0100

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

Dear Éli,

Answers below...

Le 04/01/2016 16:54, Eli Zaretskii a écrit :
>> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
>> Cc: Vincent Belaïche <vincent.belaiche <at> gmail.com> ,
>>  22301 <at> debbugs.gnu.org
>> Date: Mon, 04 Jan 2016 09:00:42 +0100
>>

[...]

>>
>> The debugging session is still opened, so please feel free to give
>> instructions if you want further details.
>
> Thanks.  Please type this at GDB prompt:
>
>  (gdb) thread 1
>  (gdb) thread apply all bt
>
> and post here everything that GDB produces.
>
> Please leave the debugging session running after you do that, in case
> we will need to ask you to look around some more.

Here is it:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
(gdb) thread 1
[Switching to thread 1 (Thread 11676.0x1edc)]
#0  SDATA (string=1461725984) at lisp.h:1325
1325	  return XSTRING (string)->data;
(gdb)  thread apply all bt

Thread 7 (Thread 11676.0x430):
#0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0xfb32daaf in ?? ()
#3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00000000 in ?? ()

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)

Thread 6 (Thread 11676.0x2aa0):
#0  0x771b868c in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x7718a246 in ntdll!EtwNotificationRegister ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#3  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00c844c0 in ?? ()
#5  0x771a568e in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0xffffffff in ?? ()
#7  0x771cb6c3 in ntdll!RtlCaptureContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x00000000 in ?? ()

--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

Please note that I don't get again the debugger prompt --- I am running
the debugger from an Emacs shell buffer, could it be some interaction
that the buffer process sentinel could not capture ? Anyway, I am
keeping the gdb session open, as you asked...

Not sure whether that is useful or not, but please also note that when
Emacs crashed, then I did not get the Yes/No popup asking to attach the
debugger, etc... but the MSWindow usual crash popup (PNG attached)

VBR,
	Vincent

[Sans titre.png (image/png, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Tue, 05 Jan 2016 05:34:45 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
> Cc: Vincent Belaïche <vincent.belaiche <at> gmail.com> ,
>  22301 <at> debbugs.gnu.org
> Date: Mon, 04 Jan 2016 23:49:53 +0100
> 
> (gdb) thread 1
> [Switching to thread 1 (Thread 11676.0x1edc)]
> #0  SDATA (string=1461725984) at lisp.h:1325
> 1325	  return XSTRING (string)->data;
> (gdb)  thread apply all bt
> 
> Thread 7 (Thread 11676.0x430):
> #0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
> #1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #2  0xfb32daaf in ?? ()
> #3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
>    from C:\WINDOWS\SYSTEM32\kernel32.dll
> #5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #6  0x00000000 in ?? ()
> 
> Lisp Backtrace:
> "backtrace" (0xbfedac)
> "debugger-setup-buffer" (0xbfefe0)
> "debug" (0xbff1b4)
> "ses-relocate-all" (0xbff200)
> "let" (0xbff3bc)
> "ses-delete-row" (0xbff598)
> "funcall-interactively" (0xbff594)
> "call-interactively" (0xbff710)
> "command-execute" (0xbff8dc)
> 
> Thread 6 (Thread 11676.0x2aa0):
> #0  0x771b868c in ntdll!ZwWaitForWorkViaWorkerFactory ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #1  0x7718a246 in ntdll!EtwNotificationRegister ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #2  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
>    from C:\WINDOWS\SYSTEM32\kernel32.dll
> #3  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #4  0x00c844c0 in ?? ()
> #5  0x771a568e in ntdll!RtlUnicodeStringToInteger ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #6  0xffffffff in ?? ()
> #7  0x771cb6c3 in ntdll!RtlCaptureContext ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #8  0x00000000 in ?? ()
> 
> --8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----
> 
> Please note that I don't get again the debugger prompt --- I am running
> the debugger from an Emacs shell buffer, could it be some interaction
> that the buffer process sentinel could not capture ? Anyway, I am
> keeping the gdb session open, as you asked...

Do you get the GDB prompt back if you press F-12 or Ctrl-C?  If not,
this session is ruined, and you can stop it.

Next time when it happens, type these commands instead:

  (gdb) thread 1
  (gdb) bt

Better yet, run Emacs from GDB to begin with, it will make the
backtrace more reliable.

Thanks.

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
To: Eli Zaretskii <eliz <at> gnu.org>, 
Cc: 22301 <at> debbugs.gnu.org,
 Vincent Belaïche <vincent.belaiche <at> gmail.com>
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Tue, 05 Jan 2016 08:17:17 +0100

Dear Éli,

Something I had forgotten to tell you: I think that I have compiled this
Emacs with Mingw-w64 --- well I am not 100% sure now because at some
point of time I had problems with Minfw-64 (see
https://sourceforge.net/p/mingw-w64/bugs/519/) and I have re-installed
the 32 bit version (both coexist now on my machine and I select the one
in use by editing the fstab file).

Anyway, I still don't get the debugger prompt, neither Ctrl-C (well C-Q
C-C because I am running it from Emacs), nor F-12 do anything. However,
if I do:

  M-x signal-process RET
  shell RET
  3 RET

then something happens with the debugger, I did it several times, I
still don't get the prompt, but there is that sort of output:

  Program received signal SIGTRAP, Trace/breakpoint trap

So below, I copied the full gdb session with these. Please make me know
whether this session is ruined or not.

Le 05/01/2016 04:34, Eli Zaretskii a écrit :
>> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
>> Cc: Vincent Belaïche <vincent.belaiche <at> gmail.com> ,
>>  22301 <at> debbugs.gnu.org
>> Date: Mon, 04 Jan 2016 23:49:53 +0100
>>

[...]

>> Please note that I don't get again the debugger prompt --- I am running
>> the debugger from an Emacs shell buffer, could it be some interaction
>> that the buffer process sentinel could not capture ? Anyway, I am
>> keeping the gdb session open, as you asked...
>
> Do you get the GDB prompt back if you press F-12 or Ctrl-C?  If not,
> this session is ruined, and you can stop it.
>
> Next time when it happens, type these commands instead:
>
>   (gdb) thread 1
>   (gdb) bt
>
> Better yet, run Emacs from GDB to begin with, it will make the
> backtrace more reliable.
>
> Thanks.

Here is the full session (you already got the beginning of it):

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
$ gdb -p 11676
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 11676
[New Thread 11676.0x1edc]
[New Thread 11676.0x2f4]
[New Thread 11676.0x2c48]
[New Thread 11676.0x1ec8]
[New Thread 11676.0x267c]
[New Thread 11676.0x2aa0]
[New Thread 11676.0x430]
Reading symbols from C:\Nos_Programmes\GNU\Emacs\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]
DISPLAY = w32
TERM = emacs
Breakpoint 1 at 0x10951bb: file emacs.c, line 370.
Temporary breakpoint 2 at 0x10aabd6: file sysdep.c, line 901.
(gdb) bt full
#0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#2  0xfb32daaf in ?? ()
No symbol table info available.
#3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
No symbol table info available.
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)
(gdb) xbacktrace
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)
(gdb) thread 1
[Switching to thread 1 (Thread 11676.0x1edc)]
#0  SDATA (string=1461725984) at lisp.h:1325
1325	  return XSTRING (string)->data;
(gdb)  thread apply all bt

Thread 7 (Thread 11676.0x430):
#0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0xfb32daaf in ?? ()
#3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00000000 in ?? ()

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)

Thread 6 (Thread 11676.0x2aa0):
#0  0x771b868c in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x7718a246 in ntdll!EtwNotificationRegister ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#3  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x00c844c0 in ?? ()
#5  0x771a568e in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0xffffffff in ?? ()
#7  0x771cb6c3 in ntdll!RtlCaptureContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x00000000 in ?? ()

[New Thread 11676.0x1f00]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 11676.0x1f00]
0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) The program received a signal in another thread while
making a function call from GDB.
Evaluation of the expression containing the function
(backtrace_top) will be abandoned.
When the function is done executing, GDB will silently stop.

Thread 8 (Thread 11676.0x1f00):
#0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0xfb32daaf in ?? ()
#3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00000000 in ?? ()

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)

Thread 6 (Thread 11676.0x2aa0):
#0  backtrace_top () at eval.c:183
#1  <function called from gdb>
#2  0x771b868c in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#3  0x7718a246 in ntdll!EtwNotificationRegister ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00c844c0 in ?? ()
#7  0x771a568e in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0xffffffff in ?? ()
#9  0x771cb6c3 in ntdll!RtlCaptureContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x00000000 in ?? ()
[New Thread 11676.0x2e80]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 11676.0x2e80]
0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) The program received a signal in another thread while
making a function call from GDB.
Evaluation of the expression containing the function
(backtrace_top) will be abandoned.
When the function is done executing, GDB will silently stop.


Thread 9 (Thread 11676.0x2e80):
#0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0xfb32daaf in ?? ()
#3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00000000 in ?? ()

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)

Thread 6 (Thread 11676.0x2aa0):
#0  backtrace_top () at eval.c:183
#1  <function called from gdb>
#2  backtrace_top () at eval.c:183
#3  <function called from gdb>
#4  0x771b868c in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#5  0x7718a246 in ntdll!EtwNotificationRegister ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#7  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x00c844c0 in ?? ()
#9  0x771a568e in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0xffffffff in ?? ()
#11 0x771cb6c3 in ntdll!RtlCaptureContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#12 0x00000000 in ?? ()

[New Thread 11676.0x1f78]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 11676.0x1f78]
0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) The program received a signal in another thread while
making a function call from GDB.
Evaluation of the expression containing the function
(backtrace_top) will be abandoned.
When the function is done executing, GDB will silently stop.

Thread 10 (Thread 11676.0x1f78):
#0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0xfb32daaf in ?? ()
#3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00000000 in ?? ()

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)

Thread 6 (Thread 11676.0x2aa0):
#0  backtrace_top () at eval.c:183
#1  <function called from gdb>
#2  backtrace_top () at eval.c:183
#3  <function called from gdb>
#4  backtrace_top () at eval.c:183
#5  <function called from gdb>
#6  0x771b868c in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#7  0x7718a246 in ntdll!EtwNotificationRegister ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#8  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#9  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x00c844c0 in ?? ()
#11 0x771a568e in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#12 0xffffffff in ?? ()
#13 0x771cb6c3 in ntdll!RtlCaptureContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#14 0x00000000 in ?? ()


[New Thread 11676.0x2134]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 11676.0x2134]
0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
(gdb) The program received a signal in another thread while
making a function call from GDB.
Evaluation of the expression containing the function
(backtrace_top) will be abandoned.
When the function is done executing, GDB will silently stop.

Thread 11 (Thread 11676.0x2134):
#0  0x771b8c51 in ntdll!DbgBreakPoint () from C:\WINDOWS\SYSTEM32\ntdll.dll
#1  0x771e9e09 in ntdll!DbgUiRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#2  0xfb32daaf in ?? ()
#3  0x771e9dd0 in ntdll!DbgUiIssueRemoteBreakin ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#4  0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#5  0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#6  0x00000000 in ?? ()

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)

Thread 6 (Thread 11676.0x2aa0):
#0  backtrace_top () at eval.c:183
#1  <function called from gdb>
#2  backtrace_top () at eval.c:183
#3  <function called from gdb>
#4  backtrace_top () at eval.c:183
#5  <function called from gdb>
#6  backtrace_top () at eval.c:183
#7  <function called from gdb>
#8  0x771b868c in ntdll!ZwWaitForWorkViaWorkerFactory ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#9  0x7718a246 in ntdll!EtwNotificationRegister ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#10 0x760238f4 in KERNEL32!BaseThreadInitThunk ()
   from C:\WINDOWS\SYSTEM32\kernel32.dll
#11 0x771a56c3 in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#12 0x00c844c0 in ?? ()
#13 0x771a568e in ntdll!RtlUnicodeStringToInteger ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#14 0xffffffff in ?? ()
#15 0x771cb6c3 in ntdll!RtlCaptureContext ()
   from C:\WINDOWS\SYSTEM32\ntdll.dll
#16 0x00000000 in ?? ()

--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

VBR,
	Vincent

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Tue, 05 Jan 2016 18:00:31 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
> Cc: Vincent Belaïche <vincent.belaiche <at> gmail.com> ,
>  22301 <at> debbugs.gnu.org
> Date: Tue, 05 Jan 2016 08:17:17 +0100
> 
> Something I had forgotten to tell you: I think that I have compiled this
> Emacs with Mingw-w64 --- well I am not 100% sure now because at some
> point of time I had problems with Minfw-64 (see
> https://sourceforge.net/p/mingw-w64/bugs/519/) and I have re-installed
> the 32 bit version (both coexist now on my machine and I select the one
> in use by editing the fstab file).
> 
> Anyway, I still don't get the debugger prompt, neither Ctrl-C (well C-Q
> C-C because I am running it from Emacs), nor F-12 do anything. However,
> if I do:
> 
>   M-x signal-process RET
>   shell RET
>   3 RET
> 
> then something happens with the debugger, I did it several times, I
> still don't get the prompt, but there is that sort of output:
> 
>   Program received signal SIGTRAP, Trace/breakpoint trap
> 
> So below, I copied the full gdb session with these. Please make me know
> whether this session is ruined or not.

You can close this session.  It cannot help us more than it already
did.  I hope we will have more information next time this happens,
using the commands I've shown.

Thanks.

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>,
 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Thu, 14 Jan 2016 17:15:24 +0100

Dear Eli,

If not yet wished: HAPPY NEW YEAR 2016, BONNE ANNÉE 2016, С НОВЫМ ГОДОМ
2016 (etc...) !

I had put on hold this bug#22301 stuff, because I wanted to make some
update on LaTeX fmtcount package. Now, I have just come back at it, and
the crash was not long to come back. It seems that it is not so
difficult to reproduce. Below is our backtrace.

My gdb session is left open, so please feel free to ask more gdb
interaction. More below...


Le 05/01/2016 04:34, Eli Zaretskii a écrit :

[...]

>
> Do you get the GDB prompt back if you press F-12 or Ctrl-C?  If not,
> this session is ruined, and you can stop it.
>
> Next time when it happens, type these commands instead:
>
>   (gdb) thread 1
>   (gdb) bt
>
> Better yet, run Emacs from GDB to begin with, it will make the
> backtrace more reliable.
>
> Thanks.

Here is the full session. At the beginning of the session there are lots
of [New thead...], that is because I did not start SES debugging at
once. I have used the Emacs under debug a number of days without any
problem, including for Lisp debugging other lisp code than SES. But
almost as soon as I came back to SES relocation functions, it crashed...

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
$ gdb /c/Nos_Programmes/GNU/Emacs/bin/emacs.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\Nos_Programmes\GNU\Emacs\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]
DISPLAY = w32
TERM = emacs
Breakpoint 1 at 0x10951bb: file emacs.c, line 370.
Temporary breakpoint 2 at 0x10aabd6: file sysdep.c, line 901.
(gdb) run
Starting program: c:/Nos_Programmes/GNU/Emacs/bin/emacs.exe 
[New Thread 2820.0x9b0]
[New Thread 2820.0x1458]
[New Thread 2820.0x1618]
[New Thread 2820.0xd5c]
[New Thread 2820.0x6f4]
[New Thread 2820.0xf84]
[New Thread 2820.0xfc8]
[New Thread 2820.0x14ec]
[New Thread 2820.0x1520]
[New Thread 2820.0x1a38]
[New Thread 2820.0x1a74]
[New Thread 2820.0x1aac]
[New Thread 2820.0x1ae4]
[New Thread 2820.0x1b20]
[New Thread 2820.0x1b54]
[New Thread 2820.0x1b88]
[New Thread 2820.0x1bbc]
[New Thread 2820.0x1bf0]
[New Thread 2820.0x114c]
[New Thread 2820.0x153c]
[New Thread 2820.0x1880]
[New Thread 2820.0xe88]
[New Thread 2820.0x1558]
[New Thread 2820.0x168c]
[New Thread 2820.0x1964]
[New Thread 2820.0x1a54]
[New Thread 2820.0x1a90]
[New Thread 2820.0x1ab8]
[New Thread 2820.0x1b00]
[New Thread 2820.0x1b64]
[New Thread 2820.0x1bb8]
[New Thread 2820.0x1be8]
[New Thread 2820.0x1e8]
[New Thread 2820.0x1848]
[New Thread 2820.0xbd8]
[New Thread 2820.0x1814]
[New Thread 2820.0x121c]
[New Thread 2820.0x1ae8]
[New Thread 2820.0x1bbc]
[New Thread 2820.0x1bf4]
[New Thread 2820.0x1864]
[New Thread 2820.0x554]
[New Thread 2820.0x1818]
[New Thread 2820.0x1248]
[New Thread 2820.0x1934]
[New Thread 2820.0x1318]
[New Thread 2820.0x1684]
[New Thread 2820.0xe9c]
[New Thread 2820.0x18cc]
[New Thread 2820.0x1a28]
[New Thread 2820.0x1a54]
[New Thread 2820.0x96c]
[New Thread 2820.0x1874]
[New Thread 2820.0x1aa0]
[New Thread 2820.0x1b1c]
[New Thread 2820.0x6ac]
[New Thread 2820.0x624]
[New Thread 2820.0x1b74]
[New Thread 2820.0x20c]
[New Thread 2820.0x1bb8]
[New Thread 2820.0x1b00]
[New Thread 2820.0x1864]
[New Thread 2820.0x554]
[New Thread 2820.0x1840]
[New Thread 2820.0x1248]
[New Thread 2820.0x1a20]
[New Thread 2820.0x19f0]
[New Thread 2820.0x1610]
[New Thread 2820.0x18b8]
[New Thread 2820.0x1b30]
[New Thread 2820.0x119c]
[New Thread 2820.0x1a4c]
[New Thread 2820.0x1be8]
[New Thread 2820.0x1a70]
[New Thread 2820.0x7ec]
[New Thread 2820.0x19c8]
[New Thread 2820.0x1abc]
[New Thread 2820.0x1ab8]
[New Thread 2820.0x1558]
[New Thread 2820.0x1b78]
[New Thread 2820.0x1b5c]
[New Thread 2820.0x1808]
[New Thread 2820.0xd40]
[New Thread 2820.0x12f0]
[New Thread 2820.0xa74]
[New Thread 2820.0x554]
[New Thread 2820.0x71c]
[New Thread 2820.0x1284]
[New Thread 2820.0x8f8]
[New Thread 2820.0xe58]
[New Thread 2820.0xf50]
[New Thread 2820.0xb08]
[New Thread 2820.0x3a0]
[New Thread 2820.0xa44]
[New Thread 2820.0x122c]
[New Thread 2820.0x1588]
[New Thread 2820.0x139c]
[New Thread 2820.0x140c]
[New Thread 2820.0x1a54]
[New Thread 2820.0x11dc]
[New Thread 2820.0x140c]
[New Thread 2820.0x1b68]
[New Thread 2820.0x9a8]
[New Thread 2820.0x43c]
[New Thread 2820.0x156c]
[New Thread 2820.0x140]
[New Thread 2820.0x19ec]
[New Thread 2820.0xb10]
[New Thread 2820.0x1388]
[New Thread 2820.0xe44]
[New Thread 2820.0x1318]
[New Thread 2820.0xfd0]
[New Thread 2820.0x17c4]
[New Thread 2820.0x15d0]
[New Thread 2820.0x1ec]
[New Thread 2820.0x414]
[New Thread 2820.0x1984]
[New Thread 2820.0xc7c]
[New Thread 2820.0x11e4]
[New Thread 2820.0x1bb8]
[New Thread 2820.0x5c8]
[New Thread 2820.0x1928]
[New Thread 2820.0xfbc]
[New Thread 2820.0xac]
[New Thread 2820.0x18b4]
[New Thread 2820.0xc8]
[New Thread 2820.0xf40]
[New Thread 2820.0x1560]
[New Thread 2820.0x1f8]
[New Thread 2820.0x4f8]
[New Thread 2820.0x1388]
[New Thread 2820.0x1520]
[New Thread 2820.0x1578]
[New Thread 2820.0x5b4]
[New Thread 2820.0x188c]
[New Thread 2820.0xf78]
[New Thread 2820.0xd4]
[New Thread 2820.0xaf8]
[New Thread 2820.0x1960]
[New Thread 2820.0x1824]
[New Thread 2820.0x830]
[New Thread 2820.0x43c]
[New Thread 2820.0xfa0]
[New Thread 2820.0x182c]
[New Thread 2820.0x1b34]
[New Thread 2820.0x178c]
[New Thread 2820.0x2f8]
[New Thread 2820.0x1208]
[New Thread 2820.0x1294]
[New Thread 2820.0x5d8]
[New Thread 2820.0xd7c]
[New Thread 2820.0x13c0]
[New Thread 2820.0x144c]
[New Thread 2820.0x1a4c]
[New Thread 2820.0x18fc]
[New Thread 2820.0xa78]
[New Thread 2820.0x4c4]
[New Thread 2820.0x13b8]
[New Thread 2820.0xe28]
[New Thread 2820.0x15a8]
[New Thread 2820.0x204]
[New Thread 2820.0x7ac]
[New Thread 2820.0x8e4]
[New Thread 2820.0xce0]
[New Thread 2820.0x9a8]
[New Thread 2820.0x18d0]
[New Thread 2820.0x1300]
[New Thread 2820.0x1a3c]
[New Thread 2820.0x114]
[New Thread 2820.0xe08]
[New Thread 2820.0x1370]
[New Thread 2820.0x1ac8]
[New Thread 2820.0x75c]
[New Thread 2820.0xd30]
[New Thread 2820.0x1490]
[New Thread 2820.0xde8]
[New Thread 2820.0x17dc]
[New Thread 2820.0x1f8]
[New Thread 2820.0x4f8]
[New Thread 2820.0x1388]
[New Thread 2820.0x888]
[New Thread 2820.0x19f8]
[New Thread 2820.0x185c]
[New Thread 2820.0xe28]
[New Thread 2820.0x188c]
[New Thread 2820.0x104c]
[New Thread 2820.0x1778]
[New Thread 2820.0x1b68]
[New Thread 2820.0x15cc]
[New Thread 2820.0x189c]
[New Thread 2820.0x15c0]
[New Thread 2820.0x1404]
[New Thread 2820.0xb94]
[New Thread 2820.0x1370]
[New Thread 2820.0xac]
[New Thread 2820.0x184c]
[New Thread 2820.0xa38]
[New Thread 2820.0x1bc4]
[New Thread 2820.0x1084]
[New Thread 2820.0x119c]
[New Thread 2820.0x1674]
[New Thread 2820.0x1388]
[New Thread 2820.0x888]
[New Thread 2820.0x16c]
[New Thread 2820.0x1590]
[New Thread 2820.0x1ec]
[New Thread 2820.0xf78]
[New Thread 2820.0x1860]
[New Thread 2820.0x15cc]
[New Thread 2820.0x870]
[New Thread 2820.0x1a94]
[New Thread 2820.0x628]
[New Thread 2820.0x158c]
[New Thread 2820.0x19ec]
[New Thread 2820.0x18ac]
[New Thread 2820.0x111c]
[New Thread 2820.0xf3c]
[New Thread 2820.0x1be4]
[New Thread 2820.0xde8]
[New Thread 2820.0x18f8]
[New Thread 2820.0x1f8]
[New Thread 2820.0x19e0]
[New Thread 2820.0x688]
[New Thread 2820.0xca0]
[New Thread 2820.0x1578]
[New Thread 2820.0xdec]
[New Thread 2820.0x14c0]
[New Thread 2820.0xcd0]
[New Thread 2820.0xe80]
[New Thread 2820.0x540]
[New Thread 2820.0x8e4]
[New Thread 2820.0xd4]
[New Thread 2820.0x1a14]
[New Thread 2820.0xb94]
[New Thread 2820.0x1b6c]
[New Thread 2820.0x1b74]
[New Thread 2820.0x910]
[New Thread 2820.0x9c]
[New Thread 2820.0x908]
[New Thread 2820.0x1a2c]
[New Thread 2820.0x1374]
[New Thread 2820.0x45c]
[New Thread 2820.0x15f0]
[New Thread 2820.0x1388]
[New Thread 2820.0xcdc]
[New Thread 2820.0x728]
[New Thread 2820.0x18d4]
[New Thread 2820.0xe6c]
[New Thread 2820.0x35c]
[New Thread 2820.0x133c]
[New Thread 2820.0x1018]
[New Thread 2820.0x126c]
[New Thread 2820.0xc14]
[New Thread 2820.0x1960]
[New Thread 2820.0x830]
[New Thread 2820.0x19ac]
[New Thread 2820.0x15c0]
[New Thread 2820.0x1b34]
[New Thread 2820.0x15d4]
[New Thread 2820.0x1370]
[New Thread 2820.0x4b8]
[New Thread 2820.0x139c]
[New Thread 2820.0x15ac]
[New Thread 2820.0x12c8]
[New Thread 2820.0x1a0c]
[New Thread 2820.0xa18]
[New Thread 2820.0x1078]
[New Thread 2820.0x864]
[New Thread 2820.0x1248]
[New Thread 2820.0x1424]
[New Thread 2820.0x1b5c]
[New Thread 2820.0x13b8]
[New Thread 2820.0x1a7c]
[New Thread 2820.0x1bfc]
[New Thread 2820.0x318]
[New Thread 2820.0x1860]
[New Thread 2820.0x1668]
[New Thread 2820.0xe78]
[New Thread 2820.0x248]
[New Thread 2820.0x1004]
[New Thread 2820.0x18e0]
[New Thread 2820.0x1af0]
[New Thread 2820.0x11a4]
[New Thread 2820.0xff8]
[New Thread 2820.0x19dc]
[New Thread 2820.0x18dc]
[New Thread 2820.0x1f8]
[New Thread 2820.0xc80]
[New Thread 2820.0x19d4]
[New Thread 2820.0xe40]
[New Thread 2820.0x16dc]
[New Thread 2820.0x1228]
[New Thread 2820.0x5c0]
[New Thread 2820.0xfac]
[New Thread 2820.0xac0]
[New Thread 2820.0x15bc]
[New Thread 2820.0x179c]
[New Thread 2820.0xe80]
[New Thread 2820.0x1250]
[New Thread 2820.0x15d0]
[New Thread 2820.0xc14]
[New Thread 2820.0x1bd8]
[New Thread 2820.0x1b04]
[New Thread 2820.0x6bc]
[New Thread 2820.0xa18]
[New Thread 2820.0x16dc]
[New Thread 2820.0x1974]
[New Thread 2820.0x1424]
[New Thread 2820.0x1a14]
[New Thread 2820.0x1818]
[New Thread 2820.0x43c]
[New Thread 2820.0x185c]
[New Thread 2820.0x1bfc]
[New Thread 2820.0x1250]
[New Thread 2820.0xe28]
[New Thread 2820.0x830]
[New Thread 2820.0x19c8]
[New Thread 2820.0x728]
[New Thread 2820.0xcec]
[New Thread 2820.0xde0]
[New Thread 2820.0x1578]
[New Thread 2820.0x1740]
[New Thread 2820.0x14bc]
[New Thread 2820.0xf78]
[New Thread 2820.0x540]
[New Thread 2820.0x1acc]
[New Thread 2820.0x176c]
[New Thread 2820.0x170]
[New Thread 2820.0x1bb4]
[New Thread 2820.0x1068]
[New Thread 2820.0x181c]
[New Thread 2820.0x19dc]
[New Thread 2820.0x1774]
[New Thread 2820.0x12cc]
[New Thread 2820.0x1208]
[New Thread 2820.0x107c]
[New Thread 2820.0x1318]
[New Thread 2820.0x1648]
[New Thread 2820.0xd54]
[New Thread 2820.0x18c]
[New Thread 2820.0x156c]
[New Thread 2820.0xbc4]
[New Thread 2820.0x116c]
[New Thread 2820.0x140]
[New Thread 2820.0x14a4]
[New Thread 2820.0x1644]
[New Thread 2820.0x1a84]
[New Thread 2820.0x1018]
[New Thread 2820.0x1204]
[New Thread 2820.0x7a8]
[New Thread 2820.0x840]
[New Thread 2820.0x176c]
[New Thread 2820.0x16a8]
[New Thread 2820.0x1768]
[New Thread 2820.0x15f4]
[New Thread 2820.0x199c]
[New Thread 2820.0xd7c]
[New Thread 2820.0xa34]
[New Thread 2820.0xc8]
[New Thread 2820.0xc0c]
[New Thread 2820.0x18e0]
[New Thread 2820.0x1688]
[New Thread 2820.0x1694]
[New Thread 2820.0x1014]
[New Thread 2820.0x1bc8]
[New Thread 2820.0x145c]
[New Thread 2820.0xf98]
[New Thread 2820.0xe44]
[New Thread 2820.0x804]
[New Thread 2820.0x1368]
[New Thread 2820.0x133c]
[New Thread 2820.0xac0]
[New Thread 2820.0x608]
[New Thread 2820.0x1ad4]
[New Thread 2820.0xb74]
[New Thread 2820.0xba0]
[New Thread 2820.0x17dc]
[New Thread 2820.0x19e0]
[New Thread 2820.0x75c]
[New Thread 2820.0x1560]
[New Thread 2820.0xb88]
[New Thread 2820.0x1128]
[New Thread 2820.0x1588]
[New Thread 2820.0x17cc]
[New Thread 2820.0xaf8]
[New Thread 2820.0x1668]
[New Thread 2820.0x11e4]
[New Thread 2820.0x16f0]
[New Thread 2820.0x16a8]
[New Thread 2820.0x1078]
[New Thread 2820.0x1768]
[New Thread 2820.0x1af8]
[New Thread 2820.0xffc]
[New Thread 2820.0x16b0]
[New Thread 2820.0x1188]
[New Thread 2820.0x82c]
[New Thread 2820.0x13e4]
[New Thread 2820.0x17c8]
[New Thread 2820.0x1318]
[New Thread 2820.0x1858]
[New Thread 2820.0x1014]
[New Thread 2820.0x1974]
[New Thread 2820.0xb10]
[New Thread 2820.0x684]
[New Thread 2820.0x11d8]
[New Thread 2820.0x12cc]
[New Thread 2820.0x1afc]
[New Thread 2820.0xb4c]
[New Thread 2820.0x1b50]
[New Thread 2820.0x13c0]
[New Thread 2820.0x1b7c]
[New Thread 2820.0x1190]
[New Thread 2820.0x684]
[New Thread 2820.0x1984]
[New Thread 2820.0x1578]
[New Thread 2820.0x864]
[New Thread 2820.0x9a8]
[New Thread 2820.0x440]
[New Thread 2820.0x8e0]
[New Thread 2820.0x158c]
[New Thread 2820.0x178c]
[New Thread 2820.0x13dc]
[New Thread 2820.0x17dc]
[New Thread 2820.0xfcc]
[New Thread 2820.0xf40]
[New Thread 2820.0x1974]
[New Thread 2820.0xe98]
[New Thread 2820.0xc18]
[New Thread 2820.0x19d0]
[New Thread 2820.0x1a2c]
[New Thread 2820.0x17e0]
[New Thread 2820.0xfcc]
[New Thread 2820.0xf38]
[New Thread 2820.0x1be8]
[New Thread 2820.0xee0]
[New Thread 2820.0x918]
[New Thread 2820.0x144c]
[New Thread 2820.0x1bb8]
[New Thread 2820.0x1208]
[New Thread 2820.0x16fc]
[New Thread 2820.0xca0]
[New Thread 2820.0x1670]
[New Thread 2820.0x6f8]
[New Thread 2820.0xa74]
[New Thread 2820.0x1994]
[New Thread 2820.0x13d4]
[New Thread 2820.0x1ba8]
[New Thread 2820.0x5a8]
[New Thread 2820.0x94c]
[New Thread 2820.0x12ac]
[New Thread 2820.0x13dc]
[New Thread 2820.0xa8c]
[New Thread 2820.0x148]
[New Thread 2820.0xb74]
[New Thread 2820.0x1a98]
[New Thread 2820.0xea0]
[New Thread 2820.0xce4]
[New Thread 2820.0x1ae8]
[New Thread 2820.0xb94]
[New Thread 2820.0x1bc8]
[New Thread 2820.0x17c4]
[New Thread 2820.0x14c0]
[New Thread 2820.0x19f0]
[New Thread 2820.0x35c]
[New Thread 2820.0x6f8]
[New Thread 2820.0x1740]
[New Thread 2820.0x1018]
[New Thread 2820.0x1824]
[New Thread 2820.0x11a4]
[New Thread 2820.0x1a98]
[New Thread 2820.0x1898]
[New Thread 2820.0x1928]
[New Thread 2820.0x1270]
[New Thread 2820.0x7ac]
[New Thread 2820.0x1854]
[New Thread 2820.0x888]
[New Thread 2820.0x1abc]
[New Thread 2820.0x838]
[New Thread 2820.0x1bf8]
[New Thread 2820.0x1b04]
[New Thread 2820.0xc54]
[New Thread 2820.0x1260]
[New Thread 2820.0x1ba4]
[New Thread 2820.0x1710]
[New Thread 2820.0x1844]
[New Thread 2820.0x1188]
[New Thread 2820.0x1b50]
[New Thread 2820.0x1864]
[New Thread 2820.0x11f8]
[New Thread 2820.0x6c8]
[New Thread 2820.0x1a54]
[New Thread 2820.0xb74]
[New Thread 2820.0x12c0]
[New Thread 2820.0x8f8]
[New Thread 2820.0x121c]
[New Thread 2820.0x1bfc]
[New Thread 2820.0xc80]
[New Thread 2820.0x1324]
[New Thread 2820.0x1a14]
[New Thread 2820.0x854]
[New Thread 2820.0x1ac8]
[New Thread 2820.0x1148]
[New Thread 2820.0x1ba0]
[New Thread 2820.0x1ad0]
[New Thread 2820.0x5a8]
[New Thread 2820.0x864]
[New Thread 2820.0xedc]
[New Thread 2820.0x1248]
[New Thread 2820.0xda0]
[New Thread 2820.0x1644]
[New Thread 2820.0x14c0]
[New Thread 2820.0x1ad4]
[New Thread 2820.0x1068]
[New Thread 2820.0x18a4]
[New Thread 2820.0x35c]
[New Thread 2820.0xd7c]
[New Thread 2820.0x1608]
[New Thread 2820.0x198]
[New Thread 2820.0x1548]
[New Thread 2820.0xcfc]
[New Thread 2820.0x1bfc]
[New Thread 2820.0x1774]
[New Thread 2820.0x18b4]
[New Thread 2820.0x1b08]
[New Thread 2820.0x768]
[New Thread 2820.0x14d4]
[New Thread 2820.0x72c]
[New Thread 2820.0xdb0]
[New Thread 2820.0x1ad0]
[New Thread 2820.0x5a8]
[New Thread 2820.0x19e0]
[New Thread 2820.0x1b7c]
[New Thread 2820.0x1858]
[New Thread 2820.0x7d4]
[New Thread 2820.0x16f0]
[New Thread 2820.0xe7c]
[New Thread 2820.0x1a0c]
[New Thread 2820.0x138c]
[New Thread 2820.0x1b78]
[New Thread 2820.0x153c]
[New Thread 2820.0x13b0]
[New Thread 2820.0x161c]
[New Thread 2820.0x76c]
[New Thread 2820.0x10f8]
[New Thread 2820.0x1bf4]
[New Thread 2820.0x1a2c]
[New Thread 2820.0x1064]
[New Thread 2820.0x1660]
[New Thread 2820.0x178c]
[New Thread 2820.0x1300]
[New Thread 2820.0xcdc]
[New Thread 2820.0x18e0]
[New Thread 2820.0xe2c]
[New Thread 2820.0x1780]
[New Thread 2820.0x13b8]
[New Thread 2820.0x1ad0]
[New Thread 2820.0x2dc]
[New Thread 2820.0xf3c]
[New Thread 2820.0x1abc]
[New Thread 2820.0x888]
[New Thread 2820.0x1ae8]
[New Thread 2820.0x32c]
[New Thread 2820.0x1134]
[New Thread 2820.0x1b04]
[New Thread 2820.0x18f8]
[New Thread 2820.0x188c]
[New Thread 2820.0x9a8]
[New Thread 2820.0x1594]
[New Thread 2820.0x111c]
[New Thread 2820.0xe78]
[New Thread 2820.0x12c8]
[New Thread 2820.0x1a54]
[New Thread 2820.0x122c]
[New Thread 2820.0x1490]
[New Thread 2820.0xf44]
[New Thread 2820.0x1530]
[New Thread 2820.0x17a8]
[New Thread 2820.0x1b88]
[New Thread 2820.0x4f8]
[New Thread 2820.0x4d8]
[New Thread 2820.0x1550]
[New Thread 2820.0x14d4]
[New Thread 2820.0x1754]
[New Thread 2820.0x14a0]
[New Thread 2820.0xb78]
[New Thread 2820.0xfec]
[New Thread 2820.0x1208]
[New Thread 2820.0x578]
[New Thread 2820.0x1204]
[New Thread 2820.0xda4]
[New Thread 2820.0x17c8]
[New Thread 2820.0x1134]
[New Thread 2820.0x1870]
[New Thread 2820.0x1260]
[New Thread 2820.0x344]
[New Thread 2820.0x1068]
[New Thread 2820.0x678]
[New Thread 2820.0x1a88]
[New Thread 2820.0x1588]
[New Thread 2820.0x12cc]
[New Thread 2820.0xf44]
[New Thread 2820.0x644]
[New Thread 2820.0x1708]
[New Thread 2820.0x148c]
[New Thread 2820.0xa18]
[New Thread 2820.0x1314]
[New Thread 2820.0x1644]
[New Thread 2820.0x54c]
[New Thread 2820.0x15ac]
[New Thread 2820.0x18b4]
[New Thread 2820.0x1d64]
[New Thread 2820.0x4c0]
[New Thread 2820.0x7ac]
[New Thread 2820.0xbdc]
[New Thread 2820.0x1368]
[New Thread 2820.0x1c38]
[New Thread 2820.0x94c]
[New Thread 2820.0x1018]
[New Thread 2820.0x63c]
[New Thread 2820.0x1d48]
[New Thread 2820.0x15d4]
[New Thread 2820.0x1f28]
[New Thread 2820.0xc98]
[New Thread 2820.0x1a54]
[New Thread 2820.0x1c30]
[New Thread 2820.0x5a0]
[New Thread 2820.0x5c0]
[New Thread 2820.0x1e38]
[New Thread 2820.0x18f8]
[New Thread 2820.0x1744]
[New Thread 2820.0x19e0]
[New Thread 2820.0x96c]
[New Thread 2820.0x1530]
[New Thread 2820.0x75c]
[New Thread 2820.0x19ac]
[New Thread 2820.0x1cac]
[New Thread 2820.0x15a8]
[New Thread 2820.0x1fd4]
[New Thread 2820.0x15f8]
[New Thread 2820.0xc8]
[New Thread 2820.0x138c]
[New Thread 2820.0x940]
[New Thread 2820.0x1d98]
[New Thread 2820.0x12c8]
[New Thread 2820.0x1d90]
[New Thread 2820.0xfbc]
[New Thread 2820.0x1a68]
[New Thread 2820.0x1928]
[New Thread 2820.0x1fcc]
[New Thread 2820.0x11e8]
[New Thread 2820.0x1e2c]
[New Thread 2820.0x1fb4]
[New Thread 2820.0x1d00]
[New Thread 2820.0x7d4]
[New Thread 2820.0xbc4]
[New Thread 2820.0xc54]
[New Thread 2820.0x1a8c]
[New Thread 2820.0x43c]
[New Thread 2820.0xfbc]
[New Thread 2820.0x18c]
[New Thread 2820.0x78c]
[New Thread 2820.0x1814]
[New Thread 2820.0x8e0]
[New Thread 2820.0x1338]
[New Thread 2820.0x1a50]
[New Thread 2820.0xb94]
[New Thread 2820.0x1bbc]
[New Thread 2820.0x11d8]
[New Thread 2820.0x1be0]
[New Thread 2820.0x1110]
[New Thread 2820.0x2c4]
[New Thread 2820.0x1d3c]
[New Thread 2820.0x1a3c]
[New Thread 2820.0xfbc]
[New Thread 2820.0x788]
[New Thread 2820.0x1c70]
[New Thread 2820.0x4e0]
[New Thread 2820.0x2188]
[New Thread 2820.0x218c]
[New Thread 2820.0x2190]
[New Thread 2820.0x2274]
[New Thread 2820.0x18fc]
[New Thread 2820.0x1f98]
[New Thread 2820.0x3ec]
[New Thread 2820.0x1554]
[New Thread 2820.0x1e08]
[New Thread 2820.0x20d8]
[New Thread 2820.0x1128]
[New Thread 2820.0x1b18]
[New Thread 2820.0x71c]
[New Thread 2820.0x121c]
[New Thread 2820.0xe58]
[New Thread 2820.0x2228]
[New Thread 2820.0x2260]
[New Thread 2820.0x19f0]
[New Thread 2820.0x22f4]
[New Thread 2820.0x23e4]
[New Thread 2820.0xc54]
[New Thread 2820.0x1cb0]
[New Thread 2820.0x214c]
[New Thread 2820.0x2094]
[New Thread 2820.0x1f50]
[New Thread 2820.0x1ba4]
[New Thread 2820.0xd34]
[New Thread 2820.0x13e8]
[New Thread 2820.0x1f5c]
[New Thread 2820.0xe54]
[New Thread 2820.0x1f18]
[New Thread 2820.0x221c]
[New Thread 2820.0x218c]
[New Thread 2820.0x225c]
[New Thread 2820.0x19f0]
[New Thread 2820.0x2288]
[New Thread 2820.0x23dc]
[New Thread 2820.0x22c8]
[New Thread 2820.0x1064]
[New Thread 2820.0xd0]
[New Thread 2820.0x374]
[New Thread 2820.0x1654]
[New Thread 2820.0x1890]
[New Thread 2820.0x2138]
[New Thread 2820.0x574]
[New Thread 2820.0x1e40]
[New Thread 2820.0x18f8]
[New Thread 2820.0x1770]
[New Thread 2820.0xce4]
[New Thread 2820.0x344]
[New Thread 2820.0x1f18]
[New Thread 2820.0x21b8]
[New Thread 2820.0xaf8]
[New Thread 2820.0x2190]
[New Thread 2820.0x1e60]
[New Thread 2820.0xf94]
[New Thread 2820.0x1f40]
[New Thread 2820.0xe78]
[New Thread 2820.0x1aa0]
[New Thread 2820.0x1814]
[New Thread 2820.0x1404]
[New Thread 2820.0x15ac]
[New Thread 2820.0x4d0]
[New Thread 2820.0x2020]
[New Thread 2820.0x2044]
[New Thread 2820.0xce0]
[New Thread 2820.0x1f90]
[New Thread 2820.0x708]
[New Thread 2820.0xba0]
[New Thread 2820.0x2318]
[New Thread 2820.0x72c]
[New Thread 2820.0x454]
[New Thread 2820.0x18c8]
[New Thread 2820.0x16a4]
[New Thread 2820.0x1214]
[New Thread 2820.0x1e2c]
[New Thread 2820.0x1c30]
[New Thread 2820.0x209c]
[New Thread 2820.0x874]
[New Thread 2820.0x1818]
[New Thread 2820.0x600]
[New Thread 2820.0x1cc4]
[New Thread 2820.0x1bc8]
[New Thread 2820.0x1130]
[New Thread 2820.0x12c8]
[New Thread 2820.0x1e14]
[New Thread 2820.0xc54]
[New Thread 2820.0xcec]
[New Thread 2820.0x2140]
[New Thread 2820.0x134c]
[New Thread 2820.0xecc]
[New Thread 2820.0x43c]
[New Thread 2820.0x8f0]
[New Thread 2820.0x1264]
[New Thread 2820.0x830]
[New Thread 2820.0xe60]
[New Thread 2820.0x1328]
[New Thread 2820.0x6b8]
[New Thread 2820.0x1a14]
[New Thread 2820.0x2140]
[New Thread 2820.0x2c4]
[New Thread 2820.0x208c]
[New Thread 2820.0x1fa8]
[New Thread 2820.0x1fac]
[New Thread 2820.0x20e4]
[New Thread 2820.0x98c]
[New Thread 2820.0xe7c]
[New Thread 2820.0x12cc]
[New Thread 2820.0x1320]
[New Thread 2820.0x2234]
[New Thread 2820.0x7f0]
[New Thread 2820.0x1ae4]
[New Thread 2820.0x1a98]
[New Thread 2820.0x354]
[New Thread 2820.0x23a4]
[New Thread 2820.0x23ac]
[New Thread 2820.0x1ac0]
[New Thread 2820.0x614]
[New Thread 2820.0x1f4c]
[New Thread 2820.0xa74]
[New Thread 2820.0x19c8]
[New Thread 2820.0x1890]
[New Thread 2820.0x2188]
[New Thread 2820.0xb94]
[New Thread 2820.0x1ce0]
[New Thread 2820.0x1084]
[New Thread 2820.0x2018]
[New Thread 2820.0xdb0]
[New Thread 2820.0x21b4]
[New Thread 2820.0x1130]
[New Thread 2820.0x15ac]
[New Thread 2820.0x14c]
[New Thread 2820.0x8ec]
[New Thread 2820.0x1e60]
[New Thread 2820.0x1bcc]
[New Thread 2820.0x2164]
[New Thread 2820.0x14c8]
[New Thread 2820.0x4d0]
[New Thread 2820.0xfbc]
[New Thread 2820.0x1df4]
[New Thread 2820.0x21d0]
[New Thread 2820.0xe14]
[New Thread 2820.0x20e8]
[New Thread 2820.0xad8]
[New Thread 2820.0x1ca8]
[New Thread 2820.0x2308]
[New Thread 2820.0x1cf0]
[New Thread 2820.0x1078]
[New Thread 2820.0x600]
[New Thread 2820.0x98c]
[New Thread 2820.0xfcc]
[New Thread 2820.0x1aac]
[New Thread 2820.0x219c]
[New Thread 2820.0xf38]
[New Thread 2820.0xb18]
[New Thread 2820.0x8e8]
[New Thread 2820.0x12ac]
[New Thread 2820.0x11dc]
[New Thread 2820.0xba0]
[New Thread 2820.0x1f98]
[New Thread 2820.0x1ef8]
[New Thread 2820.0x94c]
[New Thread 2820.0x1fa0]
[New Thread 2820.0x2268]
[New Thread 2820.0xa8c]
[New Thread 2820.0x1dc0]
[New Thread 2820.0x1d4c]
[New Thread 2820.0x1a04]
[New Thread 2820.0xb78]
[New Thread 2820.0x1d98]
[New Thread 2820.0x1b98]
[New Thread 2820.0x214c]
[New Thread 2820.0x2200]
[New Thread 2820.0x19ec]
[New Thread 2820.0x1db4]
[New Thread 2820.0x1928]
[New Thread 2820.0x1818]
[New Thread 2820.0x1268]
[New Thread 2820.0x1e00]
[New Thread 2820.0x1d2c]
[New Thread 2820.0x15ac]
[New Thread 2820.0x910]
[New Thread 2820.0x12f0]
[New Thread 2820.0x119c]
[New Thread 2820.0x1abc]
[New Thread 2820.0x1670]
[New Thread 2820.0xe28]
[New Thread 2820.0xe2c]
[New Thread 2820.0x1c70]
[New Thread 2820.0x148]
[New Thread 2820.0xec8]
[New Thread 2820.0xf3c]
[New Thread 2820.0x1ef4]
[New Thread 2820.0x17a8]
[New Thread 2820.0x23d4]
[New Thread 2820.0x19e0]
[New Thread 2820.0x1888]
[New Thread 2820.0x1268]
[New Thread 2820.0x1f10]
[New Thread 2820.0x104c]
[New Thread 2820.0xe5c]
[New Thread 2820.0x1288]
[New Thread 2820.0x1f28]
[New Thread 2820.0x8f0]
[New Thread 2820.0x2218]
[New Thread 2820.0x234c]
[New Thread 2820.0x18f8]
[New Thread 2820.0x71c]
[New Thread 2820.0x22e0]
[New Thread 2820.0x2134]
[New Thread 2820.0xad8]
[New Thread 2820.0x17d0]
[New Thread 2820.0x1708]
[New Thread 2820.0x14bc]
[New Thread 2820.0xf44]
[New Thread 2820.0xee4]
[New Thread 2820.0x1f2c]
[New Thread 2820.0x4dc]
[New Thread 2820.0x18e0]
[New Thread 2820.0x1b10]
[New Thread 2820.0x1484]
[New Thread 2820.0xc98]
[New Thread 2820.0x20d4]
[New Thread 2820.0xb88]
[New Thread 2820.0x13b0]
[New Thread 2820.0x142c]
[New Thread 2820.0x13e0]
[New Thread 2820.0x414]
[New Thread 2820.0xfac]
[New Thread 2820.0x10f8]
[New Thread 2820.0x910]
[New Thread 2820.0x1878]
[New Thread 2820.0x21e4]
[New Thread 2820.0x2384]
[New Thread 2820.0x2188]
[New Thread 2820.0x764]
[New Thread 2820.0x1a80]
[New Thread 2820.0x1b6c]
[New Thread 2820.0x1738]
[New Thread 2820.0xf94]
[New Thread 2820.0xc74]
[New Thread 2820.0x1a48]
[New Thread 2820.0x1d98]
[New Thread 2820.0xe20]
[New Thread 2820.0x3a0]
[New Thread 2820.0xfac]

Program received signal SIGSEGV, Segmentation fault.
0x011119c6 in print_object (obj=obj <at> entry=12579352, 
    printcharfun=printcharfun <at> entry=0, escapeflag=escapeflag <at> entry=true)
    at print.c:1505
1505		if (p != end && (*p == '-' || *p == '+')) p++;
(gdb) thread 1
[Switching to thread 1 (Thread 2820.0x9b0)]
#0  0x011119c6 in print_object (obj=obj <at> entry=12579352, 
    printcharfun=printcharfun <at> entry=0, escapeflag=escapeflag <at> entry=true)
    at print.c:1505
1505		if (p != end && (*p == '-' || *p == '+')) p++;
(gdb) bt
#0  0x011119c6 in print_object (obj=obj <at> entry=12579352, 
    printcharfun=printcharfun <at> entry=0, escapeflag=escapeflag <at> entry=true)
    at print.c:1505
#1  0x01112d0b in print (obj=obj <at> entry=12579352, 
    printcharfun=printcharfun <at> entry=0, escapeflag=escapeflag <at> entry=true)
    at print.c:1129
#2  0x01112f89 in Fprin1 (object=12579352, printcharfun=printcharfun <at> entry=0)
    at print.c:623
#3  0x010f89ac in Fbacktrace () at eval.c:3247
#4  0x010fa7da in Ffuncall (nargs=1, args=0xbfeda8) at eval.c:2647
#5  0x0112a00d in exec_byte_code (bytestr=-1946399349, vector=264275401, 
    maxdepth=26, args_template=args_template <at> entry=1030, nargs=nargs <at> entry=1, 
    args=0x1) at bytecode.c:880
#6  0x010fa348 in funcall_lambda (fun=81103373, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0xbfefe0) at eval.c:2810
#7  0x010fa59f in Ffuncall (nargs=2, args=0xbfefdc) at eval.c:2711
#8  0x0112a00d in exec_byte_code (bytestr=-1946399349, vector=264275401, 
    maxdepth=166, args_template=args_template <at> entry=514, nargs=nargs <at> entry=2, 
    args=0x2) at bytecode.c:880
#9  0x010fa348 in funcall_lambda (fun=81425253, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> entry=0xbff1b4) at eval.c:2810
#10 0x010fa59f in Ffuncall (nargs=nargs <at> entry=3, args=args <at> entry=0xbff1b0)
    at eval.c:2711
#11 0x010fb8e3 in Fapply (nargs=nargs <at> entry=2, args=args <at> entry=0xbff218)
    at eval.c:2278
#12 0x010fb9d6 in apply1 (fn=10304, arg=arg <at> entry=86736923) at eval.c:2494
#13 0x010fbb6e in call_debugger (arg=86736923) at eval.c:308
#14 0x010f9c97 in eval_sub (form=85682323) at eval.c:2206
#15 0x010fa08f in Fprogn (body=86013979) at eval.c:427
#16 0x010fc90b in Flet (args=86008795) at eval.c:943
#17 0x010f9d2b in eval_sub (form=86008787) at eval.c:2085
#18 0x010fa08f in Fprogn (body=86008675) at eval.c:427
#19 0x010fa3a3 in funcall_lambda (fun=86008491, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0xbff598) at eval.c:2869
#20 0x010fa59f in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0xbff594)
    at eval.c:2711
#21 0x010f6a5d in Ffuncall_interactively (nargs=2, args=0xbff594)
    at callint.c:248
#22 0x010fa67d in Ffuncall (nargs=3, args=0xbff590) at eval.c:2630
#23 0x010f7381 in Fcall_interactively (function=44729056, record_flag=0, 
    keys=89093941) at callint.c:836
#24 0x010fa7af in Ffuncall (nargs=4, args=0xbff70c) at eval.c:2657
#25 0x0112a00d in exec_byte_code (bytestr=-1946399349, vector=264275401, 
    maxdepth=54, args_template=args_template <at> entry=4102, nargs=nargs <at> entry=1, 
    args=0x4) at bytecode.c:880
#26 0x010fa348 in funcall_lambda (fun=18989285, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0xbff8dc) at eval.c:2810
#27 0x010fa59f in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0xbff8d8)
    at eval.c:2711
#28 0x010fa8fe in call1 (fn=fn <at> entry=8992, arg1=44729056) at eval.c:2509
#29 0x010a1d19 in command_loop_1 () at keyboard.c:1452
#30 0x010f91d2 in internal_condition_case (
    bfun=bfun <at> entry=0x10a199c <command_loop_1>, 
    handlers=handlers <at> entry=12000, hfun=hfun <at> entry=0x1099c36 <cmd_error>)
    at eval.c:1309
#31 0x01095861 in command_loop_2 (ignore=0) at keyboard.c:1086
#32 0x010f9120 in internal_catch (tag=tag <at> entry=32032, 
    func=func <at> entry=0x1095842 <command_loop_2>, arg=arg <at> entry=0)
    at eval.c:1073
#33 0x01095823 in command_loop () at keyboard.c:1065
#34 0x010998f0 in recursive_edit_1 () at keyboard.c:671
#35 0x01099b7e in Frecursive_edit () at keyboard.c:742
#36 0x011a73af in main (argc=<optimized out>, argv=0xf034c8) at emacs.c:1652

Lisp Backtrace:
"backtrace" (0xbfedac)
"debugger-setup-buffer" (0xbfefe0)
"debug" (0xbff1b4)
"ses-relocate-all" (0xbff200)
"let" (0xbff3bc)
"ses-delete-row" (0xbff598)
"funcall-interactively" (0xbff594)
"call-interactively" (0xbff710)
"command-execute" (0xbff8dc)
(gdb)
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

VBR,
	Vincent

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Thu, 14 Jan 2016 20:20:13 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
>  ,22301 <at> debbugs.gnu.org
> Date: Thu, 14 Jan 2016 17:15:24 +0100
> 
> Dear Eli,
> 
> If not yet wished: HAPPY NEW YEAR 2016, BONNE ANNÉE 2016, С НОВЫМ ГОДОМ
> 2016 (etc...) !

Thanks.

> My gdb session is left open, so please feel free to ask more gdb
> interaction. More below...
> [...]
> Program received signal SIGSEGV, Segmentation fault.
> 0x011119c6 in print_object (obj=obj <at> entry=12579352, 
>     printcharfun=printcharfun <at> entry=0, escapeflag=escapeflag <at> entry=true)
>     at print.c:1505
> 1505		if (p != end && (*p == '-' || *p == '+')) p++;
> (gdb) thread 1
> [Switching to thread 1 (Thread 2820.0x9b0)]
> #0  0x011119c6 in print_object (obj=obj <at> entry=12579352, 
>     printcharfun=printcharfun <at> entry=0, escapeflag=escapeflag <at> entry=true)
>     at print.c:1505
> 1505		if (p != end && (*p == '-' || *p == '+')) p++;

It looks like it crashes while trying to display a Lisp backtrace.

Please tell what these commands display:

  (gdb) p p
  (gdb) p end

Thanks.

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>,
 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Thu, 14 Jan 2016 23:54:57 +0100

Answers below...

Le 14/01/2016 19:20, Eli Zaretskii a écrit :
>> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
>> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
>>  ,22301 <at> debbugs.gnu.org
>> Date: Thu, 14 Jan 2016 17:15:24 +0100
>>

[...]

>> #0  0x011119c6 in print_object (obj=obj <at> entry=12579352, 
>>     printcharfun=printcharfun <at> entry=0, escapeflag=escapeflag <at> entry=true)
>>     at print.c:1505
>> 1505		if (p != end && (*p == '-' || *p == '+')) p++;
>
> It looks like it crashes while trying to display a Lisp backtrace.
>
> Please tell what these commands display:
>
>   (gdb) p p
>   (gdb) p end
>
> Thanks.

Here you are. I tried to print other variables too, but unfortunately,
when doing that it seems that I have killed the gdb session (doing `p
*p' has caused gdb to get locked telling "value has been optimized out",
and then I had to do `M-x signal-process RET shell RET 3 RET' to exit
from this.

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
(gdb) p p
$1 = <optimized out>
(gdb) p end
$2 = (unsigned char *) 0x9bbcd354 <Address 0x9bbcd354 out of bounds>
(gdb) p obj
$3 = 12579352
(gdb) p name
$4 = <optimized out>
(gdb) p *p
(gdb) value has been optimized out
--8<----8<----8<----8<----8<--  end  -->8---->8---->8---->8---->8----

I will try to reproduce the crash... sorry for I lost the session...

VBR,
	Vincent Belaïche 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Fri, 15 Jan 2016 09:46:43 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
>  ,22301 <at> debbugs.gnu.org
> Date: Thu, 14 Jan 2016 23:54:57 +0100
> 
> > Please tell what these commands display:
> >
> >   (gdb) p p
> >   (gdb) p end
> >
> > Thanks.
> 
> Here you are. I tried to print other variables too, but unfortunately,
> when doing that it seems that I have killed the gdb session (doing `p
> *p' has caused gdb to get locked telling "value has been optimized out",
> and then I had to do `M-x signal-process RET shell RET 3 RET' to exit
> from this.
> 
> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
> (gdb) p p
> $1 = <optimized out>
> (gdb) p end
> $2 = (unsigned char *) 0x9bbcd354 <Address 0x9bbcd354 out of bounds>
> (gdb) p obj
> $3 = 12579352
> (gdb) p name
> $4 = <optimized out>
> (gdb) p *p
> (gdb) value has been optimized out

This just means you compiled Emacs with optimizations.  Can you
reproduce this in an unoptimized build?

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>,
 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Fri, 15 Jan 2016 08:56:44 +0100

Answers below...

Le 15/01/2016 08:46, Eli Zaretskii a écrit :
>> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
>> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
>>  ,22301 <at> debbugs.gnu.org
>> Date: Thu, 14 Jan 2016 23:54:57 +0100
>>
>>> Please tell what these commands display:
>>>
>>>   (gdb) p p
>>>   (gdb) p end
>>>
>>> Thanks.
>>
>> Here you are. I tried to print other variables too, but unfortunately,
>> when doing that it seems that I have killed the gdb session (doing `p
>> *p' has caused gdb to get locked telling "value has been optimized out",
>> and then I had to do `M-x signal-process RET shell RET 3 RET' to exit
>> from this.
>>
>> --8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
>> (gdb) p p
>> $1 = <optimized out>
>> (gdb) p end
>> $2 = (unsigned char *) 0x9bbcd354 <Address 0x9bbcd354 out of bounds>
>> (gdb) p obj
>> $3 = 12579352
>> (gdb) p name
>> $4 = <optimized out>
>> (gdb) p *p
>> (gdb) value has been optimized out
>
> This just means you compiled Emacs with optimizations.  Can you
> reproduce this in an unoptimized build?

I had compiled with this line in the script launching it all:

  export CPPFLAGS="$CPPFLAGS -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"

I will recompile with it modified as follows (-Og added):

  export CPPFLAGS="$CPPFLAGS -Og -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"

Could you please confirm it is what you want before I go there.

  Vincent.

PS: BTW, it won't be the same Emacs source code as the one crashing
anyway, because I did some git pull meanwhile. what shall I do with
that, shouldn't I try another git pull to work on the latest src
version, or should I try to get the same src as the one crashing by
getting a work area revision bashed on crashing Eamcs version
compilation date.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Fri, 15 Jan 2016 10:12:50 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>  ,
>  22301 <at> debbugs.gnu.org
> Date: Fri, 15 Jan 2016 08:56:44 +0100
> 
> I had compiled with this line in the script launching it all:
> 
>   export CPPFLAGS="$CPPFLAGS -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"
> 
> I will recompile with it modified as follows (-Og added):
> 
>   export CPPFLAGS="$CPPFLAGS -Og -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"
> 
> Could you please confirm it is what you want before I go there.

Not -Og, -O0.  Also, it's wrong to put all these into CPPFLAGS, so I
suggest this instead (2 commands instead of one):

  export CPPFLAGS="$CPPFLAGS -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src"
  export CFLAGS="$CFLAGS -O0 -g3 -L ${HERE_DIR}/libXpm-3.5.8/src"

> PS: BTW, it won't be the same Emacs source code as the one crashing
> anyway, because I did some git pull meanwhile. what shall I do with
> that, shouldn't I try another git pull to work on the latest src
> version, or should I try to get the same src as the one crashing by
> getting a work area revision bashed on crashing Eamcs version
> compilation date.

Using the latest sources is always TRT.  Thanks.

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>,
 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Wed, 20 Jan 2016 00:34:28 +0100

Dear Eli,

I have recompiled with the latest source and using the compiler options
which you gave me, and I do not reproduce the crash (although I have
been debugging my SES bugs at length). I have recompiled with the 32bit
MinGW. However I am not sure whether the Emacs version that was crashing
(that of 2015-12-16), was compiled with this MinGW or with the 64bit
MinGW.

I think that it was also compiled with the 32bit, because my MSYS fstab
file date is "12-16 08:49", and the crashing emacs.exe date is "12-16
10:27". So the fstab setting (currently pointing at the 32bit MinGW
compiler) is anterior the crashing Emacs emacs.exe. However I am not
100% sure, I may well have launched the compilation earlier than
changing the fstab file, but as compiling is so long, the emacs.exe date
could however be after the fstab modification time.

In a nutshell, is there any way to know whether the crashing Emacs was
compiled with the 32bit MinGW or with another MinGW. Please note that
the `M-x report-emacs-bug' gives on the crashing Emacs the following
text:

  In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
    of 2015-12-16

as was in my initial bug report.

So, where does this `i686-pc-mingw32' in the bug report come from?

   Vincent.

PS: does TRT mean "trick 'r treat" or "Turkish Radio Television"?

Le 15/01/2016 09:12, Eli Zaretskii a écrit :
>> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
>> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>  ,
>>  22301 <at> debbugs.gnu.org
>> Date: Fri, 15 Jan 2016 08:56:44 +0100
>>
>> I had compiled with this line in the script launching it all:
>>
>>   export CPPFLAGS="$CPPFLAGS -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"
>>
>> I will recompile with it modified as follows (-Og added):
>>
>>   export CPPFLAGS="$CPPFLAGS -Og -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"
>>
>> Could you please confirm it is what you want before I go there.
>
> Not -Og, -O0.  Also, it's wrong to put all these into CPPFLAGS, so I
> suggest this instead (2 commands instead of one):
>
>   export CPPFLAGS="$CPPFLAGS -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src"
>   export CFLAGS="$CFLAGS -O0 -g3 -L ${HERE_DIR}/libXpm-3.5.8/src"
>
>> PS: BTW, it won't be the same Emacs source code as the one crashing
>> anyway, because I did some git pull meanwhile. what shall I do with
>> that, shouldn't I try another git pull to work on the latest src
>> version, or should I try to get the same src as the one crashing by
>> getting a work area revision bashed on crashing Eamcs version
>> compilation date.
>
> Using the latest sources is always TRT.  Thanks.

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

From: Alexis <flexibeast <at> gmail.com>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Wed, 20 Jan 2016 12:58:58 +1100

Vincent Belaïche <vincentb1 <at> users.sourceforge.net> writes:

> So, where does this `i686-pc-mingw32' in the bug report come 
> from?

It's the value of the `system-configuration' variable.

> PS: does TRT mean "trick 'r treat" or "Turkish Radio 
> Television"?

In this context, it means "The Right Thing".


Alexis.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Wed, 20 Jan 2016 06:31:13 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>  ,
>  22301 <at> debbugs.gnu.org
> Date: Wed, 20 Jan 2016 00:34:28 +0100
> 
> I have recompiled with the latest source and using the compiler options
> which you gave me, and I do not reproduce the crash (although I have
> been debugging my SES bugs at length). I have recompiled with the 32bit
> MinGW. However I am not sure whether the Emacs version that was crashing
> (that of 2015-12-16), was compiled with this MinGW or with the 64bit
> MinGW.

If -O0 doesn't reproduce the problem, then please try with -Og
instead.

> I think that it was also compiled with the 32bit, because my MSYS fstab
> file date is "12-16 08:49", and the crashing emacs.exe date is "12-16
> 10:27". So the fstab setting (currently pointing at the 32bit MinGW
> compiler) is anterior the crashing Emacs emacs.exe. However I am not
> 100% sure, I may well have launched the compilation earlier than
> changing the fstab file, but as compiling is so long, the emacs.exe date
> could however be after the fstab modification time.
> 
> In a nutshell, is there any way to know whether the crashing Emacs was
> compiled with the 32bit MinGW or with another MinGW.

I'm not sure it's worth our time to try to figure that out.  Let's
concentrate on reproducing the bug instead, OK?

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

From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>,
 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Wed, 20 Jan 2016 09:50:36 +0100

Le 20/01/2016 05:31, Eli Zaretskii a écrit :
>> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
>> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>  ,
>>  22301 <at> debbugs.gnu.org
>> Date: Wed, 20 Jan 2016 00:34:28 +0100
>>
>> I have recompiled with the latest source and using the compiler options
>> which you gave me, and I do not reproduce the crash (although I have
>> been debugging my SES bugs at length). I have recompiled with the 32bit
>> MinGW. However I am not sure whether the Emacs version that was crashing
>> (that of 2015-12-16), was compiled with this MinGW or with the 64bit
>> MinGW.
>
> If -O0 doesn't reproduce the problem, then please try with -Og
> instead.
>

I have changed -O0 to -Og, but I also did a git pull --- I needed to do
that in order to push my corrections to SES, after all that was just
what I was initially trying to do when the crash occurred.

Now, simingly after this git pull, Emacs does not compile anymore I am
getting this.

make[2]: Leaving directory `/c/Programmes/installation/emacs-install/master/emacs/admin/unidata'
  CCLD     temacs.exe
sysdep.o: In function `init_random':
c:\Programmes\installation\emacs-install\master\emacs\src/sysdep.c:2122: undefined reference to `w32_init_random'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [temacs.exe] Error 1
make[1]: Leaving directory `/c/Programmes/installation/emacs-install/master/emacs/src'
make: *** [src] Error 2

I had a look at the emacs git Web interface
http://git.savannah.gnu.org/cgit/emacs.git/commit/, and I am now feeling
a bit panicked, as when I did the git pull some commit was inserted
automatically just after my SES corrections, I did not pay too much
attention at this `2 commits ahead', but I now realize that in this
automatic commit there is an incredible number of files affected. I
don't know why that happened so... I hope I did not make anything too
hard to revert if need be.

  Vincent.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Wed, 20 Jan 2016 11:49:46 +0200

> From: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> 
> Cc: Vincent Belaïche <vincentb1 <at> users.sourceforge.net> ,
>  22301 <at> debbugs.gnu.org
> Date: Wed, 20 Jan 2016 09:50:36 +0100
> 
> I have changed -O0 to -Og, but I also did a git pull --- I needed to do
> that in order to push my corrections to SES, after all that was just
> what I was initially trying to do when the crash occurred.
> 
> Now, simingly after this git pull, Emacs does not compile anymore I am
> getting this.

Should be fixed now.

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

From: Nicolas Richard <youngfrog <at> members.fsf.org>
To: Vincent Belaïche <vincentb1 <at> users.sourceforge.net>
Cc: 22301 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Wed, 20 Jan 2016 16:30:27 +0100

> automatic commit there is an incredible number of files affected. I
> don't know why that happened so... I hope I did not make anything too
> hard to revert if need be.

IIUC you're talking about the merge commit you created, namely
b895c72059521fec064ff27b4cfcfa4104081c4e.

What you did is that you were on your local branch, with your SES
changes, then you git pull'd from savannah/master which created a merge
commit (and then pushed the result). When creating a merge commit, emacs
uses current commit as first parent, and the second parent is the commit
at the tip of the other branch (in your case savannah/master).

Now the trick is that "git diff" will show the diff wrt the *first*
parent. In this case, git diff thus shows a diff between the merged
state and the first parent, which is your own commit. IOW, it doesn't
show what you changed, but everything that was changed by all other
people. This is why there are many changes and you don't recognize them.

If you want to check that you merged correctly, do this:
    "git diff b895c720^2 b895c720"
or equivalently (at least with bash) :
    git diff b895c720{^2,}
The "^2" part means "take second parent of given commit".

HTH,

-- 
Nicolas.

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

From: vincent.belaiche <at> gmail.com (Vincent Belaïche)
To: Nicolas Richard <youngfrog <at> members.fsf.org>
Cc: 22301 <at> debbugs.gnu.org,
 Vincent Belaïche <vincent.belaiche <at> gmail.com>
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Mon, 01 Feb 2016 10:18:06 +0100

Thank you for the comment. I did the diff and my changes were ok. Anyway
nobody else than me had changed ses.el, so the merge was rather that
many other files were affected. Indeed I was just surprised by the very
large amout of files affected in a so short lapse of time.

   Vincent.

Le 20/01/2016 16:30, Nicolas Richard a écrit :
>> automatic commit there is an incredible number of files affected. I
>> don't know why that happened so... I hope I did not make anything too
>> hard to revert if need be.
>
> IIUC you're talking about the merge commit you created, namely
> b895c72059521fec064ff27b4cfcfa4104081c4e.
>
> What you did is that you were on your local branch, with your SES
> changes, then you git pull'd from savannah/master which created a merge
> commit (and then pushed the result). When creating a merge commit, emacs
> uses current commit as first parent, and the second parent is the commit
> at the tip of the other branch (in your case savannah/master).
>
> Now the trick is that "git diff" will show the diff wrt the *first*
> parent. In this case, git diff thus shows a diff between the merged
> state and the first parent, which is your own commit. IOW, it doesn't
> show what you changed, but everything that was changed by all other
> people. This is why there are many changes and you don't recognize them.
>
> If you want to check that you merged correctly, do this:
>     "git diff b895c720^2 b895c720"
> or equivalently (at least with bash) :
>     git diff b895c720{^2,}
> The "^2" part means "take second parent of given commit".
>
> HTH,
>

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

From: vincent.belaiche <at> gmail.com (Vincent Belaïche)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22301 <at> debbugs.gnu.org,
 Vincent Belaïche <vincent.belaiche <at> gmail.com>
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Mon, 01 Feb 2016 18:22:57 +0100

Dear Eli,

Some update on this problem:

I could not reproduce it with the -Og compilation either. I tried to
recompile with same options as the crashing Emacs (-O3 and no CFLAGS)
and I could not reproduce it either.

I am now sure that the crashing Emacs was compiled with a w32 (not w64)
mingw, because when compiling with w64 you get `(i686-w64-mingw32)' in
the Emacs bug reprot, while in the orginal report there was
`(i686-pc-mingw32)'.

So either

- the changes made in ses.el by me now hide the bug (or the crash won't
  happen so easily), or

- there was some changes in the C code since the crashing Emacs, and
  that has corrected or moved/hidden the problem.


So now, I am trying to reproduce the crash again with the Emacs instance
that initially was crashing in order to find some more deterministic way
to produce the crash and be more sure what is working and what is not
working.


VBR,
	Vincent

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

From: vincent.belaiche <at> gmail.com (Vincent Belaïche)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22301 <at> debbugs.gnu.org,
 Vincent Belaïche <vincent.belaiche <at> gmail.com>
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Tue, 02 Feb 2016 08:14:48 +0100

Dear Eli,

Some update on this problem:

I could not reproduce it with the -Og compilation either. I tried to
recompile with same options as the crashing Emacs (-O3 and no CFLAGS)
and I could not reproduce it either.

I am now sure that the crashing Emacs was compiled with a w32 (not w64)
mingw, because when compiling with w64 you get `(i686-w64-mingw32)' in
the Emacs bug reprot, while in the orginal report there was
`(i686-pc-mingw32)'.

So either

- the changes made in ses.el by me now hide the bug (or the crash won't
  happen so easily), or

- there was some changes in the C code since the crashing Emacs, and
  that has corrected or moved/hidden the problem.


So now, I am trying to reproduce the crash again with the Emacs instance
that initially was crashing in order to find some more deterministic way
to produce the crash and be able to test again those other Emacs
instance with a more reliable verdict.


VBR,
	Vincent

Message #76 received at 22301-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 22301-done <at> debbugs.gnu.org
Subject: Re: bug#22301: 25.1.50; Emacs crashes while lisp debugging
Date: Wed, 07 Dec 2016 13:55:49 -0500

Vincent Belaïche wrote:

> I could not reproduce it with the -Og compilation either. I tried to
> recompile with same options as the crashing Emacs (-O3 and no CFLAGS)
> and I could not reproduce it either.
>
> I am now sure that the crashing Emacs was compiled with a w32 (not w64)
> mingw, because when compiling with w64 you get `(i686-w64-mingw32)' in
> the Emacs bug reprot, while in the orginal report there was
> `(i686-pc-mingw32)'.
>
> So either
>
> - the changes made in ses.el by me now hide the bug (or the crash won't
>   happen so easily), or
>
> - there was some changes in the C code since the crashing Emacs, and
>   that has corrected or moved/hidden the problem.
>
>
> So now, I am trying to reproduce the crash again with the Emacs instance
> that initially was crashing in order to find some more deterministic way
> to produce the crash and be able to test again those other Emacs
> instance with a more reliable verdict.


Since the best part of a year has passed, I don't think this report is
going to go anywhere and am closing it. I suggest opening a new report
if you have a more reproducible/debuggable case.

Previous Next

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