GNU bug report logs -
#9723
24.0.50; Emacs Clipboard crash
Previous Next
Reported by: Joseph Jones <josejones <at> expedia.com>
Date: Mon, 10 Oct 2011 23:43:02 UTC
Severity: normal
Found in version 24.0.50
Done: Chong Yidong <cyd <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9723 in the body.
You can then email your comments to 9723 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 10 Oct 2011 23:43:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Joseph Jones <josejones <at> expedia.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 10 Oct 2011 23:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
No real specific actions that I am aware of. Just a random crash in
emacs clipboard. Here is the text of the crash:
Emacs Clipboard: emacs.exe - Application Error
The exception Breakpoint
A breakpoint has been reached.
(0x80000003) occurred in the application at location 0x7d61002d.
Click on OK to terminate the program
Click on CANCEL to debug the program
I do not have GDB and so cannot do a debug attach and backtrace.
In GNU Emacs 24.0.50.1 (i386-mingw-nt5.2.3790)
of 2011-09-03 on SHAN-PC
Windowing system distributor `Microsoft Corp.', version 5.2.3790
configured using `configure --with-gcc (3.4)'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
value of $XMODIFIERS: nil
locale-coding-system: cp1252
default enable-multibyte-characters: t
Major mode: Shell
Minor modes in effect:
shell-dirtrack-mode: t
recentf-mode: t
ido-everywhere: t
erc-truncate-mode: t
global-auto-complete-mode: t
server-mode: t
global-linum-mode: t
linum-mode: t
display-time-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<down-mouse-1> <mouse-1> M-x s e t - a t l a n <return>
l f s 0 0 0 1 <return> M-x s e t - a t l a <return>
l f s 0 0 0 1 0 <return> c d SPC <backspace> <backspace>
<backspace> h o t u t i l <return> c d SPC . . \ t
r e <backspace> <tab> <backspace> <backspace> <backspace>
/ t r <tab> s e r <tab> c o m m <tab> h o t <tab> i
<backspace> u n i t t e s t <return> <up> <down> M-p
s <return> M-x r e p o r t - <return>
Recent messages:
File f:/workspace/source/lfs00010/travcore/server/common/hotutil/unittests/OSSMgr.cpp removed from the recentf list
File f:/workspace/source/lfs00010/travcore/server/common/hotutil/unittests/OSSMgr.h removed from the recentf list
File f:/workspace/source/lfs00010/travcore/server/common/hotutil/unittests/makefile removed from the recentf list
Cleaning up the recentf list...done (5 removed)
For information about GNU Emacs and the GNU system, type C-h C-a.
progn: Copying file: no such file or directory, f:/workspace/ini/setenv.cmd, f:/workspace/source/lfs0001/build
Setting working folder to F:\workspace\source\lfs00010\mtt
No match
History item: 1
f:/workspace/source/lfs00010/travcore/server/common/hotutil/unittests
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader emacsbug
pcmpl-unix ansi-color powershell-mode powershell shell pcomplete
atlantis cdb-gud gud easy-mmode comint smex ascope xcscope nav derived
re-builder recentf tree-widget ido erc-truncate erc-goodies erc
erc-backend erc-compat format-spec thingatpt pp cc-styles cc-align
cc-engine cc-vars cc-defs regexp-opt color-theme easymenu wid-edit cl
tiling buffer-move windmove winner ring breadcrumb byte-opt warnings
bytecomp byte-compile cconv macroexp advice help-fns advice-preload
auto-complete-config auto-complete popup p4 server linum package
tabulated-list edmacro kmacro time time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer button faces cus-face files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
multi-tty emacs)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 06:30:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> Date: Mon, 10 Oct 2011 16:42:30 -0700
>
> No real specific actions that I am aware of. Just a random crash in
> emacs clipboard. Here is the text of the crash:
>
> Emacs Clipboard: emacs.exe - Application Error
>
> The exception Breakpoint
> A breakpoint has been reached.
> (0x80000003) occurred in the application at location 0x7d61002d.
>
> Click on OK to terminate the program
> Click on CANCEL to debug the program
>
> I do not have GDB and so cannot do a debug attach and backtrace.
I hope you didn't yet click either OK or CANCEL, and so the crashed
session is still running. If so, there are a couple of things that
can still be done, even without GDB, to gather more info.
Failing that, please go to the Event Viewer (a.k.a. "system log"),
find this event in the "Application" log, and post here all the
information you see when you double-click on the log entry
corresponding to this crash. While at that, please look in other
types of log, primarily "System" and "Security", and see if there's
any event that happened at the same time.
Also, did this kind of crash happen to you before?
Finally, I suggest to download DrMinGW from this place:
http://code.google.com/p/jrfonseca/wiki/DrMingw
and install it as your system's JIT debugger. (I hope you don't
develop with Microsoft tools on the same platform, because then you
want the Visual Studio to be the JIT debugger.) Then, clicking on
CANCEL will cause DrMinGW to kick in and display a backtrace that can
be saved to a file and posted with the bug report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 10:16:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 9723 <at> debbugs.gnu.org (full text, mbox):
On Tue, 11 Oct 2011 08:29:01 +0200
Eli Zaretskii wrote:
> Failing that, please go to the Event Viewer (a.k.a. "system log"),
> find this event in the "Application" log, and post here all the
> information you see when you double-click on the log entry
> corresponding to this crash. While at that, please look in other
> types of log, primarily "System" and "Security", and see if there's
> any event that happened at the same time.
>
> Also, did this kind of crash happen to you before?
>
> Finally, I suggest to download DrMinGW from this place:
>
> http://code.google.com/p/jrfonseca/wiki/DrMingw
>
> and install it as your system's JIT debugger. (I hope you don't
> develop with Microsoft tools on the same platform, because then you
> want the Visual Studio to be the JIT debugger.) Then, clicking on
> CANCEL will cause DrMinGW to kick in and display a backtrace that can
> be saved to a file and posted with the bug report.
Wouldn't it make sense to add these instructions to the Windows-specific
section of etc/DEBUG? I don't use Windows myself, but last time someone
asked how to debug Emacs on Windows I pointed them to that file, and I
don't see anything about DrMinGW there.
--
Štěpán
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 12:22:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Štěpán Němec <stepnem <at> gmail.com>
> Cc: Joseph Jones <josejones <at> expedia.com>, 9723 <at> debbugs.gnu.org
> Date: Tue, 11 Oct 2011 12:09:31 +0200
>
> Wouldn't it make sense to add these instructions to the Windows-specific
> section of etc/DEBUG? I don't use Windows myself, but last time someone
> asked how to debug Emacs on Windows I pointed them to that file, and I
> don't see anything about DrMinGW there.
Maybe it would make sense, thanks for suggesting. One issue with this
is that etc/DEBUG is about _debugging_ Emacs, while DrMinGW is not a
debugger, strictly speaking, it just uses the Windows JIT debug
interface. But perhaps, given the fact that most Windows users will
not be able to debug Emacs, having these instructions in etc/DEBUG is
still a good idea.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 15:52:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 9723 <at> debbugs.gnu.org (full text, mbox):
My job is to develop on Windows using MSFT tools, so I do need the debugger, however I will try to set that up as the JIT debugger since most of my debugging is non-JIT only. I'll install that and if I get the crash again I will debug as best as I can.
Yes, this has happened many times before, I just never remembered to file the bug.
Event Log:
Application:
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 10/10/2011
Time: 4:33:54 PM
User: N/A
Computer: BELDQD1FQ1
Description:
Faulting application emacs.exe, version 24.0.50.0, faulting module ntdll.dll, version 5.2.3790.4789, fault address 0x0005b878.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 65 6d 61 ure ema
0018: 63 73 2e 65 78 65 20 32 cs.exe 2
0020: 34 2e 30 2e 35 30 2e 30 4.0.50.0
0028: 20 69 6e 20 6e 74 64 6c in ntdl
0030: 6c 2e 64 6c 6c 20 35 2e l.dll 5.
0038: 32 2e 33 37 39 30 2e 34 2.3790.4
0040: 37 38 39 20 61 74 20 6f 789 at o
0048: 66 66 73 65 74 20 30 30 ffset 00
0050: 30 35 62 38 37 38 05b878
System:
Event Type: Information
Event Source: Application Popup
Event Category: None
Event ID: 26
Date: 10/10/2011
Time: 4:33:52 PM
User: N/A
Computer: BELDQD1FQ1
Description:
Application popup: Emacs Clipboard: emacs.exe - Application Error : The exception Breakpoint
A breakpoint has been reached.
(0x80000003) occurred in the application at location 0x7d61002d.
Click on OK to terminate the program
Click on CANCEL to debug the program
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Event Type: Information
Event Source: Application Popup
Event Category: None
Event ID: 26
Date: 10/10/2011
Time: 4:33:54 PM
User: N/A
Computer: BELDQD1FQ1
Description:
Application popup: emacs <at> BELDQD1FQ1: emacs.exe - Application Error : The exception unknown software exception (0xc0000029) occurred in the application at location 0x7d65b878.
Click on OK to terminate the program
Click on CANCEL to debug the program
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, October 10, 2011 11:29 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> Date: Mon, 10 Oct 2011 16:42:30 -0700
>
> No real specific actions that I am aware of. Just a random crash in
> emacs clipboard. Here is the text of the crash:
>
> Emacs Clipboard: emacs.exe - Application Error
>
> The exception Breakpoint
> A breakpoint has been reached.
> (0x80000003) occurred in the application at location 0x7d61002d.
>
> Click on OK to terminate the program
> Click on CANCEL to debug the program
>
> I do not have GDB and so cannot do a debug attach and backtrace.
I hope you didn't yet click either OK or CANCEL, and so the crashed
session is still running. If so, there are a couple of things that
can still be done, even without GDB, to gather more info.
Failing that, please go to the Event Viewer (a.k.a. "system log"),
find this event in the "Application" log, and post here all the
information you see when you double-click on the log entry
corresponding to this crash. While at that, please look in other
types of log, primarily "System" and "Security", and see if there's
any event that happened at the same time.
Also, did this kind of crash happen to you before?
Finally, I suggest to download DrMinGW from this place:
http://code.google.com/p/jrfonseca/wiki/DrMingw
and install it as your system's JIT debugger. (I hope you don't
develop with Microsoft tools on the same platform, because then you
want the Visual Studio to be the JIT debugger.) Then, clicking on
CANCEL will cause DrMinGW to kick in and display a backtrace that can
be saved to a file and posted with the bug report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 17:01:03 GMT)
Full text and
rfc822 format available.
Message #20 received at 9723 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here is the crash report DrMinGW gave me after emacs just crashed.
I have noticed that the last few times it has crashed has been when attemtpint to create a new file that doesn't exists using C-x f.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, October 10, 2011 11:29 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> Date: Mon, 10 Oct 2011 16:42:30 -0700
>
> No real specific actions that I am aware of. Just a random crash in
> emacs clipboard. Here is the text of the crash:
>
> Emacs Clipboard: emacs.exe - Application Error
>
> The exception Breakpoint
> A breakpoint has been reached.
> (0x80000003) occurred in the application at location 0x7d61002d.
>
> Click on OK to terminate the program
> Click on CANCEL to debug the program
>
> I do not have GDB and so cannot do a debug attach and backtrace.
I hope you didn't yet click either OK or CANCEL, and so the crashed
session is still running. If so, there are a couple of things that
can still be done, even without GDB, to gather more info.
Failing that, please go to the Event Viewer (a.k.a. "system log"),
find this event in the "Application" log, and post here all the
information you see when you double-click on the log entry
corresponding to this crash. While at that, please look in other
types of log, primarily "System" and "Security", and see if there's
any event that happened at the same time.
Also, did this kind of crash happen to you before?
Finally, I suggest to download DrMinGW from this place:
http://code.google.com/p/jrfonseca/wiki/DrMingw
and install it as your system's JIT debugger. (I hope you don't
develop with Microsoft tools on the same platform, because then you
want the Visual Studio to be the JIT debugger.) Then, clicking on
CANCEL will cause DrMinGW to kick in and display a backtrace that can
be saved to a file and posted with the bug report.
[emacs_crash_report.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 17:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Tue, 11 Oct 2011 09:59:53 -0700
>
> Here is the crash report DrMinGW gave me after emacs just crashed.
Thanks. But it sounds like this binary doesn't have any debug info in
it, is that right? If so, could you try a build with debug info?
> I have noticed that the last few times it has crashed has been when attemtpint to create a new file that doesn't exists using C-x f.
You mean, "C-x C-f"? But that shouldn't have anything to do with the
clipboard, should it? Do you have any software installed on that
machine that could possibly explain how visiting files or creating new
files could be connected to the clipboard?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 17:59:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 9723 <at> debbugs.gnu.org (full text, mbox):
*** inline
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Tuesday, October 11, 2011 10:55 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Tue, 11 Oct 2011 09:59:53 -0700
>
> Here is the crash report DrMinGW gave me after emacs just crashed.
Thanks. But it sounds like this binary doesn't have any debug info in
it, is that right? If so, could you try a build with debug info?
*** I'll see if I can get one with debug info. This is the official pre-built binary.
> I have noticed that the last few times it has crashed has been when attemtpint to create a new file that doesn't exists using C-x f.
You mean, "C-x C-f"? But that shouldn't have anything to do with the
clipboard, should it? Do you have any software installed on that
machine that could possibly explain how visiting files or creating new
files could be connected to the clipboard?
*** Yes, C-x C-f. No, I have no idea how that is messing with the clipboard I am only forwarding what I am seeing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 18:04:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 9723 <at> debbugs.gnu.org (full text, mbox):
I don't think I can get debug builds right now. The only place I know of that I can get Emacs 24 for Windows is http://code.google.com/p/emacs-for-windows/updates/list and there is no debug download there.
Neither do I have the tools or the time to build from scratch here at work.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Tuesday, October 11, 2011 10:55 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Tue, 11 Oct 2011 09:59:53 -0700
>
> Here is the crash report DrMinGW gave me after emacs just crashed.
Thanks. But it sounds like this binary doesn't have any debug info in
it, is that right? If so, could you try a build with debug info?
> I have noticed that the last few times it has crashed has been when attemtpint to create a new file that doesn't exists using C-x f.
You mean, "C-x C-f"? But that shouldn't have anything to do with the
clipboard, should it? Do you have any software installed on that
machine that could possibly explain how visiting files or creating new
files could be connected to the clipboard?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 19:22:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Tue, 11 Oct 2011 11:03:39 -0700
>
> I don't think I can get debug builds right now. The only place I know of that I can get Emacs 24 for Windows is http://code.google.com/p/emacs-for-windows/updates/list and there is no debug download there.
>
> Neither do I have the tools or the time to build from scratch here at work.
I think you will find here a sufficiently current build of Emacs 24
that includes debug info:
ftp://alpha.gnu.org/gnu/emacs/windows/
Thanks a lot for your help and efforts so far.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 11 Oct 2011 20:44:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 9723 <at> debbugs.gnu.org (full text, mbox):
OK, I pulled down the 9/19 build. Hopefully that will crash and I can get you a decent dump.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Tuesday, October 11, 2011 12:18 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Tue, 11 Oct 2011 11:03:39 -0700
>
> I don't think I can get debug builds right now. The only place I know of that I can get Emacs 24 for Windows is http://code.google.com/p/emacs-for-windows/updates/list and there is no debug download there.
>
> Neither do I have the tools or the time to build from scratch here at work.
I think you will find here a sufficiently current build of Emacs 24
that includes debug info:
ftp://alpha.gnu.org/gnu/emacs/windows/
Thanks a lot for your help and efforts so far.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Wed, 12 Oct 2011 18:41:03 GMT)
Full text and
rfc822 format available.
Message #38 received at 9723 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Here is the DrMinGW output for the 9/19 build that was in the link you sent me.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Tuesday, October 11, 2011 12:18 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Tue, 11 Oct 2011 11:03:39 -0700
>
> I don't think I can get debug builds right now. The only place I know of that I can get Emacs 24 for Windows is http://code.google.com/p/emacs-for-windows/updates/list and there is no debug download there.
>
> Neither do I have the tools or the time to build from scratch here at work.
I think you will find here a sufficiently current build of Emacs 24
that includes debug info:
ftp://alpha.gnu.org/gnu/emacs/windows/
Thanks a lot for your help and efforts so far.
[emacs-24-dbg-9-19-2011.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 14 Oct 2011 18:07:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 12 Oct 2011 11:39:27 -0700
>
> Here is the DrMinGW output for the 9/19 build that was in the link you sent me.
Thanks. This is very strange: these addresses seem to indicate that
the crash is inside garbage collection, which makes no sense, given
the error message about the clipboard. Or maybe I'm missing
something...
Can I ask you to download GDB, the GNU debugger, from here:
http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GDB/GDB-7.3/gdb-7.3-2-mingw32-bin.tar.lzma/download
and then run this Emacs binary under GDB? (You will need the
unlzma.exe program to unpack the .lzma archive.)
To run Emacs under GDB, open a cmd window, chdir to where you have the
emacs.exe binary, and type:
gdb ./emacs.exe
After GDB starts and reads the symbols from emacs.exe, it will show
this prompt:
(gdb)
Type "run" to run Emacs normally. (If you are normally invoking Emacs
with some command line arguments, type them after the "run" command,
as in "run arg1 arg2 ...".) When Emacs crashes, please type at the
GDB prompt:
(gdb) bt full
and post the results.
Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 14 Oct 2011 19:35:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Here is what I get, and it looks like it is definitely happening during C-x C-f for a file that doesn't already exist:
(gdb) bt
#0 0x0137014e in pure ()
#1 0x010388af in unbind_to (count=54, value=54704154) at eval.c:3406
#2 0x01032687 in unwind_to_catch (catch=0x82e424, value=54704178) at eval.c:1299
#3 0x01032718 in Fthrow (tag=20382054, value=54704178) at eval.c:1337
#4 0x01143887 in signal_user_input () at w32fns.c:2482
#5 0x01143924 in post_character_message (hwnd=0x190c66, msg=256, wParam=13, lParam=1835009, modifiers=0) at w32fns.c:2542
#6 0x01144690 in w32_wnd_proc (hwnd=0x190c66, msg=256, wParam=13, lParam=1835009) at w32fns.c:2913
#7 0x7d9472d8 in USER32!DefDlgProcW () from C:\WINDOWS\syswow64\user32.dll
#8 0x00190c66 in ?? ()
#9 0x00000100 in ?? ()
#10 0x0000000d in ?? ()
#11 0x001c0001 in ?? ()
#12 0x00000001 in ?? ()
#13 0xdcbaabcd in ?? ()
#14 0x00000000 in ?? ()
(gdb) bt full
#0 0x0137014e in pure ()
No symbol table info available.
#1 0x010388af in unbind_to (count=54, value=54704154) at eval.c:3406
this_binding = {symbol = 57296896, old_value = 20382054, func = 0x137014e <pure+438414>, unused = 20382030}
quitf = 54704154
gcpro1 = {next = 0x7d94759c, var = 0x9376b0, nvars = 9663904}
gcpro2 = {next = 0x114394d, var = 0x190c66, nvars = 1806498288}
#2 0x01032687 in unwind_to_catch (catch=0x82e424, value=54704178) at eval.c:1299
last_time = 1
#3 0x01032718 in Fthrow (tag=20382054, value=54704178) at eval.c:1337
c = 0x82e424
#4 0x01143887 in signal_user_input () at w32fns.c:2482
flag = 92784554
#5 0x01143924 in post_character_message (hwnd=0x190c66, msg=256, wParam=13, lParam=1835009, modifiers=0) at w32fns.c:2542
c = 13
wmsg = {msg = {hwnd = 0x0, message = 642, wParam = 11, lParam = 1806498460, time = 18100165, pt = {x = 0, y = 13}},
dwModifiers = 0, rect = {left = 3, top = 0, right = 60997120, bottom = 60997125}}
#6 0x01144690 in w32_wnd_proc (hwnd=0x190c66, msg=256, wParam=13, lParam=1835009) at w32fns.c:2913
f = 0x6bacfdb0
dpyinfo = 0x1626820
wmsg = {msg = {hwnd = 0x190c66, message = 512, wParam = 0, lParam = 49087330, time = 246493093, pt = {x = 2102234307,
y = 2102234125}}, dwModifiers = 0, rect = {left = 2103560934, top = 23226400, right = 684, bottom = 0}}
windows_translate = 0
key = 1806499484
#7 0x7d9472d8 in USER32!DefDlgProcW () from C:\WINDOWS\syswow64\user32.dll
No symbol table info available.
#8 0x00190c66 in ?? ()
No symbol table info available.
#9 0x00000100 in ?? ()
No symbol table info available.
#10 0x0000000d in ?? ()
No symbol table info available.
#11 0x001c0001 in ?? ()
No symbol table info available.
#12 0x00000001 in ?? ()
No symbol table info available.
#13 0xdcbaabcd in ?? ()
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Friday, October 14, 2011 11:05 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 12 Oct 2011 11:39:27 -0700
>
> Here is the DrMinGW output for the 9/19 build that was in the link you sent me.
Thanks. This is very strange: these addresses seem to indicate that
the crash is inside garbage collection, which makes no sense, given
the error message about the clipboard. Or maybe I'm missing
something...
Can I ask you to download GDB, the GNU debugger, from here:
http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GDB/GDB-7.3/gdb-7.3-2-mingw32-bin.tar.lzma/download
and then run this Emacs binary under GDB? (You will need the
unlzma.exe program to unpack the .lzma archive.)
To run Emacs under GDB, open a cmd window, chdir to where you have the
emacs.exe binary, and type:
gdb ./emacs.exe
After GDB starts and reads the symbols from emacs.exe, it will show
this prompt:
(gdb)
Type "run" to run Emacs normally. (If you are normally invoking Emacs
with some command line arguments, type them after the "run" command,
as in "run arg1 arg2 ...".) When Emacs crashes, please type at the
GDB prompt:
(gdb) bt full
and post the results.
Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 14 Oct 2011 19:36:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 9723 <at> debbugs.gnu.org (full text, mbox):
At the same time, I did have a lot of text on the windows clipboard (~5KB)
-----Original Message-----
From: Joseph Jones
Sent: Friday, October 14, 2011 12:33 PM
To: 'Eli Zaretskii'
Cc: 9723 <at> debbugs.gnu.org
Subject: RE: bug#9723: 24.0.50; Emacs Clipboard crash
Here is what I get, and it looks like it is definitely happening during C-x C-f for a file that doesn't already exist:
(gdb) bt
#0 0x0137014e in pure ()
#1 0x010388af in unbind_to (count=54, value=54704154) at eval.c:3406
#2 0x01032687 in unwind_to_catch (catch=0x82e424, value=54704178) at eval.c:1299
#3 0x01032718 in Fthrow (tag=20382054, value=54704178) at eval.c:1337
#4 0x01143887 in signal_user_input () at w32fns.c:2482
#5 0x01143924 in post_character_message (hwnd=0x190c66, msg=256, wParam=13, lParam=1835009, modifiers=0) at w32fns.c:2542
#6 0x01144690 in w32_wnd_proc (hwnd=0x190c66, msg=256, wParam=13, lParam=1835009) at w32fns.c:2913
#7 0x7d9472d8 in USER32!DefDlgProcW () from C:\WINDOWS\syswow64\user32.dll
#8 0x00190c66 in ?? ()
#9 0x00000100 in ?? ()
#10 0x0000000d in ?? ()
#11 0x001c0001 in ?? ()
#12 0x00000001 in ?? ()
#13 0xdcbaabcd in ?? ()
#14 0x00000000 in ?? ()
(gdb) bt full
#0 0x0137014e in pure ()
No symbol table info available.
#1 0x010388af in unbind_to (count=54, value=54704154) at eval.c:3406
this_binding = {symbol = 57296896, old_value = 20382054, func = 0x137014e <pure+438414>, unused = 20382030}
quitf = 54704154
gcpro1 = {next = 0x7d94759c, var = 0x9376b0, nvars = 9663904}
gcpro2 = {next = 0x114394d, var = 0x190c66, nvars = 1806498288}
#2 0x01032687 in unwind_to_catch (catch=0x82e424, value=54704178) at eval.c:1299
last_time = 1
#3 0x01032718 in Fthrow (tag=20382054, value=54704178) at eval.c:1337
c = 0x82e424
#4 0x01143887 in signal_user_input () at w32fns.c:2482
flag = 92784554
#5 0x01143924 in post_character_message (hwnd=0x190c66, msg=256, wParam=13, lParam=1835009, modifiers=0) at w32fns.c:2542
c = 13
wmsg = {msg = {hwnd = 0x0, message = 642, wParam = 11, lParam = 1806498460, time = 18100165, pt = {x = 0, y = 13}},
dwModifiers = 0, rect = {left = 3, top = 0, right = 60997120, bottom = 60997125}}
#6 0x01144690 in w32_wnd_proc (hwnd=0x190c66, msg=256, wParam=13, lParam=1835009) at w32fns.c:2913
f = 0x6bacfdb0
dpyinfo = 0x1626820
wmsg = {msg = {hwnd = 0x190c66, message = 512, wParam = 0, lParam = 49087330, time = 246493093, pt = {x = 2102234307,
y = 2102234125}}, dwModifiers = 0, rect = {left = 2103560934, top = 23226400, right = 684, bottom = 0}}
windows_translate = 0
key = 1806499484
#7 0x7d9472d8 in USER32!DefDlgProcW () from C:\WINDOWS\syswow64\user32.dll
No symbol table info available.
#8 0x00190c66 in ?? ()
No symbol table info available.
#9 0x00000100 in ?? ()
No symbol table info available.
#10 0x0000000d in ?? ()
No symbol table info available.
#11 0x001c0001 in ?? ()
No symbol table info available.
#12 0x00000001 in ?? ()
No symbol table info available.
#13 0xdcbaabcd in ?? ()
No symbol table info available.
#14 0x00000000 in ?? ()
No symbol table info available.
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Friday, October 14, 2011 11:05 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 12 Oct 2011 11:39:27 -0700
>
> Here is the DrMinGW output for the 9/19 build that was in the link you sent me.
Thanks. This is very strange: these addresses seem to indicate that
the crash is inside garbage collection, which makes no sense, given
the error message about the clipboard. Or maybe I'm missing
something...
Can I ask you to download GDB, the GNU debugger, from here:
http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GDB/GDB-7.3/gdb-7.3-2-mingw32-bin.tar.lzma/download
and then run this Emacs binary under GDB? (You will need the
unlzma.exe program to unpack the .lzma archive.)
To run Emacs under GDB, open a cmd window, chdir to where you have the
emacs.exe binary, and type:
gdb ./emacs.exe
After GDB starts and reads the symbols from emacs.exe, it will show
this prompt:
(gdb)
Type "run" to run Emacs normally. (If you are normally invoking Emacs
with some command line arguments, type them after the "run" command,
as in "run arg1 arg2 ...".) When Emacs crashes, please type at the
GDB prompt:
(gdb) bt full
and post the results.
Thanks in advance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 14 Oct 2011 21:34:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Fri, 14 Oct 2011 12:33:26 -0700
>
> Here is what I get, and it looks like it is definitely happening during C-x C-f for a file that doesn't already exist:
Do you still have this crashed session in GDB? If you do, I'd like
you to display values of some variables.
Also, what does "info threads" display? If there's more than one
thread (usually, there are), please show "bt" from the other threads
as well, like this:
(gdb) thread 2
(gdb) bt
(gdb) thread 3
(gdb) bt
etc., for every thread number that's listed in "info threads", except
the one marked with an asterisk (which is the current thread, the one
whose backtrace you posted).
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 17 Oct 2011 17:09:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 9723 <at> debbugs.gnu.org (full text, mbox):
I have the GDB session running right now if you need more info. Note that I was entering in a dir name using ido-mode when this happened. The dir name was supposed to be fooMap but instead was foo< (bad typist).
Here is the backtrace of the threads:
(gdb) i threads
52 Thread 13724.0x2f34 0x7d61c876 in ?? ()
4 Thread 13724.0xda4 0x7d61c846 in ?? ()
* 3 Thread 13724.0x20f8 0x7d65b878 in ?? ()
1 Thread 13724.0x16f8 0x7d94c888 in USER32!DrawFrame () from C:\WINDOWS\syswow64\user32.dll
(gdb) bt
#0 0x7d65b878 in ?? ()
#1 0x77bc641c in msvcrt!_global_unwind2 () from C:\WINDOWS\syswow64\msvcrt.dll
#2 0x77bc7e30 in msvcrt!longjmp () from C:\WINDOWS\syswow64\msvcrt.dll
#3 0x0082ffe0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) thread 52
[Switching to thread 52 (Thread 13724.0x2f34)]#0 0x7d61c876 in ?? ()
(gdb) bt
#0 0x7d61c876 in ?? ()
#1 0x77bc084a in putch () from C:\WINDOWS\syswow64\msvcrt.dll
#2 0x00000218 in ?? ()
#3 0x016235a4 in child_procs ()
#4 0x00000001 in ?? ()
#5 0x6cbcfee0 in ?? ()
#6 0x77bc0a0d in read () from C:\WINDOWS\syswow64\msvcrt.dll
#7 0x00000004 in ?? ()
#8 0x016235a4 in child_procs ()
#9 0x00000001 in ?? ()
#10 0x00000000 in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 13724.0xda4)]#0 0x7d61c846 in ?? ()
(gdb) bt
#0 0x7d61c846 in ?? ()
#1 0x7d4d8c0d in RegisterWaitForInputIdle () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000220 in ?? ()
#3 0xffffffff in ?? ()
#4 0x00000000 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 13724.0x16f8)]#0 0x7d94c888 in USER32!DrawFrame () from C:\WINDOWS\syswow64\user32.dll
(gdb) bt
#0 0x7d94c888 in USER32!DrawFrame () from C:\WINDOWS\syswow64\user32.dll
#1 0x7dbf6fd7 in ImageList_Duplicate ()
from C:\WINDOWS\WinSxS\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_8D2E3180\comctl32.dll
#2 0x7dbf71bf in ImageList_Duplicate ()
from C:\WINDOWS\WinSxS\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_8D2E3180\comctl32.dll
#3 0x7dbf7374 in ImageList_Duplicate ()
from C:\WINDOWS\WinSxS\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_8D2E3180\comctl32.dll
#4 0x7dbf7d35 in ImageList_Duplicate ()
from C:\WINDOWS\WinSxS\WOW64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.4770_x-ww_8D2E3180\comctl32.dll
#5 0x7d9472d8 in USER32!DefDlgProcW () from C:\WINDOWS\syswow64\user32.dll
#6 0x008f0588 in ?? ()
#7 0x00000001 in ?? ()
#8 0x00000000 in ?? ()
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Friday, October 14, 2011 2:32 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Fri, 14 Oct 2011 12:33:26 -0700
>
> Here is what I get, and it looks like it is definitely happening during C-x C-f for a file that doesn't already exist:
Do you still have this crashed session in GDB? If you do, I'd like
you to display values of some variables.
Also, what does "info threads" display? If there's more than one
thread (usually, there are), please show "bt" from the other threads
as well, like this:
(gdb) thread 2
(gdb) bt
(gdb) thread 3
(gdb) bt
etc., for every thread number that's listed in "info threads", except
the one marked with an asterisk (which is the current thread, the one
whose backtrace you posted).
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 17 Oct 2011 17:56:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 10:07:16 -0700
>
> I have the GDB session running right now if you need more info. Note that I was entering in a dir name using ido-mode when this happened. The dir name was supposed to be fooMap but instead was foo< (bad typist).
>
> Here is the backtrace of the threads:
There isn't a single function here that belongs to Emacs proper.
Either the Emacs process is already very much dead, or something is
terribly messed up with its stack.
When Emacs crashed, what exactly did GDB announce before showing you
the "(gdb)" prompt?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 17 Oct 2011 18:02:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 9723 <at> debbugs.gnu.org (full text, mbox):
[New Thread 13724.0x2f34]
warning: frame 03A2BE00 (emacs <at> BELDQD1FQ1) obscured
warning: frame 03A2BE00 (emacs <at> BELDQD1FQ1) reexposed by WM_PAINT
[New Thread 13724.0x2bb0]
warning: reader_thread.SetEvent failed with 6 for fd -1
[New Thread 13724.0x1c48]
warning: reader_thread.SetEvent failed with 6 for fd -1
[New Thread 13724.0x1188]
[New Thread 13724.0x36fc]
warning: frame 03A2BE00 (emacs <at> BELDQD1FQ1) obscured
warning: frame 03A2BE00 (emacs <at> BELDQD1FQ1) reexposed by WM_PAINT
gdb: unknown target exception 0xc0000029 at 0x7d65b878
Program received signal ?, Unknown signal.
[Switching to Thread 13724.0x20f8]
0x7d65b878 in ?? ()
All I can do is try again, but that is what the debug Emacs crash looks like.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, October 17, 2011 10:53 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 10:07:16 -0700
>
> I have the GDB session running right now if you need more info. Note that I was entering in a dir name using ido-mode when this happened. The dir name was supposed to be fooMap but instead was foo< (bad typist).
>
> Here is the backtrace of the threads:
There isn't a single function here that belongs to Emacs proper.
Either the Emacs process is already very much dead, or something is
terribly messed up with its stack.
When Emacs crashed, what exactly did GDB announce before showing you
the "(gdb)" prompt?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 17 Oct 2011 18:32:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 11:00:07 -0700
>
> gdb: unknown target exception 0xc0000029 at 0x7d65b878
>
> Program received signal ?, Unknown signal.
> [Switching to Thread 13724.0x20f8]
> 0x7d65b878 in ?? ()
Exception 0xc0000029? What do you see in the Event Viewer (under
"Application", I think, look for "Application Error" in the "Source"
column) near the time Emacs crashed? Also, did the previous crashes
log a different info there, or exactly the same as this one?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 17 Oct 2011 20:33:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 9723 <at> debbugs.gnu.org (full text, mbox):
I don't think it has logged the crash in Event Viewer yet since I broke into the debugger. I don't see anything in the event viewer at all for this.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, October 17, 2011 11:30 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 11:00:07 -0700
>
> gdb: unknown target exception 0xc0000029 at 0x7d65b878
>
> Program received signal ?, Unknown signal.
> [Switching to Thread 13724.0x20f8]
> 0x7d65b878 in ?? ()
Exception 0xc0000029? What do you see in the Event Viewer (under
"Application", I think, look for "Application Error" in the "Source"
column) near the time Emacs crashed? Also, did the previous crashes
log a different info there, or exactly the same as this one?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 17 Oct 2011 20:36:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 9723 <at> debbugs.gnu.org (full text, mbox):
I am restarting Emacs in the debugger a) because I need to work and b) it was obvious that crash session was no good.
I'll let you know if I get a good crash session again.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, October 17, 2011 11:30 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 11:00:07 -0700
>
> gdb: unknown target exception 0xc0000029 at 0x7d65b878
>
> Program received signal ?, Unknown signal.
> [Switching to Thread 13724.0x20f8]
> 0x7d65b878 in ?? ()
Exception 0xc0000029? What do you see in the Event Viewer (under
"Application", I think, look for "Application Error" in the "Source"
column) near the time Emacs crashed? Also, did the previous crashes
log a different info there, or exactly the same as this one?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 17 Oct 2011 20:40:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 13:31:45 -0700
>
> I don't think it has logged the crash in Event Viewer yet since I broke into the debugger. I don't see anything in the event viewer at all for this.
Not even for the previous crashes, before you started to run under the
debugger?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 17 Oct 2011 20:49:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 9723 <at> debbugs.gnu.org (full text, mbox):
I see those, but they are different and I already sent you one of them.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, October 17, 2011 1:39 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 13:31:45 -0700
>
> I don't think it has logged the crash in Event Viewer yet since I broke into the debugger. I don't see anything in the event viewer at all for this.
Not even for the previous crashes, before you started to run under the
debugger?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 18 Oct 2011 03:46:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 13:47:32 -0700
>
> I see those, but they are different and I already sent you one of them.
I meant do you see anything in the Event Viewer that corresponds to
them? If so, could you post the data from the Event Viewer here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 20 Oct 2011 22:06:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 9723 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
OK, got another crash but I'm not in GDB because I can't debug Emacs AND use Emacs to debug my work.
Event Viewer:
Faulting application emacs.exe, version 24.0.50.0, faulting module emacs.exe, version 24.0.50.0, fault address 0x000df89c.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Dr MinGw attached.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, October 17, 2011 8:44 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 13:47:32 -0700
>
> I see those, but they are different and I already sent you one of them.
I meant do you see anything in the Event Viewer that corresponds to
them? If so, could you post the data from the Event Viewer here?
[emacs-24-dbg-9-19-2011.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 20 Oct 2011 22:31:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Just got a new crash while in GDB. Here is the GDB session information you requested last time.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 13664.0x2a74]
0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712, args_template=16837538, nargs=23009797,
args=0x186a00) at bytecode.c:1012
1012 bytecode.c: No such file or directory.
in bytecode.c
(gdb) i threads
63 Thread 13664.0x38b4 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
4 Thread 13664.0x3060 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
3 Thread 13664.0x1c64 0x7d61c846 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
2 Thread 13664.0x33e4 0x7d947860 in USER32!SetActiveWindow () from C:\WINDOWS\syswow64\user32.dll
* 1 Thread 13664.0x2a74 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712,
args_template=16837538, nargs=23009797, args=0x186a00) at bytecode.c:1012
(gdb) bt 63
#0 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712, args_template=16837538,
nargs=23009797, args=0x186a00) at bytecode.c:1012
#1 0x010dfd99 in exec_byte_code (bytestr=23009797, vector=1600000, maxdepth=8578600, args_template=17642311, nargs=20835142,
args=0x13e281a) at bytecode.c:1182
#2 0x0100eba2 in make_lispy_position (f=0x10dfd6c, x=23009797, y=20835142, t=17593177) at keyboard.c:5148
#3 0x010e0d54 in exec_byte_code (bytestr=0, vector=0, maxdepth=20850714, args_template=20850714, nargs=0, args=0x0)
at bytecode.c:1730
#4 0x01025592 in Fsequencep (object=-875902696) at data.c:352
#5 0x010279f6 in let_shadows_buffer_binding_p (symbol=0x13e281a) at data.c:1082
#6 0x01029a11 in Fkill_local_variable (variable=8583808) at data.c:1672
#7 0x0100ee4f in make_lispy_position (f=0x1029871, x=20908442, y=16922106, t=2102413915) at keyboard.c:5168
#8 0x0101cf4b in read_key_sequence (keybuf=0x13e281a, bufsize=7602259, prompt=7209057, dont_downcase_last=6357092,
can_return_switch_frame=20906466, fix_current_buffer=20850714) at keyboard.c:9472
#9 0x0100ed84 in make_lispy_position (f=0x13f01e2, x=16895784, y=20850714, t=2009014352) at keyboard.c:5163
#10 0x0101cdfe in read_key_sequence (keybuf=0x101cac1, bufsize=20850714, prompt=2009021072, dont_downcase_last=8585048,
can_return_switch_frame=0, fix_current_buffer=-1) at keyboard.c:9452
#11 0x0101cf12 in read_key_sequence (keybuf=0x135bdd6, bufsize=0, prompt=1, dont_downcase_last=0,
can_return_switch_frame=8585028, fix_current_buffer=8584944) at keyboard.c:9472
#12 0x01002eb0 in shut_down_emacs (sig=1, no_x=11551144, stuff=11546872) at emacs.c:2039
#13 0x010010b6 in __mingw_CRTStartup ()
#14 0x01001148 in WinMainCRTStartup ()
#15 0x00000001 in ?? ()
#16 0x00000001 in ?? ()
#17 0x00000000 in ?? ()
(gdb) bt 4
#0 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712, args_template=16837538,
nargs=23009797, args=0x186a00) at bytecode.c:1012
#1 0x010dfd99 in exec_byte_code (bytestr=23009797, vector=1600000, maxdepth=8578600, args_template=17642311, nargs=20835142,
args=0x13e281a) at bytecode.c:1182
#2 0x0100eba2 in make_lispy_position (f=0x10dfd6c, x=23009797, y=20835142, t=17593177) at keyboard.c:5148
#3 0x010e0d54 in exec_byte_code (bytestr=0, vector=0, maxdepth=20850714, args_template=20850714, nargs=0, args=0x0)
at bytecode.c:1730
(More stack frames follow...)
(gdb) thread 63
[Switching to thread 63 (Thread 13664.0x38b4)]#0 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
#1 0x7d4d08ac in KERNEL32!CreateThread () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x000001dc in ?? ()
#3 0x00000000 in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 13664.0x3060)]#0 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
#1 0x7d4d08ac in KERNEL32!CreateThread () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x0000021c in ?? ()
#3 0x00000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 13664.0x1c64)]#0 0x7d61c846 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7d61c846 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
#1 0x7d4d8c9e in KERNEL32!GetCommandLineW () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000230 in ?? ()
#3 0x00000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 13664.0x33e4)]#0 0x7d947860 in USER32!SetActiveWindow () from C:\WINDOWS\syswow64\user32.dll
(gdb) bt
#0 0x7d947860 in USER32!SetActiveWindow () from C:\WINDOWS\syswow64\user32.dll
#1 0x7d947bbf in USER32!SetForegroundWindow () from C:\WINDOWS\syswow64\user32.dll
#2 0x6bacfef0 in ?? ()
#3 0x01129fea in regex_compile (pattern=0x2a74 <Address 0x2a74 out of bounds>, size=1027, syntax=0, bufp=0x0) at regex.c:2632
#4 0x0112a5c1 in regex_compile (pattern=0x0, size=0, syntax=0, bufp=0x0) at regex.c:2724
#5 0x7d4dfe37 in KERNEL32!GetConsoleOutputCP () from C:\WINDOWS\syswow64\kernel32.dll
#6 0x00000000 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 13664.0x2a74)]#0 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730,
maxdepth=8578712, args_template=16837538, nargs=23009797, args=0x186a00) at bytecode.c:1012
1012 in bytecode.c
(gdb) bt
#0 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712, args_template=16837538,
nargs=23009797, args=0x186a00) at bytecode.c:1012
#1 0x010dfd99 in exec_byte_code (bytestr=23009797, vector=1600000, maxdepth=8578600, args_template=17642311, nargs=20835142,
args=0x13e281a) at bytecode.c:1182
#2 0x0100eba2 in make_lispy_position (f=0x10dfd6c, x=23009797, y=20835142, t=17593177) at keyboard.c:5148
#3 0x010e0d54 in exec_byte_code (bytestr=0, vector=0, maxdepth=20850714, args_template=20850714, nargs=0, args=0x0)
at bytecode.c:1730
#4 0x01025592 in Fsequencep (object=-875902696) at data.c:352
#5 0x010279f6 in let_shadows_buffer_binding_p (symbol=0x13e281a) at data.c:1082
#6 0x01029a11 in Fkill_local_variable (variable=8583808) at data.c:1672
#7 0x0100ee4f in make_lispy_position (f=0x1029871, x=20908442, y=16922106, t=2102413915) at keyboard.c:5168
#8 0x0101cf4b in read_key_sequence (keybuf=0x13e281a, bufsize=7602259, prompt=7209057, dont_downcase_last=6357092,
can_return_switch_frame=20906466, fix_current_buffer=20850714) at keyboard.c:9472
#9 0x0100ed84 in make_lispy_position (f=0x13f01e2, x=16895784, y=20850714, t=2009014352) at keyboard.c:5163
#10 0x0101cdfe in read_key_sequence (keybuf=0x101cac1, bufsize=20850714, prompt=2009021072, dont_downcase_last=8585048,
can_return_switch_frame=0, fix_current_buffer=-1) at keyboard.c:9452
#11 0x0101cf12 in read_key_sequence (keybuf=0x135bdd6, bufsize=0, prompt=1, dont_downcase_last=0,
can_return_switch_frame=8585028, fix_current_buffer=8584944) at keyboard.c:9472
#12 0x01002eb0 in shut_down_emacs (sig=1, no_x=11551144, stuff=11546872) at emacs.c:2039
#13 0x010010b6 in __mingw_CRTStartup ()
#14 0x01001148 in WinMainCRTStartup ()
#15 0x00000001 in ?? ()
-----Original Message-----
From: Joseph Jones
Sent: Thursday, October 20, 2011 3:04 PM
To: 'Eli Zaretskii'
Cc: 9723 <at> debbugs.gnu.org
Subject: RE: bug#9723: 24.0.50; Emacs Clipboard crash
OK, got another crash but I'm not in GDB because I can't debug Emacs AND use Emacs to debug my work.
Event Viewer:
Faulting application emacs.exe, version 24.0.50.0, faulting module emacs.exe, version 24.0.50.0, fault address 0x000df89c.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Dr MinGw attached.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, October 17, 2011 8:44 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 17 Oct 2011 13:47:32 -0700
>
> I see those, but they are different and I already sent you one of them.
I meant do you see anything in the Event Viewer that corresponds to them? If so, could you post the data from the Event Viewer here?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 21 Oct 2011 08:52:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 20 Oct 2011 15:29:33 -0700
>
> Just got a new crash while in GDB. Here is the GDB session information you requested last time.
Thanks.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 13664.0x2a74]
> 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712, args_template=16837538, nargs=23009797,
> args=0x186a00) at bytecode.c:1012
> 1012 bytecode.c: No such file or directory.
> in bytecode.c
> (gdb) i threads
> 63 Thread 13664.0x38b4 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
> 4 Thread 13664.0x3060 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
> 3 Thread 13664.0x1c64 0x7d61c846 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
> 2 Thread 13664.0x33e4 0x7d947860 in USER32!SetActiveWindow () from C:\WINDOWS\syswow64\user32.dll
> * 1 Thread 13664.0x2a74 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712,
> args_template=16837538, nargs=23009797, args=0x186a00) at bytecode.c:1012
> (gdb) bt 63
> #0 0x010df89c in exec_byte_code (bytestr=20911730, vector=20911730, maxdepth=8578712, args_template=16837538,
> nargs=23009797, args=0x186a00) at bytecode.c:1012
> #1 0x010dfd99 in exec_byte_code (bytestr=23009797, vector=1600000, maxdepth=8578600, args_template=17642311, nargs=20835142,
> args=0x13e281a) at bytecode.c:1182
> #2 0x0100eba2 in make_lispy_position (f=0x10dfd6c, x=23009797, y=20835142, t=17593177) at keyboard.c:5148
> #3 0x010e0d54 in exec_byte_code (bytestr=0, vector=0, maxdepth=20850714, args_template=20850714, nargs=0, args=0x0)
> at bytecode.c:1730
> #4 0x01025592 in Fsequencep (object=-875902696) at data.c:352
> #5 0x010279f6 in let_shadows_buffer_binding_p (symbol=0x13e281a) at data.c:1082
> #6 0x01029a11 in Fkill_local_variable (variable=8583808) at data.c:1672
> #7 0x0100ee4f in make_lispy_position (f=0x1029871, x=20908442, y=16922106, t=2102413915) at keyboard.c:5168
> #8 0x0101cf4b in read_key_sequence (keybuf=0x13e281a, bufsize=7602259, prompt=7209057, dont_downcase_last=6357092,
> can_return_switch_frame=20906466, fix_current_buffer=20850714) at keyboard.c:9472
> #9 0x0100ed84 in make_lispy_position (f=0x13f01e2, x=16895784, y=20850714, t=2009014352) at keyboard.c:5163
> #10 0x0101cdfe in read_key_sequence (keybuf=0x101cac1, bufsize=20850714, prompt=2009021072, dont_downcase_last=8585048,
> can_return_switch_frame=0, fix_current_buffer=-1) at keyboard.c:9452
> #11 0x0101cf12 in read_key_sequence (keybuf=0x135bdd6, bufsize=0, prompt=1, dont_downcase_last=0,
> can_return_switch_frame=8585028, fix_current_buffer=8584944) at keyboard.c:9472
> #12 0x01002eb0 in shut_down_emacs (sig=1, no_x=11551144, stuff=11546872) at emacs.c:2039
> #13 0x010010b6 in __mingw_CRTStartup ()
> #14 0x01001148 in WinMainCRTStartup ()
> #15 0x00000001 in ?? ()
> #16 0x00000001 in ?? ()
> #17 0x00000000 in ?? ()
I don't understand this backtrace. It says that Emacs was being shut
down because of a fatal signal. sig=1 on Windows means SIGHUP, and
the only relevant place seems to be this line in keyboard.c:
kill (getpid (), SIGHUP);
But even if this is so, how come GDB shows that shut_down_emacs was
called from the library startup code, and why does it say that
shut_down_emacs calls read_key_sequence? There are no such calls in
the code, and this being an unoptimized build, I don't expect any
intermediate functions to be inlined and disappear from the backtrace.
If you set a breakpoint in shut_down_emacs, do you get a more
reasonable backtrace?
In any case, it looks like the crash is secondary; the primary reason
is that Emacs hits some fatal error and commits suicide. Why that
happens is still a mystery for me, as is why it happens only to you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 21 Oct 2011 09:06:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> #12 0x01002eb0 in shut_down_emacs (sig=1, no_x=11551144, stuff=11546872) at emacs.c:2039
>> #13 0x010010b6 in __mingw_CRTStartup ()
>> #14 0x01001148 in WinMainCRTStartup ()
>> #15 0x00000001 in ?? ()
>> #16 0x00000001 in ?? ()
>> #17 0x00000000 in ?? ()
>
> I don't understand this backtrace. It says that Emacs was being shut
> down because of a fatal signal. sig=1 on Windows means SIGHUP, and
> the only relevant place seems to be this line in keyboard.c:
That looks more like main, with argc == 1 and argv, envp following. The
second argument of shut_down_emacs is a boolean.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 21 Oct 2011 09:16:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Joseph Jones <josejones <at> expedia.com>, 9723 <at> debbugs.gnu.org
> Date: Fri, 21 Oct 2011 11:04:15 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> #12 0x01002eb0 in shut_down_emacs (sig=1, no_x=11551144, stuff=11546872) at emacs.c:2039
> >> #13 0x010010b6 in __mingw_CRTStartup ()
> >> #14 0x01001148 in WinMainCRTStartup ()
> >> #15 0x00000001 in ?? ()
> >> #16 0x00000001 in ?? ()
> >> #17 0x00000000 in ?? ()
> >
> > I don't understand this backtrace. It says that Emacs was being shut
> > down because of a fatal signal. sig=1 on Windows means SIGHUP, and
> > the only relevant place seems to be this line in keyboard.c:
>
> That looks more like main, with argc == 1 and argv, envp following. The
> second argument of shut_down_emacs is a boolean.
You are probably right. Any idea how the backtrace could be mangled
like that, though? Bad debug info?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 21 Oct 2011 09:53:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Bad debug info?
Not unheard of.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 21 Oct 2011 16:15:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Is there a later 24 build with debug info?
-----Original Message-----
From: Andreas Schwab [mailto:schwab <at> linux-m68k.org]
Sent: Friday, October 21, 2011 2:52 AM
To: Eli Zaretskii
Cc: Joseph Jones; 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
Eli Zaretskii <eliz <at> gnu.org> writes:
> Bad debug info?
Not unheard of.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 21 Oct 2011 16:44:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Fri, 21 Oct 2011 09:13:28 -0700
>
> Is there a later 24 build with debug info?
Look here:
http://alpha.gnu.org/gnu/emacs/windows/
The latest one is emacs-20111018-r106127-bin-i386.zip. If you don't
have this one already, try it.
FWIW, this is the first time I bump into a case of bad debug info, so
I'm still bewildered by these crashes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Wed, 26 Oct 2011 16:45:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Not sure if this is good or bad news, but I have yet to hit a crash in that build of Emacs at all. Happy it's not crashing but I have no idea what the issue was and may never find out now. :-(
I'll run it in the debugger for a few more days and see if we get anything.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Friday, October 21, 2011 9:42 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Fri, 21 Oct 2011 09:13:28 -0700
>
> Is there a later 24 build with debug info?
Look here:
http://alpha.gnu.org/gnu/emacs/windows/
The latest one is emacs-20111018-r106127-bin-i386.zip. If you don't
have this one already, try it.
FWIW, this is the first time I bump into a case of bad debug info, so
I'm still bewildered by these crashes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Wed, 26 Oct 2011 18:18:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 26 Oct 2011 09:42:23 -0700
> Accept-Language: en-US
> acceptlanguage: en-US
>
> Not sure if this is good or bad news, but I have yet to hit a crash in that build of Emacs at all. Happy it's not crashing but I have no idea what the issue was and may never find out now. :-(
>
> I'll run it in the debugger for a few more days and see if we get anything.
Thanks for the update.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 27 Oct 2011 03:30:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Well, it was a nice dream...
Program received signal SIGSEGV, Segmentation fault.
0x010e0061 in exec_byte_code (bytestr=59862065, vector=59899269, maxdepth=16, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:1827
1827 bytecode.c: No such file or directory.
in bytecode.c
(gdb) i threads
52 Thread 5948.0xec0 0x7d61c876 in ?? ()
4 Thread 5948.0x2fb8 0x7d61c846 in ?? ()
3 Thread 5948.0x3dd4 0x7d65b878 in ?? ()
* 1 Thread 5948.0x2738 0x010e0061 in exec_byte_code (bytestr=59862065, vector=59899269, maxdepth=16, args_template=54736922,
nargs=0, args=0x0) at bytecode.c:1827
(gdb) bt
#0 0x010e0061 in exec_byte_code (bytestr=59862065, vector=59899269, maxdepth=16, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:1827
#1 0x01037d02 in funcall_lambda (fun=58396229, nargs=3, arg_vector=0x343381a) at eval.c:3205
#2 0x010371a3 in Ffuncall (nargs=4, args=0x82ec2c) at eval.c:3023
#3 0x010df7f2 in exec_byte_code (bytestr=92197297, vector=59748357, maxdepth=88, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#4 0x01037d02 in funcall_lambda (fun=58212581, nargs=6, arg_vector=0x343381a) at eval.c:3205
#5 0x010371a3 in Ffuncall (nargs=7, args=0x82ef70) at eval.c:3023
#6 0x010df7f2 in exec_byte_code (bytestr=92545665, vector=92501509, maxdepth=32, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#7 0x01037d02 in funcall_lambda (fun=58209253, nargs=6, arg_vector=0x343381a) at eval.c:3205
#8 0x010371a3 in Ffuncall (nargs=7, args=0x82f280) at eval.c:3023
#9 0x010df7f2 in exec_byte_code (bytestr=92526641, vector=59858181, maxdepth=36, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#10 0x01037d02 in funcall_lambda (fun=58211365, nargs=1, arg_vector=0x343381a) at eval.c:3205
#11 0x010371a3 in Ffuncall (nargs=2, args=0x82f5a0) at eval.c:3023
#12 0x010df7f2 in exec_byte_code (bytestr=92773889, vector=60704693, maxdepth=8, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#13 0x01037d02 in funcall_lambda (fun=58377125, nargs=0, arg_vector=0x343381a) at eval.c:3205
#14 0x010371a3 in Ffuncall (nargs=1, args=0x82f8d0) at eval.c:3023
#15 0x01036246 in apply1 (fn=55597322, arg=54736922) at eval.c:2710
#16 0x010e259d in Fcall_interactively (function=55597322, record_flag=54736922, keys=101274117) at callint.c:379
#17 0x01036e78 in Ffuncall (nargs=4, args=0x82fb60) at eval.c:2981
#18 0x01036349 in call3 (fn=54857066, arg1=55597322, arg2=54736922, arg3=54736922) at eval.c:2774
#19 0x0101fa4b in Fcommand_execute (cmd=55597322, record_flag=54736922, keys=54736922, special=54736922) at keyboard.c:10280
#20 0x01006535 in command_loop_1 () at keyboard.c:1570
#21 0x01032d43 in internal_condition_case (bfun=0x10055f8 <command_loop_1>, handlers=54794650, hfun=0x1004e17 <cmd_error>)
at eval.c:1499
#22 0x01005254 in command_loop_2 (ignore=54736922) at keyboard.c:1158
#23 0x01032766 in internal_catch (tag=54792674, func=0x1005230 <command_loop_2>, arg=54736922) at eval.c:1256
#24 0x01005210 in command_loop () at keyboard.c:1137
#25 0x010047ec in recursive_edit_1 () at keyboard.c:757
#26 0x01004b07 in Frecursive_edit () at keyboard.c:821
#27 0x01002834 in main (argc=1, argv=0xb02ef8) at emacs.c:1706
(gdb) thread 52
[Switching to thread 52 (Thread 5948.0xec0)]#0 0x7d61c876 in ?? ()
(gdb) bt
#0 0x7d61c876 in ?? ()
#1 0x77bc084a in putch () from C:\WINDOWS\syswow64\msvcrt.dll
#2 0x0000022c in ?? ()
#3 0x01630144 in child_procs ()
#4 0x00000001 in ?? ()
#5 0x6cbcfee0 in ?? ()
#6 0x77bc0a0d in read () from C:\WINDOWS\syswow64\msvcrt.dll
#7 0x00000004 in ?? ()
#8 0x01630144 in child_procs ()
#9 0x00000001 in ?? ()
#10 0x00000000 in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 5948.0x2fb8)]#0 0x7d61c846 in ?? ()
(gdb) bt
#0 0x7d61c846 in ?? ()
#1 0x7d4d8c0d in RegisterWaitForInputIdle () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000224 in ?? ()
#3 0xffffffff in ?? ()
#4 0x00000000 in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 5948.0x3dd4)]#0 0x7d65b878 in ?? ()
(gdb) bt
#0 0x7d65b878 in ?? ()
#1 0x77bc641c in msvcrt!_global_unwind2 () from C:\WINDOWS\syswow64\msvcrt.dll
#2 0x77bc7e30 in msvcrt!longjmp () from C:\WINDOWS\syswow64\msvcrt.dll
#3 0x0344d152 in _Jv_RegisterClasses ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Wednesday, October 26, 2011 11:16 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 26 Oct 2011 09:42:23 -0700
> Accept-Language: en-US
> acceptlanguage: en-US
>
> Not sure if this is good or bad news, but I have yet to hit a crash in that build of Emacs at all. Happy it's not crashing but I have no idea what the issue was and may never find out now. :-(
>
> I'll run it in the debugger for a few more days and see if we get anything.
Thanks for the update.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 27 Oct 2011 14:27:03 GMT)
Full text and
rfc822 format available.
Message #113 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 26 Oct 2011 20:26:59 -0700
>
> Well, it was a nice dream...
It was good while it lasted...
> Program received signal SIGSEGV, Segmentation fault.
> 0x010e0061 in exec_byte_code (bytestr=59862065, vector=59899269, maxdepth=16, args_template=54736922, nargs=0, args=0x0)
> at bytecode.c:1827
Do you still have this in the debugger, so I could ask you to show
values of some variables?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 27 Oct 2011 16:09:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Yes
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Thursday, October 27, 2011 7:25 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 26 Oct 2011 20:26:59 -0700
>
> Well, it was a nice dream...
It was good while it lasted...
> Program received signal SIGSEGV, Segmentation fault.
> 0x010e0061 in exec_byte_code (bytestr=59862065, vector=59899269, maxdepth=16, args_template=54736922, nargs=0, args=0x0)
> at bytecode.c:1827
Do you still have this in the debugger, so I could ask you to show
values of some variables?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 27 Oct 2011 17:41:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 27 Oct 2011 09:06:50 -0700
>
> Yes
Great.
First, please download the file .gdbinit from here:
http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/src/.gdbinit
Then read this file into GDB:
(gdb) source x:/path/to/.gdbinit
(This file includes a few user-defined commands that make it easier to
examine Emacs Lisp objects. One of them is the xbacktrace command I
ask you to invoke below.)
Then please type these commands, and post the results here:
(gdb) thread 1
(gdb) xbacktrace
This should display the Lisp-level backtrace.
After you show that backtrace, I might have more requests. TIA.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 27 Oct 2011 17:46:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 9723 <at> debbugs.gnu.org (full text, mbox):
(gdb) source ..\..\..\gdbinit
Warning: C:\Documents and Settings\josejones\My Documents\Downloads\emacs-24-dbg\emacs-24.0.50\bin/../lwlib: No such file or dir
ectory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
Environment variable "TERM" not defined.
Breakpoint 1 at 0x11501ac: file w32fns.c, line 7182.
Temporary breakpoint 2 at 0x11507fe: file sysdep.c, line 858.
(gdb) thread 1
[Switching to thread 1 (Thread 5948.0x2738)]#0 0x010e0061 in exec_byte_code (bytestr=59862065, vector=59899269, maxdepth=16,
args_template=54736922, nargs=0, args=0x0) at bytecode.c:1827
1827 bytecode.c: No such file or directory.
in bytecode.c
(gdb) xbacktrace
"ido-make-merged-file-list" (0x82ec30)
"ido-read-internal" (0x82ef74)
"ido-file-internal" (0x82f284)
"ido-buffer-internal" (0x82f5a4)
"ido-switch-buffer" (0x82f8d4)
"call-interactively" (0x82fb64)
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Thursday, October 27, 2011 10:38 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 27 Oct 2011 09:06:50 -0700
>
> Yes
Great.
First, please download the file .gdbinit from here:
http://bzr.savannah.gnu.org/lh/emacs/trunk/annotate/head:/src/.gdbinit
Then read this file into GDB:
(gdb) source x:/path/to/.gdbinit
(This file includes a few user-defined commands that make it easier to
examine Emacs Lisp objects. One of them is the xbacktrace command I
ask you to invoke below.)
Then please type these commands, and post the results here:
(gdb) thread 1
(gdb) xbacktrace
This should display the Lisp-level backtrace.
After you show that backtrace, I might have more requests. TIA.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 27 Oct 2011 18:09:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 27 Oct 2011 10:42:54 -0700
>
> (gdb) xbacktrace
> "ido-make-merged-file-list" (0x82ec30)
> "ido-read-internal" (0x82ef74)
> "ido-file-internal" (0x82f284)
> "ido-buffer-internal" (0x82f5a4)
> "ido-switch-buffer" (0x82f8d4)
> "call-interactively" (0x82fb64)
> (gdb)
This says that it crashed when you invoked ido-switch-buffer. Is that
accurate?
What does this command display?
(gdb) print byte_stack_list
My crystal ball says the value is zero (i.e. a NULL pointer).
Also, please show the result of this:
(gdb) print stack
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 27 Oct 2011 18:31:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Yes. Ctrl+h b is tied to ido-switch-buffer
(gdb) print byte_stack_list
$1 = (struct byte_stack *) 0x440
(gdb) print stack
$2 = {
pc = 0x58801d7 "",
byte_string = 59862065,
byte_string_start = 0x5880188 "╞\030╟╚ \"\210╞╔╩\217\210\bâ\032",
constants = 59899269,
next = 0x82eca4
}
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Thursday, October 27, 2011 11:07 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 27 Oct 2011 10:42:54 -0700
>
> (gdb) xbacktrace
> "ido-make-merged-file-list" (0x82ec30)
> "ido-read-internal" (0x82ef74)
> "ido-file-internal" (0x82f284)
> "ido-buffer-internal" (0x82f5a4)
> "ido-switch-buffer" (0x82f8d4)
> "call-interactively" (0x82fb64)
> (gdb)
This says that it crashed when you invoked ido-switch-buffer. Is that
accurate?
What does this command display?
(gdb) print byte_stack_list
My crystal ball says the value is zero (i.e. a NULL pointer).
Also, please show the result of this:
(gdb) print stack
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 28 Oct 2011 09:42:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 27 Oct 2011 11:28:31 -0700
>
> Yes. Ctrl+h b is tied to ido-switch-buffer
>
>
> (gdb) print byte_stack_list
> $1 = (struct byte_stack *) 0x440
> (gdb) print stack
> $2 = {
> pc = 0x58801d7 "",
> byte_string = 59862065,
> byte_string_start = 0x5880188 "╞\030╟╚ \"\210╞╔╩\217\210\bâ\032",
> constants = 59899269,
> next = 0x82eca4
> }
> (gdb)
So byte_stack_list isn't NULL, but is nevertheless garbage.
Hmm... some snafu during GC, perhaps?
If you still have that session in GDB, please copy the following two
functions to a file:
---------------------- cut here ----------------------
define xprintstr1
set $data = (char *) $arg0->data
output/c ($arg0->size > 1000) ? 0 : ($data[0])@($arg0->size_byte < 0 ? $arg0->size & ~gdb_array_mark_flag : $arg0->size_byte)
end
define xbytestack
set $st = &stack
while $st
printf "0x%x => ", $st->byte_string
xgetptr ($st->byte_string)
set $x = (struct Lisp_String *) $ptr
xprintstr1 $x
echo \n
set $st = $st->next
end
end
---------------------- cut here ----------------------
Let's say the file's name is `foo', then type "source foo" at GDB
prompt, and then type these two commands:
(gdb) frame 0
(gdb) xbytestack
This must be _after_ you source .gdbinit, because xbytestack uses some
of the commands defined there, so if this is a new session, source
.gdbinit first.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 28 Oct 2011 20:57:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 9723 <at> debbugs.gnu.org (full text, mbox):
#0 w32_abort () at w32fns.c:7182
7182 in w32fns.c
(gdb) xbytestack
No symbol "stack" in current context.
(gdb)
What you have there doesn't seem to work.
Here is the back trace for the crashed thread:
(gdb) bt
#0 w32_abort () at w32fns.c:7182
#1 0x010e19de in exec_byte_code (bytestr=92733073, vector=58379621, maxdepth=12, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:1834
#2 0x01037d02 in funcall_lambda (fun=58379493, nargs=1, arg_vector=0x343381a) at eval.c:3205
#3 0x010371a3 in Ffuncall (nargs=2, args=0x82d998) at eval.c:3023
#4 0x010362cf in call1 (fn=58379493, arg1=102127238) at eval.c:2743
#5 0x010793b7 in mapcar1 (leni=96, vals=0x0, fn=58379493, seq=102091926) at fns.c:2346
#6 0x0107989f in Fmapc (function=58379493, sequence=102091926) at fns.c:2434
#7 0x01036e0a in Ffuncall (nargs=3, args=0x82db00) at eval.c:2977
#8 0x010df7f2 in exec_byte_code (bytestr=92727889, vector=59869445, maxdepth=24, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#9 0x01037d02 in funcall_lambda (fun=58379333, nargs=1, arg_vector=0x343381a) at eval.c:3205
#10 0x010371a3 in Ffuncall (nargs=2, args=0x82de10) at eval.c:3023
#11 0x010df7f2 in exec_byte_code (bytestr=59875297, vector=59869701, maxdepth=28, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#12 0x01037d02 in funcall_lambda (fun=58523781, nargs=3, arg_vector=0x343381a) at eval.c:3205
#13 0x010371a3 in Ffuncall (nargs=4, args=0x82e120) at eval.c:3023
#14 0x010df7f2 in exec_byte_code (bytestr=59872801, vector=59935493, maxdepth=16, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#15 0x010ded90 in Fbyte_code (bytestr=59872801, vector=59935493, maxdepth=16) at bytecode.c:423
#16 0x01034f92 in eval_sub (form=92753774) at eval.c:2328
#17 0x01032766 in internal_catch (tag=59857306, func=0x103460e <eval_sub>, arg=92753774) at eval.c:1256
#18 0x010e01b0 in exec_byte_code (bytestr=59872929, vector=58523717, maxdepth=8, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:966
#19 0x010ded90 in Fbyte_code (bytestr=59872929, vector=58523717, maxdepth=8) at bytecode.c:423
#20 0x01034f92 in eval_sub (form=92751982) at eval.c:2328
#21 0x01032c61 in internal_lisp_condition_case (var=54736922, bodyform=92751982, handlers=92753798) at eval.c:1453
#22 0x010e0217 in exec_byte_code (bytestr=59873025, vector=58396613, maxdepth=12, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:981
#23 0x010ded90 in Fbyte_code (bytestr=59873025, vector=58396613, maxdepth=12) at bytecode.c:423
#24 0x01034f92 in eval_sub (form=92752014) at eval.c:2328
#25 0x01032c61 in internal_lisp_condition_case (var=54736922, bodyform=92752014, handlers=92752254) at eval.c:1453
#26 0x010e0217 in exec_byte_code (bytestr=59873249, vector=59940229, maxdepth=16, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:981
#27 0x01037d02 in funcall_lambda (fun=58396389, nargs=3, arg_vector=0x343381a) at eval.c:3205
#28 0x010371a3 in Ffuncall (nargs=4, args=0x82ef4c) at eval.c:3023
#29 0x010df7f2 in exec_byte_code (bytestr=92197297, vector=59854853, maxdepth=88, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#30 0x01037d02 in funcall_lambda (fun=58212901, nargs=6, arg_vector=0x343381a) at eval.c:3205
#31 0x010371a3 in Ffuncall (nargs=7, args=0x82f290) at eval.c:3023
#32 0x010df7f2 in exec_byte_code (bytestr=92545649, vector=92501509, maxdepth=32, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#33 0x01037d02 in funcall_lambda (fun=58209477, nargs=1, arg_vector=0x343381a) at eval.c:3205
#34 0x010371a3 in Ffuncall (nargs=2, args=0x82f5a0) at eval.c:3023
#35 0x010df7f2 in exec_byte_code (bytestr=92768337, vector=60704677, maxdepth=8, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#36 0x01037d02 in funcall_lambda (fun=58724037, nargs=0, arg_vector=0x343381a) at eval.c:3205
#37 0x010371a3 in Ffuncall (nargs=1, args=0x82f8d0) at eval.c:3023
#38 0x01036246 in apply1 (fn=55597490, arg=54736922) at eval.c:2710
#39 0x010e259d in Fcall_interactively (function=55597490, record_flag=54736922, keys=54758149) at callint.c:379
#40 0x01036e78 in Ffuncall (nargs=4, args=0x82fb60) at eval.c:2981
#41 0x01036349 in call3 (fn=54857066, arg1=55597490, arg2=54736922, arg3=54736922) at eval.c:2774
#42 0x0101fa4b in Fcommand_execute (cmd=55597490, record_flag=54736922, keys=54736922, special=54736922) at keyboard.c:10280
#43 0x01006535 in command_loop_1 () at keyboard.c:1570
#44 0x01032d43 in internal_condition_case (bfun=0x10055f8 <command_loop_1>, handlers=54794650, hfun=0x1004e17 <cmd_error>)
at eval.c:1499
#45 0x01005254 in command_loop_2 (ignore=54736922) at keyboard.c:1158
#46 0x01032766 in internal_catch (tag=54792674, func=0x1005230 <command_loop_2>, arg=54736922) at eval.c:1256
#47 0x01005210 in command_loop () at keyboard.c:1137
#48 0x010047ec in recursive_edit_1 () at keyboard.c:757
#49 0x01004b07 in Frecursive_edit () at keyboard.c:821
#50 0x01002834 in main (argc=1, argv=0xb02ef8) at emacs.c:1706
Lisp Backtrace:
0x37acce0 PVEC_COMPILED
"mapc" (0x82db04)
"ido-set-matches-1" (0x82de14)
"ido-make-merged-file-list-1" (0x82e124)
"byte-code" (0x82e370)
"byte-code" (0x82e710)
"byte-code" (0x82ead0)
"ido-make-merged-file-list" (0x82ef50)
"ido-read-internal" (0x82f294)
"ido-file-internal" (0x82f5a4)
"ido-find-file" (0x82f8d4)
"call-interactively" (0x82fb64)
(gdb)
(gdb) t 52
[Switching to thread 52 (Thread 15620.0x2d98)]#0 0x7d61c876 in ?? ()
(gdb) bt
#0 0x7d61c876 in ?? ()
#1 0x77bc084a in putch () from C:\WINDOWS\syswow64\msvcrt.dll
#2 0x00000218 in ?? ()
#3 0x01630144 in child_procs ()
#4 0x00000001 in ?? ()
#5 0x6cbcfee0 in ?? ()
#6 0x77bc0a0d in read () from C:\WINDOWS\syswow64\msvcrt.dll
#7 0x00000004 in ?? ()
#8 0x01630144 in child_procs ()
#9 0x00000001 in ?? ()
#10 0x00000000 in ?? ()
Lisp Backtrace:
0x37acce0 PVEC_COMPILED
"mapc" (0x82db04)
"ido-set-matches-1" (0x82de14)
"ido-make-merged-file-list-1" (0x82e124)
"byte-code" (0x82e370)
"byte-code" (0x82e710)
"byte-code" (0x82ead0)
"ido-make-merged-file-list" (0x82ef50)
"ido-read-internal" (0x82f294)
"ido-file-internal" (0x82f5a4)
"ido-find-file" (0x82f8d4)
"call-interactively" (0x82fb64)
(gdb) print stack
No symbol "stack" in current context.
(gdb) i threads
* 52 Thread 15620.0x2d98 0x7d61c876 in ?? ()
4 Thread 15620.0x2e54 0x7d61c846 in ?? ()
3 Thread 15620.0xd44 0x7d65b878 in ?? ()
1 Thread 15620.0xae8 w32_abort () at w32fns.c:7182
(gdb) t 4
[Switching to thread 4 (Thread 15620.0x2e54)]#0 0x7d61c846 in ?? ()
(gdb) bt
#0 0x7d61c846 in ?? ()
#1 0x7d4d8c0d in RegisterWaitForInputIdle () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000228 in ?? ()
#3 0xffffffff in ?? ()
#4 0x00000000 in ?? ()
Lisp Backtrace:
0x37acce0 PVEC_COMPILED
"mapc" (0x82db04)
"ido-set-matches-1" (0x82de14)
"ido-make-merged-file-list-1" (0x82e124)
"byte-code" (0x82e370)
"byte-code" (0x82e710)
"byte-code" (0x82ead0)
"ido-make-merged-file-list" (0x82ef50)
"ido-read-internal" (0x82f294)
"ido-file-internal" (0x82f5a4)
"ido-find-file" (0x82f8d4)
"call-interactively" (0x82fb64)
(gdb) print stack
No symbol "stack" in current context.
(gdb) t 3
[Switching to thread 3 (Thread 15620.0xd44)]#0 0x7d65b878 in ?? ()
(gdb) bt
#0 0x7d65b878 in ?? ()
#1 0x77bc641c in msvcrt!_global_unwind2 () from C:\WINDOWS\syswow64\msvcrt.dll
#2 0x77bc7e30 in msvcrt!longjmp () from C:\WINDOWS\syswow64\msvcrt.dll
#3 0x0082ffe0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Lisp Backtrace:
0x37acce0 PVEC_COMPILED
"mapc" (0x82db04)
"ido-set-matches-1" (0x82de14)
"ido-make-merged-file-list-1" (0x82e124)
"byte-code" (0x82e370)
"byte-code" (0x82e710)
"byte-code" (0x82ead0)
"ido-make-merged-file-list" (0x82ef50)
"ido-read-internal" (0x82f294)
"ido-file-internal" (0x82f5a4)
"ido-find-file" (0x82f8d4)
"call-interactively" (0x82fb64)
(gdb) p stack
No symbol "stack" in current context.
(gdb) t 1
[Switching to thread 1 (Thread 15620.0xae8)]#0 w32_abort () at w32fns.c:7182
7182 in w32fns.c
(gdb) bt
#0 w32_abort () at w32fns.c:7182
#1 0x010e19de in exec_byte_code (bytestr=92733073, vector=58379621, maxdepth=12, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:1834
#2 0x01037d02 in funcall_lambda (fun=58379493, nargs=1, arg_vector=0x343381a) at eval.c:3205
#3 0x010371a3 in Ffuncall (nargs=2, args=0x82d998) at eval.c:3023
#4 0x010362cf in call1 (fn=58379493, arg1=102127238) at eval.c:2743
#5 0x010793b7 in mapcar1 (leni=96, vals=0x0, fn=58379493, seq=102091926) at fns.c:2346
#6 0x0107989f in Fmapc (function=58379493, sequence=102091926) at fns.c:2434
#7 0x01036e0a in Ffuncall (nargs=3, args=0x82db00) at eval.c:2977
#8 0x010df7f2 in exec_byte_code (bytestr=92727889, vector=59869445, maxdepth=24, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#9 0x01037d02 in funcall_lambda (fun=58379333, nargs=1, arg_vector=0x343381a) at eval.c:3205
#10 0x010371a3 in Ffuncall (nargs=2, args=0x82de10) at eval.c:3023
#11 0x010df7f2 in exec_byte_code (bytestr=59875297, vector=59869701, maxdepth=28, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#12 0x01037d02 in funcall_lambda (fun=58523781, nargs=3, arg_vector=0x343381a) at eval.c:3205
#13 0x010371a3 in Ffuncall (nargs=4, args=0x82e120) at eval.c:3023
#14 0x010df7f2 in exec_byte_code (bytestr=59872801, vector=59935493, maxdepth=16, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#15 0x010ded90 in Fbyte_code (bytestr=59872801, vector=59935493, maxdepth=16) at bytecode.c:423
#16 0x01034f92 in eval_sub (form=92753774) at eval.c:2328
#17 0x01032766 in internal_catch (tag=59857306, func=0x103460e <eval_sub>, arg=92753774) at eval.c:1256
#18 0x010e01b0 in exec_byte_code (bytestr=59872929, vector=58523717, maxdepth=8, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:966
#19 0x010ded90 in Fbyte_code (bytestr=59872929, vector=58523717, maxdepth=8) at bytecode.c:423
#20 0x01034f92 in eval_sub (form=92751982) at eval.c:2328
#21 0x01032c61 in internal_lisp_condition_case (var=54736922, bodyform=92751982, handlers=92753798) at eval.c:1453
#22 0x010e0217 in exec_byte_code (bytestr=59873025, vector=58396613, maxdepth=12, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:981
#23 0x010ded90 in Fbyte_code (bytestr=59873025, vector=58396613, maxdepth=12) at bytecode.c:423
#24 0x01034f92 in eval_sub (form=92752014) at eval.c:2328
#25 0x01032c61 in internal_lisp_condition_case (var=54736922, bodyform=92752014, handlers=92752254) at eval.c:1453
#26 0x010e0217 in exec_byte_code (bytestr=59873249, vector=59940229, maxdepth=16, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:981
#27 0x01037d02 in funcall_lambda (fun=58396389, nargs=3, arg_vector=0x343381a) at eval.c:3205
#28 0x010371a3 in Ffuncall (nargs=4, args=0x82ef4c) at eval.c:3023
#29 0x010df7f2 in exec_byte_code (bytestr=92197297, vector=59854853, maxdepth=88, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#30 0x01037d02 in funcall_lambda (fun=58212901, nargs=6, arg_vector=0x343381a) at eval.c:3205
#31 0x010371a3 in Ffuncall (nargs=7, args=0x82f290) at eval.c:3023
#32 0x010df7f2 in exec_byte_code (bytestr=92545649, vector=92501509, maxdepth=32, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#33 0x01037d02 in funcall_lambda (fun=58209477, nargs=1, arg_vector=0x343381a) at eval.c:3205
#34 0x010371a3 in Ffuncall (nargs=2, args=0x82f5a0) at eval.c:3023
#35 0x010df7f2 in exec_byte_code (bytestr=92768337, vector=60704677, maxdepth=8, args_template=54736922, nargs=0, args=0x0)
at bytecode.c:785
#36 0x01037d02 in funcall_lambda (fun=58724037, nargs=0, arg_vector=0x343381a) at eval.c:3205
#37 0x010371a3 in Ffuncall (nargs=1, args=0x82f8d0) at eval.c:3023
#38 0x01036246 in apply1 (fn=55597490, arg=54736922) at eval.c:2710
#39 0x010e259d in Fcall_interactively (function=55597490, record_flag=54736922, keys=54758149) at callint.c:379
#40 0x01036e78 in Ffuncall (nargs=4, args=0x82fb60) at eval.c:2981
#41 0x01036349 in call3 (fn=54857066, arg1=55597490, arg2=54736922, arg3=54736922) at eval.c:2774
#42 0x0101fa4b in Fcommand_execute (cmd=55597490, record_flag=54736922, keys=54736922, special=54736922) at keyboard.c:10280
#43 0x01006535 in command_loop_1 () at keyboard.c:1570
#44 0x01032d43 in internal_condition_case (bfun=0x10055f8 <command_loop_1>, handlers=54794650, hfun=0x1004e17 <cmd_error>)
at eval.c:1499
#45 0x01005254 in command_loop_2 (ignore=54736922) at keyboard.c:1158
#46 0x01032766 in internal_catch (tag=54792674, func=0x1005230 <command_loop_2>, arg=54736922) at eval.c:1256
#47 0x01005210 in command_loop () at keyboard.c:1137
#48 0x010047ec in recursive_edit_1 () at keyboard.c:757
#49 0x01004b07 in Frecursive_edit () at keyboard.c:821
#50 0x01002834 in main (argc=1, argv=0xb02ef8) at emacs.c:1706
Lisp Backtrace:
0x37acce0 PVEC_COMPILED
"mapc" (0x82db04)
"ido-set-matches-1" (0x82de14)
"ido-make-merged-file-list-1" (0x82e124)
"byte-code" (0x82e370)
"byte-code" (0x82e710)
"byte-code" (0x82ead0)
"ido-make-merged-file-list" (0x82ef50)
"ido-read-internal" (0x82f294)
"ido-file-internal" (0x82f5a4)
"ido-find-file" (0x82f8d4)
"call-interactively" (0x82fb64)
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Friday, October 28, 2011 2:39 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 27 Oct 2011 11:28:31 -0700
>
> Yes. Ctrl+h b is tied to ido-switch-buffer
>
>
> (gdb) print byte_stack_list
> $1 = (struct byte_stack *) 0x440
> (gdb) print stack
> $2 = {
> pc = 0x58801d7 "",
> byte_string = 59862065,
> byte_string_start = 0x5880188 "╞\030╟╚ \"\210╞╔╩\217\210\bâ\032",
> constants = 59899269,
> next = 0x82eca4
> }
> (gdb)
So byte_stack_list isn't NULL, but is nevertheless garbage.
Hmm... some snafu during GC, perhaps?
If you still have that session in GDB, please copy the following two
functions to a file:
---------------------- cut here ----------------------
define xprintstr1
set $data = (char *) $arg0->data
output/c ($arg0->size > 1000) ? 0 : ($data[0])@($arg0->size_byte < 0 ? $arg0->size & ~gdb_array_mark_flag : $arg0->size_byte)
end
define xbytestack
set $st = &stack
while $st
printf "0x%x => ", $st->byte_string
xgetptr ($st->byte_string)
set $x = (struct Lisp_String *) $ptr
xprintstr1 $x
echo \n
set $st = $st->next
end
end
---------------------- cut here ----------------------
Let's say the file's name is `foo', then type "source foo" at GDB
prompt, and then type these two commands:
(gdb) frame 0
(gdb) xbytestack
This must be _after_ you source .gdbinit, because xbytestack uses some
of the commands defined there, so if this is a new session, source
.gdbinit first.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 29 Oct 2011 08:54:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Fri, 28 Oct 2011 13:55:02 -0700
> Accept-Language: en-US
> acceptlanguage: en-US
>
> #0 w32_abort () at w32fns.c:7182
> 7182 in w32fns.c
> (gdb) xbytestack
> No symbol "stack" in current context.
> (gdb)
>
>
> What you have there doesn't seem to work.
The xbytestack command only works in the frame of exec_byte_code, so
in this case you need to type "frame 1" first. I don't know of any
way to do that automatically in a script.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 21 Jan 2012 09:39:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Please ALWAYS have the bug address on the CC list. That's the only
way to have all the history of the bug archived by the bug tracker.
> I have another one for you. Sorry it isn't up to date but I haven't crashed in a while and forgot about it. Xbytestack wouldn't work for me but there is a lisp stack trace at the end of each bt.
Is that with the same binary you installed back then? A number of
related bugs was fixed since then, so if you are still running that
old binary, please try the latest one. I believe one of the bugs that
were fixed also fixes your clipboard-related crashes.
> Breakpoint 1, w32_abort () at w32fns.c:7182
> 7182 w32fns.c: No such file or directory.
> in w32fns.c
> (gdb) b
> Note: breakpoint 1 also set at pc 0x11501ac.
> Breakpoint 3 at 0x11501ac: file w32fns.c, line 7182.
> (gdb) bt
> #0 w32_abort () at w32fns.c:7182
> #1 0x010eb3da in adjust_glyph_matrix (w=0x6843c00, matrix=0x6f99180, x=0, y=0, dim=...) at dispnew.c:485
> #2 0x010eec07 in allocate_matrices_for_window_redisplay (w=0x6843c00) at dispnew.c:1838
> #3 0x010efa72 in adjust_frame_glyphs_for_window_redisplay (f=0x3a27e00) at dispnew.c:2167
This crash looks very different. Why did you decide it was the same
problem?
Unfortunately, it looks like you indeed are using an old build, so the
source line numbers don't make sense (e.g., line 485 in dispnew.c,
shown in frame #1, is a comment). What does "M-x emacs-version RET"
display for this binary? Given the date of build shown there, I could
try finding out what was on line 485 in dispnew.c on that date.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 21 Jan 2012 16:10:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Eli,
Thanks, I'll update as soon as I can. Hopefully this crash is fixed (the clipboard one). You wouldn't happen to know which fix or what the fix was for the one you think will help this?
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Saturday, January 21, 2012 1:38 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
Please ALWAYS have the bug address on the CC list. That's the only way to have all the history of the bug archived by the bug tracker.
> I have another one for you. Sorry it isn't up to date but I haven't crashed in a while and forgot about it. Xbytestack wouldn't work for me but there is a lisp stack trace at the end of each bt.
Is that with the same binary you installed back then? A number of related bugs was fixed since then, so if you are still running that old binary, please try the latest one. I believe one of the bugs that were fixed also fixes your clipboard-related crashes.
> Breakpoint 1, w32_abort () at w32fns.c:7182
> 7182 w32fns.c: No such file or directory.
> in w32fns.c
> (gdb) b
> Note: breakpoint 1 also set at pc 0x11501ac.
> Breakpoint 3 at 0x11501ac: file w32fns.c, line 7182.
> (gdb) bt
> #0 w32_abort () at w32fns.c:7182
> #1 0x010eb3da in adjust_glyph_matrix (w=0x6843c00, matrix=0x6f99180,
> x=0, y=0, dim=...) at dispnew.c:485
> #2 0x010eec07 in allocate_matrices_for_window_redisplay (w=0x6843c00)
> at dispnew.c:1838
> #3 0x010efa72 in adjust_frame_glyphs_for_window_redisplay
> (f=0x3a27e00) at dispnew.c:2167
This crash looks very different. Why did you decide it was the same problem?
Unfortunately, it looks like you indeed are using an old build, so the source line numbers don't make sense (e.g., line 485 in dispnew.c, shown in frame #1, is a comment). What does "M-x emacs-version RET"
display for this binary? Given the date of build shown there, I could try finding out what was on line 485 in dispnew.c on that date.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 21 Jan 2012 16:20:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Just to answer your other Q: "GNU Emacs 24.0.90.1 (i386-mingw-nt5.2.3790) of 2011-10-18 on MARVIN"
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Saturday, January 21, 2012 1:38 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
Please ALWAYS have the bug address on the CC list. That's the only way to have all the history of the bug archived by the bug tracker.
> I have another one for you. Sorry it isn't up to date but I haven't crashed in a while and forgot about it. Xbytestack wouldn't work for me but there is a lisp stack trace at the end of each bt.
Is that with the same binary you installed back then? A number of related bugs was fixed since then, so if you are still running that old binary, please try the latest one. I believe one of the bugs that were fixed also fixes your clipboard-related crashes.
> Breakpoint 1, w32_abort () at w32fns.c:7182
> 7182 w32fns.c: No such file or directory.
> in w32fns.c
> (gdb) b
> Note: breakpoint 1 also set at pc 0x11501ac.
> Breakpoint 3 at 0x11501ac: file w32fns.c, line 7182.
> (gdb) bt
> #0 w32_abort () at w32fns.c:7182
> #1 0x010eb3da in adjust_glyph_matrix (w=0x6843c00, matrix=0x6f99180,
> x=0, y=0, dim=...) at dispnew.c:485
> #2 0x010eec07 in allocate_matrices_for_window_redisplay (w=0x6843c00)
> at dispnew.c:1838
> #3 0x010efa72 in adjust_frame_glyphs_for_window_redisplay
> (f=0x3a27e00) at dispnew.c:2167
This crash looks very different. Why did you decide it was the same problem?
Unfortunately, it looks like you indeed are using an old build, so the source line numbers don't make sense (e.g., line 485 in dispnew.c, shown in frame #1, is a comment). What does "M-x emacs-version RET"
display for this binary? Given the date of build shown there, I could try finding out what was on line 485 in dispnew.c on that date.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 21 Jan 2012 16:41:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 21 Jan 2012 08:08:54 -0800
>
> Thanks, I'll update as soon as I can. Hopefully this crash is fixed (the clipboard one). You wouldn't happen to know which fix or what the fix was for the one you think will help this?
Yes, I do know. See
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9087#77
for the explanation, and
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9087#119
for the patch that was installed to fix the problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 21 Jan 2012 16:50:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Thanks. I thought it was triggered by ido but at least someone (smarter than me) figured out a repro.
Thanks for your patience on this.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Saturday, January 21, 2012 8:41 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 21 Jan 2012 08:08:54 -0800
>
> Thanks, I'll update as soon as I can. Hopefully this crash is fixed (the clipboard one). You wouldn't happen to know which fix or what the fix was for the one you think will help this?
Yes, I do know. See
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9087#77
for the explanation, and
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9087#119
for the patch that was installed to fix the problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 24 Jan 2012 02:24:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 9723 <at> debbugs.gnu.org (full text, mbox):
OK, it crashed for me again using the latest version from the link below. This time I wasn't doing anything other than running a compile. I was disconnected from the machine and when I connected remotely this is what I found.
C:\Documents and Settings\josejones\My Documents\Downloads>c:\MinGW\bin\gdb.exe -p 10208
GNU gdb (GDB) 7.2
Copyright (C) 2010 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 10208
[New Thread 10208.0x2420]
[New Thread 10208.0x1d80]
[New Thread 10208.0x3024]
[New Thread 10208.0x2c6c]
[New Thread 10208.0x29e4]
Reading symbols from C:\Documents and Settings\josejones\My Documents\Downloads\emacs-24.0.92\bin\emacs.exe...done.
[Switching to Thread 10208.0x29e4]
(gdb) source gdbinit
Warning: C:\Documents and Settings\josejones\My Documents\Downloads/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
Environment variable "DISPLAY" not defined.
Environment variable "TERM" not defined.
Breakpoint 1 at 0x114f0d3: file w32fns.c, line 7196.
Temporary breakpoint 2 at 0x114f722: file sysdep.c, line 859.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 10208.0x2420]
0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
#1 0x0114f10a in w32_abort () at w32fns.c:7210
#2 0x010ea4c8 in adjust_glyph_matrix (w=0x3903a00, matrix=0x38ed500, x=0, y=0, dim=...) at dispnew.c:493
#3 0x010eddb2 in allocate_matrices_for_window_redisplay (w=0x3903a00) at dispnew.c:1867
#4 0x010eec1d in adjust_frame_glyphs_for_window_redisplay (f=0x3903c00) at dispnew.c:2196
#5 0x010ee208 in adjust_frame_glyphs (f=0x3903c00) at dispnew.c:1944
#6 0x010ede82 in adjust_glyphs (f=0x3903c00) at dispnew.c:1889
#7 0x010f7aa7 in change_frame_size_1 (f=0x3903c00, newheight=65, newwidth=2, pretend=0, delay=0, safe=1) at dispnew.c:5826
#8 0x010f772b in change_frame_size (f=0x6, newheight=0, newwidth=-2, pretend=0, delay=0, safe=1) at dispnew.c:5736
#9 0x010f74e0 in do_pending_window_change (safe=1) at dispnew.c:5702
#10 0x011fd446 in redisplay_internal () at xdisp.c:12783
#11 0x011ff4db in redisplay_preserve_echo_area (from_where=11) at xdisp.c:13411
#12 0x0104b3d3 in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54749210,
wait_proc=0x0, just_wait_proc=0) at process.c:4554
#13 0x0100ca33 in kbd_buffer_get_event (kbp=0x82f808, used_mouse_menu=0x82fa88, end_time=0x0) at keyboard.c:3851
#14 0x01009637 in read_char (commandflag=1, nmaps=8, maps=0x82f9a0, prev_event=54749210, used_mouse_menu=0x82fa88,
end_time=0x0) at keyboard.c:2797
#15 0x0101c1d2 in read_key_sequence (keybuf=0x82fc04, bufsize=30, prompt=54749210, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9300
#16 0x01005c17 in command_loop_1 () at keyboard.c:1448
#17 0x01032b5f in internal_condition_case (bfun=0x100561f <command_loop_1>, handlers=54806938, hfun=0x1004e3e <cmd_error>)
at eval.c:1499
#18 0x0100527b in command_loop_2 (ignore=54749210) at keyboard.c:1159
#19 0x01032582 in internal_catch (tag=54804962, func=0x1005257 <command_loop_2>, arg=54749210) at eval.c:1256
#20 0x01005237 in command_loop () at keyboard.c:1138
#21 0x01004813 in recursive_edit_1 () at keyboard.c:758
#22 0x01004b2e in Frecursive_edit () at keyboard.c:822
#23 0x01002839 in main (argc=1, argv=0xb043c0) at emacs.c:1715
(gdb) info threads
4 Thread 10208.0x2c6c 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
3 Thread 10208.0x3024 0x7d61c846 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
2 Thread 10208.0x1d80 0x7d947860 in USER32!SetActiveWindow () from C:\WINDOWS\syswow64\user32.dll
* 1 Thread 10208.0x2420 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
(gdb) t 2
[Switching to thread 2 (Thread 10208.0x1d80)]#0 0x7d947860 in USER32!SetActiveWindow () from C:\WINDOWS\syswow64\user32.dll
(gdb) bt
#0 0x7d947860 in USER32!SetActiveWindow () from C:\WINDOWS\syswow64\user32.dll
#1 0x7d947bbf in USER32!SetForegroundWindow () from C:\WINDOWS\syswow64\user32.dll
#2 0x6be8fef0 in ?? ()
#3 0x01143b78 in w32_msg_pump (msg_buf=0x6be8ff58) at w32fns.c:2251
#4 0x01143dac in w32_msg_worker (arg=0x0) at w32fns.c:2470
#5 0x7d4dfe37 in KERNEL32!GetConsoleOutputCP () from C:\WINDOWS\syswow64\kernel32.dll
#6 0x00000000 in ?? ()
(gdb) t 3
[Switching to thread 3 (Thread 10208.0x3024)]#0 0x7d61c846 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7d61c846 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
#1 0x7d4d8c9e in KERNEL32!GetCommandLineW () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000228 in ?? ()
#3 0x00000000 in ?? ()
(gdb) t 4
[Switching to thread 4 (Thread 10208.0x2c6c)]#0 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0 0x7d61c876 in ntdll!NtAccessCheck () from C:\WINDOWS\system32\ntdll.dll
#1 0x7d4d08ac in KERNEL32!CreateThread () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000208 in ?? ()
#3 0x00000000 in ?? ()
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Saturday, January 21, 2012 8:41 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 21 Jan 2012 08:08:54 -0800
>
> Thanks, I'll update as soon as I can. Hopefully this crash is fixed (the clipboard one). You wouldn't happen to know which fix or what the fix was for the one you think will help this?
Yes, I do know. See
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9087#77
for the explanation, and
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9087#119
for the patch that was installed to fix the problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 24 Jan 2012 05:32:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 23 Jan 2012 18:23:10 -0800
>
> OK, it crashed for me again using the latest version from the link below.
This is not the same crash as what you had when this bug was opened.
It's something entirely different. It is clearly related to the
display engine, see below.
> This time I wasn't doing anything other than running a compile. I was disconnected from the machine and when I connected remotely this is what I found.
Sorry, I don't understand: what does it mean "disconnected from the
machine"? Are you running Emacs through a remote desktop of some kind
(mstsc.exe or some such)? If so, this definitely warrants a separate
bug report. In any case, please describe in more detail what happened
around the crash.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 10208.0x2420]
> 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
> (gdb) bt
> #0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
> #1 0x0114f10a in w32_abort () at w32fns.c:7210
> #2 0x010ea4c8 in adjust_glyph_matrix (w=0x3903a00, matrix=0x38ed500, x=0, y=0, dim=...) at dispnew.c:493
This is an assertion violation here:
left = margin_glyphs_to_reserve (w, dim.width, w->left_margin_cols);
right = margin_glyphs_to_reserve (w, dim.width, w->right_margin_cols);
xassert (left >= 0 && right >= 0);
I hope you still have this crash in the debugger; if so, please tell
what are the values of `left' and `right' (in thread #1 and in frame
#2).
It's likely that display dimensions cannot be figured out for a
disconnected remote session. This is what this crash is about.
Can you reproduce this problem at will, by deliberately disconnecting
and then reconnecting?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 24 Jan 2012 17:14:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Disconnected == Remote Desktop session. I was connected from home and then when I came in to the office and connected locally it was crashed.
Sorry, I don't have it in crashed state. I do have it running in the debugger so if it happens again I can grab more info. I am constantly connecting remotely from home so if that is the issue hopefully it will crash again.
As for reproducibility, this is the first time I've seen this. I have yet to crash it again like this.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, January 23, 2012 9:31 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 23 Jan 2012 18:23:10 -0800
>
> OK, it crashed for me again using the latest version from the link below.
This is not the same crash as what you had when this bug was opened.
It's something entirely different. It is clearly related to the display engine, see below.
> This time I wasn't doing anything other than running a compile. I was disconnected from the machine and when I connected remotely this is what I found.
Sorry, I don't understand: what does it mean "disconnected from the machine"? Are you running Emacs through a remote desktop of some kind (mstsc.exe or some such)? If so, this definitely warrants a separate bug report. In any case, please describe in more detail what happened around the crash.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> [Switching to Thread 10208.0x2420]
> 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
> (gdb) bt
> #0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
> #1 0x0114f10a in w32_abort () at w32fns.c:7210
> #2 0x010ea4c8 in adjust_glyph_matrix (w=0x3903a00, matrix=0x38ed500,
> x=0, y=0, dim=...) at dispnew.c:493
This is an assertion violation here:
left = margin_glyphs_to_reserve (w, dim.width, w->left_margin_cols);
right = margin_glyphs_to_reserve (w, dim.width, w->right_margin_cols);
xassert (left >= 0 && right >= 0);
I hope you still have this crash in the debugger; if so, please tell what are the values of `left' and `right' (in thread #1 and in frame #2).
It's likely that display dimensions cannot be figured out for a disconnected remote session. This is what this crash is about.
Can you reproduce this problem at will, by deliberately disconnecting and then reconnecting?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 30 Jan 2012 17:49:03 GMT)
Full text and
rfc822 format available.
Message #164 received at 9723 <at> debbugs.gnu.org (full text, mbox):
I have this broken in the debugger now and I will leave it there for you. This was like this when I got in this morning, no remoting in, no nothing.
Here is what I have for this crash:
warning: frame 03903C00 (emacs <at> BELDQD1FQ1) reexposed by WM_PAINT
Breakpoint 1, w32_abort () at w32fns.c:7196
7196 w32fns.c: No such file or directory.
in w32fns.c
(gdb) bp
Undefined command: "bp". Try "help".
(gdb) bt
#0 w32_abort () at w32fns.c:7196
#1 0x010ea4c8 in adjust_glyph_matrix (w=0x5b20a00, matrix=0x57b9480, x=0, y=0, dim=...) at dispnew.c:493
#2 0x010eddb2 in allocate_matrices_for_window_redisplay (w=0x5b20a00) at dispnew.c:1867
#3 0x010eec1d in adjust_frame_glyphs_for_window_redisplay (f=0x3903c00) at dispnew.c:2196
#4 0x010ee208 in adjust_frame_glyphs (f=0x3903c00) at dispnew.c:1944
#5 0x010ede82 in adjust_glyphs (f=0x3903c00) at dispnew.c:1889
#6 0x010f7aa7 in change_frame_size_1 (f=0x3903c00, newheight=65, newwidth=2, pretend=0, delay=0, safe=0) at dispnew.c:5826
#7 0x010f772b in change_frame_size (f=0x0, newheight=0, newwidth=-2, pretend=0, delay=0, safe=0) at dispnew.c:5736
#8 0x010f74e0 in do_pending_window_change (safe=0) at dispnew.c:5702
#9 0x0104b89e in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54749210,
wait_proc=0x0, just_wait_proc=0) at process.c:4673
#10 0x0100ca33 in kbd_buffer_get_event (kbp=0x82f808, used_mouse_menu=0x82fa88, end_time=0x0) at keyboard.c:3851
#11 0x01009637 in read_char (commandflag=1, nmaps=8, maps=0x82f9a0, prev_event=54749210, used_mouse_menu=0x82fa88,
end_time=0x0) at keyboard.c:2797
#12 0x0101c1d2 in read_key_sequence (keybuf=0x82fc04, bufsize=30, prompt=54749210, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9300
#13 0x01005c17 in command_loop_1 () at keyboard.c:1448
#14 0x01032b5f in internal_condition_case (bfun=0x100561f <command_loop_1>, handlers=54806938, hfun=0x1004e3e <cmd_error>)
at eval.c:1499
#15 0x0100527b in command_loop_2 (ignore=54749210) at keyboard.c:1159
#16 0x01032582 in internal_catch (tag=54804962, func=0x1005257 <command_loop_2>, arg=54749210) at eval.c:1256
#17 0x01005237 in command_loop () at keyboard.c:1138
#18 0x01004813 in recursive_edit_1 () at keyboard.c:758
#19 0x01004b2e in Frecursive_edit () at keyboard.c:822
#20 0x01002839 in main (argc=1, argv=0xb02740) at emacs.c:1715
(gdb) i locals
button = 0
(gdb) i args
No arguments.
(gdb) dim
Undefined command: "dim". Try "help".
(gdb) p dim
No symbol "dim" in current context.
(gdb) f 1
#1 0x010ea4c8 in adjust_glyph_matrix (w=0x5b20a00, matrix=0x57b9480, x=0, y=0, dim=...) at dispnew.c:493
493 dispnew.c: No such file or directory.
in dispnew.c
(gdb) p dim
$1 = {
width = 4,
height = 67
}
(gdb) p w
$2 = (struct window *) 0x5b20a00
(gdb) p *w
$3 = {
header = {
size = 1073745975,
next = {
buffer = 0x5b20400,
vector = 0x5b20400
}
},
frame = 59784197,
mini_p = 54749210,
next = 59783173,
prev = 54749210,
hchild = 54749210,
vchild = 54749210,
parent = 54749210,
left_col = 0,
top_line = 0,
total_lines = 256,
total_cols = 0,
normal_lines = 54736647,
normal_cols = 54736639,
new_total = 480,
new_normal = 54749210,
buffer = 57479173,
start = 100433619,
pointm = 100433595,
force_start = 54749210,
optional_new_start = 54749210,
hscroll = 0,
min_hscroll = 0,
use_time = 6472,
sequence_number = 60,
temslot = 8,
last_modified = 18192,
last_overlay_modified = 11356,
last_point = 1100880,
last_had_star = 54749234,
vertical_scroll_bar = 54749210,
left_margin_cols = 24,
right_margin_cols = 54749210,
left_fringe_width = 54749210,
right_fringe_width = 54749210,
fringes_outside_margins = 54749210,
scroll_bar_width = 54749210,
vertical_scroll_bar_type = 54749234,
last_mark_x = 54749210,
last_mark_y = 54749210,
window_end_pos = 0,
window_end_vpos = 0,
window_end_valid = 54749210,
update_mode_line = 54749210,
start_at_line_beg = 54749234,
display_table = 54749210,
dedicated = 54749210,
base_line_number = 9980,
base_line_pos = 1059176,
region_showing = 54749210,
column_number_displayed = 54749210,
redisplay_end_trigger = 54749210,
combination_limit = 54749210,
prev_buffers = 97438990,
next_buffers = 54749210,
window_parameters = 97408838,
current_matrix = 0x38e1280,
desired_matrix = 0x57b9480,
nrows_scale_factor = 1,
ncols_scale_factor = 2,
last_cursor = {
x = 0,
y = 0,
hpos = 0,
vpos = 0
},
cursor = {
x = 0,
y = 0,
hpos = 0,
vpos = 0
},
phys_cursor = {
x = 0,
y = 0,
hpos = 0,
vpos = 0
},
phys_cursor_type = -1,
phys_cursor_width = -1,
phys_cursor_ascent = 12,
phys_cursor_height = 16,
phys_cursor_on_p = 1,
cursor_off_p = 1,
last_cursor_off_p = 1,
must_be_updated_p = 0,
pseudo_window_p = 0,
frozen_window_start_p = 0,
vscroll = 0,
window_end_bytepos = 0
}
(gdb) p matrix
$4 = (struct glyph_matrix *) 0x57b9480
(gdb) p dim
$5 = {
width = 4,
height = 67
}
(gdb) i args
w = 0x5b20a00
matrix = 0x57b9480
x = 0
y = 0
dim = {
width = 4,
height = 67
}
(gdb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 30 Jan 2012 19:10:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 30 Jan 2012 09:47:40 -0800
>
> (gdb) p dim
> $5 = {
> width = 4,
> height = 67
> }
> (gdb) i args
> w = 0x5b20a00
> matrix = 0x57b9480
> x = 0
> y = 0
> dim = {
> width = 4,
> height = 67
> }
> (gdb)
What does "p left" and "p right" show in this frame?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 30 Jan 2012 21:17:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> Date: Mon, 30 Jan 2012 11:12:35 -0800
>
> (gdb) p left
> $6 = -2147483648
> (gdb) p right
> $7 = 0
> (gdb)
Then please show what these commands display (in the same frame):
(gdb) p w->total_cols
(gdb) p w->left_margin_cols
(gdb) xtype
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 30 Jan 2012 21:51:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 9723 <at> debbugs.gnu.org (full text, mbox):
(gdb) p w->totol_cols
There is no member named totol_cols.
(gdb) p w->total_cols
$8 = 0
(gdb) p w->left_margin_cols
$9 = 24
(gdb) xtype
Lisp_Int0
(gdb)
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, January 30, 2012 1:15 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> Date: Mon, 30 Jan 2012 11:12:35 -0800
>
> (gdb) p left
> $6 = -2147483648
> (gdb) p right
> $7 = 0
> (gdb)
Then please show what these commands display (in the same frame):
(gdb) p w->total_cols
(gdb) p w->left_margin_cols
(gdb) xtype
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 31 Jan 2012 17:46:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 30 Jan 2012 13:50:24 -0800
>
> (gdb) p w->total_cols
> $8 = 0
> (gdb) p w->left_margin_cols
> $9 = 24
> (gdb) xtype
> Lisp_Int0
> (gdb)
Thanks. This is very strange. Look at the last portion of the backtrace:
> #1 0x010ea4c8 in adjust_glyph_matrix (w=0x5b20a00, matrix=0x57b9480, x=0, y=0, dim=...) at dispnew.c:493
> #2 0x010eddb2 in allocate_matrices_for_window_redisplay (w=0x5b20a00) at dispnew.c:1867
> #3 0x010eec1d in adjust_frame_glyphs_for_window_redisplay (f=0x3903c00) at dispnew.c:2196
> #4 0x010ee208 in adjust_frame_glyphs (f=0x3903c00) at dispnew.c:1944
> #5 0x010ede82 in adjust_glyphs (f=0x3903c00) at dispnew.c:1889
> #6 0x010f7aa7 in change_frame_size_1 (f=0x3903c00, newheight=65, newwidth=2, pretend=0, delay=0, safe=0) at dispnew.c:5826
> #7 0x010f772b in change_frame_size (f=0x0, newheight=0, newwidth=-2, pretend=0, delay=0, safe=0) at dispnew.c:5736
> #8 0x010f74e0 in do_pending_window_change (safe=0) at dispnew.c:5702
> #9 0x0104b89e in wait_reading_process_output (time_limit=0, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54749210,
> wait_proc=0x0, just_wait_proc=0) at process.c:4673
According to this, Emacs decided to apply a change in window
dimensions that was pending from some previous redisplay cycle. So
far so good, but look at the new size of the window it tries to set:
its newwidth value is -2, a negative number. This should never
happen. (The value -2 is "upgraded" to +2, the minimum "safe" value,
inside change_frame_size, but 2 is also too small.)
The question is now which code requested the change of window width to
-2, and why.
Could you please run Emacs again under GDB, but this time set a
breakpoint before starting Emacs. That is, after starting the
debugger, and before running Emacs with the "run" command, set a
breakpoint like this:
(gdb) break dispnew.c: 5751 if f->new_text_cols < 2
(gdb) run
Line 5751 is where Emacs delays window size changes, to be performed
later by do_pending_window_change. Here's the relevant fragment:
/* If we can't deal with the change now, queue it for later. */
if (delay || (redisplaying_p && !safe))
{
f->new_text_lines = newheight;
f->new_text_cols = newwidth;
delayed_size_change = 1;
return;
}
I would like to know which code sets f->new_text_cols to bogus values.
If the above breakpoint ever breaks, please type "bt" and post the
results here.
Thanks.
(You can now stop the session that you left in GDB.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 31 Jan 2012 17:55:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 30 Jan 2012 13:50:24 -0800
>
> (gdb) p w->total_cols
> $8 = 0
> (gdb) p w->left_margin_cols
> $9 = 24
> (gdb) xtype
> Lisp_Int0
> (gdb)
Btw: what kind of frame and window configuration did you have before
this session crashed? IOW, how many frames did you have, how many
windows on each frame, did you have special frames like Speedbar,
minibuffer-only frames, etc.?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 31 Jan 2012 18:17:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 9723 <at> debbugs.gnu.org (full text, mbox):
1 frame, 2 windows, nothing special at all.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Tuesday, January 31, 2012 9:52 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 30 Jan 2012 13:50:24 -0800
>
> (gdb) p w->total_cols
> $8 = 0
> (gdb) p w->left_margin_cols
> $9 = 24
> (gdb) xtype
> Lisp_Int0
> (gdb)
Btw: what kind of frame and window configuration did you have before this session crashed? IOW, how many frames did you have, how many windows on each frame, did you have special frames like Speedbar, minibuffer-only frames, etc.?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Wed, 01 Feb 2012 22:10:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 9723 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Never seen this one before either, though this might be an issue with the CEDET tools in Emacs I don't see the Emacs should be crashing from it. I'll keep this session up and going for you as long as I can.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Tuesday, January 31, 2012 9:52 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 30 Jan 2012 13:50:24 -0800
>
> (gdb) p w->total_cols
> $8 = 0
> (gdb) p w->left_margin_cols
> $9 = 24
> (gdb) xtype
> Lisp_Int0
> (gdb)
Btw: what kind of frame and window configuration did you have before this session crashed? IOW, how many frames did you have, how many windows on each frame, did you have special frames like Speedbar, minibuffer-only frames, etc.?
[emacs_crash_2_1_2012.zip (application/x-zip-compressed, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 03:51:01 GMT)
Full text and
rfc822 format available.
Message #188 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 1 Feb 2012 14:08:38 -0800
>
> Never seen this one before either, though this might be an issue with the CEDET tools in Emacs I don't see the Emacs should be crashing from it. I'll keep this session up and going for you as long as I can.
That session is no longer needed. Please start a new one, with the
breakpoint that I suggested. We need to understand which code
requests such a strange resize, and why.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 04:05:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 9723 <at> debbugs.gnu.org (full text, mbox):
OK, thanx. I'll try to get it up and going again tomorrow.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Wednesday, February 01, 2012 7:48 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Wed, 1 Feb 2012 14:08:38 -0800
>
> Never seen this one before either, though this might be an issue with the CEDET tools in Emacs I don't see the Emacs should be crashing from it. I'll keep this session up and going for you as long as I can.
That session is no longer needed. Please start a new one, with the breakpoint that I suggested. We need to understand which code requests such a strange resize, and why.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 11:11:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> According to this, Emacs decided to apply a change in window
> dimensions that was pending from some previous redisplay cycle. So
> far so good, but look at the new size of the window it tries to set:
> its newwidth value is -2, a negative number. This should never
> happen. (The value -2 is "upgraded" to +2, the minimum "safe" value,
> inside change_frame_size, but 2 is also too small.)
The upgrading happens in check_frame_size and 2 is the minimum width
sufficient for the frame's root window. Why do you think it's too
small?
> The question is now which code requested the change of window width to
> -2, and why.
If you know what the minimum "safe" value is, why not use that?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 17:10:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 02 Feb 2012 12:08:34 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Joseph Jones <josejones <at> expedia.com>, 9723 <at> debbugs.gnu.org
>
> > According to this, Emacs decided to apply a change in window
> > dimensions that was pending from some previous redisplay cycle. So
> > far so good, but look at the new size of the window it tries to set:
> > its newwidth value is -2, a negative number. This should never
> > happen. (The value -2 is "upgraded" to +2, the minimum "safe" value,
> > inside change_frame_size, but 2 is also too small.)
>
> The upgrading happens in check_frame_size and 2 is the minimum width
> sufficient for the frame's root window.
Yes, I know, this is clearly visible in the backtrace.
> Why do you think it's too small?
Because it causes the assertion violation anyway.
> > The question is now which code requested the change of window width to
> > -2, and why.
>
> If you know what the minimum "safe" value is, why not use that?
I'm not sure yet that I know what is the safe value. I'd appreciate
some help, if you can. Look at the backtrace:
#1 0x010ea4c8 in adjust_glyph_matrix (w=0x5b20a00, matrix=0x57b9480, x=0, y=0, dim=...) at dispnew.c:493
#2 0x010eddb2 in allocate_matrices_for_window_redisplay (w=0x5b20a00) at dispnew.c:1867
#3 0x010eec1d in adjust_frame_glyphs_for_window_redisplay (f=0x3903c00) at dispnew.c:2196
#4 0x010ee208 in adjust_frame_glyphs (f=0x3903c00) at dispnew.c:1944
#5 0x010ede82 in adjust_glyphs (f=0x3903c00) at dispnew.c:1889
#6 0x010f7aa7 in change_frame_size_1 (f=0x3903c00, newheight=65, newwidth=2, pretend=0, delay=0, safe=0) at dispnew.c:5826
#7 0x010f772b in change_frame_size (f=0x0, newheight=0, newwidth=-2, pretend=0, delay=0, safe=0) at dispnew.c:5736
#8 0x010f74e0 in do_pending_window_change (safe=0) at dispnew.c:5702
If newwidth is 2 (in frame 6), then how come w->total_cols becomes
zero by the time it gets to adjust_glyph_matrix? Joseph reported
these values:
w->left_margin_cols = 24
w->total_cols = 0
How did that happen, in a window that is just 2 columns wide?? If
that's legit, then 2 is too small; or else we have yet another bug on
our hands.
TIA
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 17:10:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 9723 <at> debbugs.gnu.org (full text, mbox):
My thought exactly, but it would be interesting to know why it is trying to set a bad size in the first place. Given my abilities to keep debug sessions running, though, I would vote to go with the defensive fix and correct or abort an invalid resize.
-----Original Message-----
From: martin rudalics [mailto:rudalics <at> gmx.at]
Sent: Thursday, February 02, 2012 3:09 AM
To: Eli Zaretskii
Cc: Joseph Jones; 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> According to this, Emacs decided to apply a change in window > dimensions that was pending from some previous redisplay cycle. So > far so good, but look at the new size of the window it tries to set:
> its newwidth value is -2, a negative number. This should never > happen. (The value -2 is "upgraded" to +2, the minimum "safe" value, > inside change_frame_size, but 2 is also too small.)
The upgrading happens in check_frame_size and 2 is the minimum width sufficient for the frame's root window. Why do you think it's too small?
> The question is now which code requested the change of window width to > -2, and why.
If you know what the minimum "safe" value is, why not use that?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 17:42:01 GMT)
Full text and
rfc822 format available.
Message #203 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Thu, 2 Feb 2012 09:08:51 -0800
>
> My thought exactly, but it would be interesting to know why it is trying to set a bad size in the first place. Given my abilities to keep debug sessions running, though, I would vote to go with the defensive fix and correct or abort an invalid resize.
I don't like to make "defensive" fixes for problems I don't
understand, because they run a risk of sweeping a real bug under the
carpet.
Once we understand the root cause, we will certainly entertain a
possibility of a defensive fix, among others.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 19:25:02 GMT)
Full text and
rfc822 format available.
Message #206 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> I'm not sure yet that I know what is the safe value.
As far as resize_frame_windows is concerned the smallest value is 2.
Modulo any bugs it assigns this value directly if the frame has just one
window. If the frame has at least two side-by-side windows, it checks
that the width of any of these windows is at least 2. If this doesn't
fit, it deletes all windows but the selected one. So 2 is the safe
value unless the display code needs more.
> If newwidth is 2 (in frame 6), then how come w->total_cols becomes
> zero by the time it gets to adjust_glyph_matrix? Joseph reported
> these values:
>
> w->left_margin_cols = 24
> w->total_cols = 0
24 doesn't strike me as reasonable for the left margin. So I'm not sure
what to think of these values.
> How did that happen, in a window that is just 2 columns wide?? If
> that's legit, then 2 is too small; or else we have yet another bug on
> our hands.
The problem is that I cannot reproduce the crash easily. It seems that
Windows assures that any frame has a minimum width of 5 or so columns,
hence `set-frame-width' is of no use. Do you have any idea how to
simulate the crash by calling change_frame_size with Joseph's values?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 19:25:02 GMT)
Full text and
rfc822 format available.
Message #209 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> I don't like to make "defensive" fixes for problems I don't
> understand, because they run a risk of sweeping a real bug under the
> carpet.
>
> Once we understand the root cause, we will certainly entertain a
> possibility of a defensive fix, among others.
I obviously agree. But it's nowhere written that change_frame_size must
be called with reasonable arguments.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Thu, 02 Feb 2012 20:29:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 02 Feb 2012 20:22:39 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: josejones <at> expedia.com, 9723 <at> debbugs.gnu.org
>
> Do you have any idea how to simulate the crash by calling
> change_frame_size with Joseph's values?
Inject a special code that overrides the "normal" values when
do_pending_window_change is called?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 03 Feb 2012 18:26:01 GMT)
Full text and
rfc822 format available.
Message #215 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Inject a special code that overrides the "normal" values when
> do_pending_window_change is called?
I added a Lisp variable frame-bomb and in change_frame_size do
else if (CONSP (Vframe_bomb))
change_frame_size_1 (f, XINT (Fcar (Vframe_bomb)), XINT (Fcdr (Vframe_bomb)), 0, 0, 0);
else
change_frame_size_1 (f, newheight, newwidth, pretend, delay, safe);
but this gets me a resized root window and NOT a resized frame so I am
still missing something. In all cases w->total_cols was set to 2 for
the frame's selected window if I counted correctly (I divided by four).
Is there any way to print the value of an Elisp integer? Nowhere did I
get a value of zero for w->total_cols.
In any case, the following excerpt from change_frame_size_1 is fishy:
/* Compute width of windows in F.
This is the width of the frame without vertical scroll bars. */
new_frame_total_cols = FRAME_TOTAL_COLS_ARG (f, newwidth);
/* Round up to the smallest acceptable size. */
check_frame_size (f, &newheight, &newwidth);
This means that when "rounding" changes newwidth, the new value is NOT
reflected in new_frame_total_cols. Interchanging these lines gets me a
w->total_cols of 6 for the window (again, if I counted correctly) which
seems slightly more correct to me. WDYT?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Fri, 03 Feb 2012 19:08:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 03 Feb 2012 19:23:30 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: josejones <at> expedia.com, 9723 <at> debbugs.gnu.org
>
> In all cases w->total_cols was set to 2 for the frame's selected
> window if I counted correctly (I divided by four). Is there any way
> to print the value of an Elisp integer?
Dividing by four is the right thing.
> In any case, the following excerpt from change_frame_size_1 is fishy:
>
> /* Compute width of windows in F.
> This is the width of the frame without vertical scroll bars. */
> new_frame_total_cols = FRAME_TOTAL_COLS_ARG (f, newwidth);
>
> /* Round up to the smallest acceptable size. */
> check_frame_size (f, &newheight, &newwidth);
>
> This means that when "rounding" changes newwidth, the new value is NOT
> reflected in new_frame_total_cols. Interchanging these lines gets me a
> w->total_cols of 6 for the window (again, if I counted correctly) which
> seems slightly more correct to me. WDYT?
I think you should install it. Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 13:58:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 9723 <at> debbugs.gnu.org (full text, mbox):
>> Is there any way
>> to print the value of an Elisp integer?
>
> Dividing by four is the right thing.
Can there ever be a remainder when printing?
> I think you should install it. Thanks.
Installed. I still don't understand why frames should have fringes and
scrollbars and why we should count them.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 14:18:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Feb 2012 14:56:29 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: josejones <at> expedia.com, 9723 <at> debbugs.gnu.org
>
> >> Is there any way
> >> to print the value of an Elisp integer?
> >
> > Dividing by four is the right thing.
>
> Can there ever be a remainder when printing?
I'm not sure I understand. Lisp integers are shifted 2 bits to the
left in C. Does that answer your question? If not, please tell more.
> > I think you should install it. Thanks.
>
> Installed. I still don't understand why frames should have fringes and
> scrollbars and why we should count them.
Again, not sure I understand you. frame.h says:
/* Total width of frame F, in columns (characters),
including the width used by scroll bars if any. */
#define FRAME_TOTAL_COLS(f) ((f)->total_cols)
This width is supposed to be the width of the window as known to the
window manager, so it includes everything Emacs controls.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 15:02:01 GMT)
Full text and
rfc822 format available.
Message #227 received at 9723 <at> debbugs.gnu.org (full text, mbox):
>> Can there ever be a remainder when printing?
>
> I'm not sure I understand. Lisp integers are shifted 2 bits to the
> left in C. Does that answer your question? If not, please tell more.
IIUC they are shifted to accomodate the collector bits. Are these
always zero?
> Again, not sure I understand you. frame.h says:
>
> /* Total width of frame F, in columns (characters),
> including the width used by scroll bars if any. */
>
> #define FRAME_TOTAL_COLS(f) ((f)->total_cols)
>
> This width is supposed to be the width of the window as known to the
> window manager, so it includes everything Emacs controls.
Scrollbars and fringes pertain to Emacs windows, not Emacs frames. What
sense does it make to count them for frames?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 15:34:01 GMT)
Full text and
rfc822 format available.
Message #230 received at 9723 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>>> Can there ever be a remainder when printing?
>>
>> I'm not sure I understand. Lisp integers are shifted 2 bits to the
>> left in C. Does that answer your question? If not, please tell more.
>
> IIUC they are shifted to accomodate the collector bits.
No, those are the tag bits. Lisp integers have no GC bit, since they
are not collectable.
> Are these always zero?
Yes.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 15:41:01 GMT)
Full text and
rfc822 format available.
Message #233 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Feb 2012 16:00:37 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: josejones <at> expedia.com, 9723 <at> debbugs.gnu.org
>
> >> Can there ever be a remainder when printing?
> >
> > I'm not sure I understand. Lisp integers are shifted 2 bits to the
> > left in C. Does that answer your question? If not, please tell more.
>
> IIUC they are shifted to accomodate the collector bits. Are these
> always zero?
Andreas answered that.
> > Again, not sure I understand you. frame.h says:
> >
> > /* Total width of frame F, in columns (characters),
> > including the width used by scroll bars if any. */
> >
> > #define FRAME_TOTAL_COLS(f) ((f)->total_cols)
> >
> > This width is supposed to be the width of the window as known to the
> > window manager, so it includes everything Emacs controls.
>
> Scrollbars and fringes pertain to Emacs windows, not Emacs frames. What
> sense does it make to count them for frames?
You need this value to communicate with the window manager and the
toolkit. And that value should include one scroll bar and one pair of
fringes, in addition to text width. Storing that value in a separate
struct member is a convenience device, nothing more.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 17:25:01 GMT)
Full text and
rfc822 format available.
Message #236 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> No, those are the tag bits. Lisp integers have no GC bit, since they
> are not collectable.
>
>> Are these always zero?
>
> Yes.
Thanks. Is there no way to strip these when printing them from GDB
running under Emacs?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 17:26:01 GMT)
Full text and
rfc822 format available.
Message #239 received at 9723 <at> debbugs.gnu.org (full text, mbox):
>> Scrollbars and fringes pertain to Emacs windows, not Emacs frames. What
>> sense does it make to count them for frames?
>
> You need this value to communicate with the window manager and the
> toolkit. And that value should include one scroll bar and one pair of
> fringes, in addition to text width. Storing that value in a separate
> struct member is a convenience device, nothing more.
But in change_frame_size_1 we use "this value" to adjust the sizes of
Emacs windows. Moreover, why communicate the presence of a scrollbar to
the window manager and the toolkit? Suppose I do
(set-frame-parameter nil 'vertical-scroll-bars nil)
(set-window-scroll-bars nil 16 'right)
then my window has scrollbars and the frame doesn't. Confusing.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 17:47:02 GMT)
Full text and
rfc822 format available.
Message #242 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Feb 2012 18:24:25 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: josejones <at> expedia.com, 9723 <at> debbugs.gnu.org
>
> >> Scrollbars and fringes pertain to Emacs windows, not Emacs frames. What
> >> sense does it make to count them for frames?
> >
> > You need this value to communicate with the window manager and the
> > toolkit. And that value should include one scroll bar and one pair of
> > fringes, in addition to text width. Storing that value in a separate
> > struct member is a convenience device, nothing more.
>
> But in change_frame_size_1 we use "this value" to adjust the sizes of
> Emacs windows.
Of course: if the frame's size changes, the sizes of its windows need
to be adjusted. Since you surely understand that, I wonder what am I
missing here.
> Moreover, why communicate the presence of a scrollbar to the window
> manager and the toolkit?
We don't, we just communicate the total size of the frame to it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 17:53:01 GMT)
Full text and
rfc822 format available.
Message #245 received at 9723 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> No, those are the tag bits. Lisp integers have no GC bit, since they
>> are not collectable.
>>
>>> Are these always zero?
>>
>> Yes.
>
> Thanks. Is there no way to strip these when printing them from GDB
> running under Emacs?
pr works for every Lisp object.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 17:55:01 GMT)
Full text and
rfc822 format available.
Message #248 received at 9723 <at> debbugs.gnu.org (full text, mbox):
>> But in change_frame_size_1 we use "this value" to adjust the sizes of
>> Emacs windows.
>
> Of course: if the frame's size changes, the sizes of its windows need
> to be adjusted. Since you surely understand that, I wonder what am I
> missing here.
What I'm missing is just one thing: Where and why do we need the
non-total (no fringes, no scrollbars aka text portion) size of a frame?
We don't need them for adjusting windows, we don't pass it to the window
manager, ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 18:37:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> pr works for every Lisp object.
It doesn't for a structure member here.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 19:32:01 GMT)
Full text and
rfc822 format available.
Message #254 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Feb 2012 19:35:23 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, josejones <at> expedia.com,
> 9723 <at> debbugs.gnu.org
>
> > pr works for every Lisp object.
>
> It doesn't for a structure member here.
Try pp instead.
In any case, "p foo->bar" followed by "xint" should show the value.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 19:33:01 GMT)
Full text and
rfc822 format available.
Message #257 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 Feb 2012 18:53:45 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: josejones <at> expedia.com, 9723 <at> debbugs.gnu.org
>
> >> But in change_frame_size_1 we use "this value" to adjust the sizes of
> >> Emacs windows.
> >
> > Of course: if the frame's size changes, the sizes of its windows need
> > to be adjusted. Since you surely understand that, I wonder what am I
> > missing here.
>
> What I'm missing is just one thing: Where and why do we need the
> non-total (no fringes, no scrollbars aka text portion) size of a frame?
Never?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 04 Feb 2012 19:43:02 GMT)
Full text and
rfc822 format available.
Message #260 received at 9723 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> pr works for every Lisp object.
>
> It doesn't for a structure member here.
Which structure member? It only works for Lisp_Object values.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 10:41:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Try pp instead.
Doesn't work either, probably due to the fact that I'm using GDB 6.8.
> In any case, "p foo->bar" followed by "xint" should show the value.
This works. Thanks.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 10:44:01 GMT)
Full text and
rfc822 format available.
Message #266 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Which structure member?
w->total_cols
> It only works for Lisp_Object values.
That is a Lisp_Object.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 11:02:01 GMT)
Full text and
rfc822 format available.
Message #269 received at 9723 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> Which structure member?
>
> w->total_cols
>
>> It only works for Lisp_Object values.
>
> That is a Lisp_Object.
How does it not work?
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 13:18:01 GMT)
Full text and
rfc822 format available.
Message #272 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> How does it not work?
pr doesn't print anything. p followed by xint does.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 13:49:02 GMT)
Full text and
rfc822 format available.
Message #275 received at 9723 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> How does it not work?
>
> pr doesn't print anything.
It does, to stderr of the inferior.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 16:24:02 GMT)
Full text and
rfc822 format available.
Message #278 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 05 Feb 2012 14:16:50 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, josejones <at> expedia.com,
> 9723 <at> debbugs.gnu.org
>
> > How does it not work?
>
> pr doesn't print anything.
Ah, that is a different matter. My crystal ball says that you
attached the debugger to an already running Emacs (as opposed to
starting Emacs from GDB with "start" or "run"), is that true?
If so, then the problem is that Emacs started from runemacs.exe on
Windows doesn't have a stderr stream, and as Andreas points out, pp,
pr, etc. output the values to Emacs's stderr (because the code that
produces these values runs inside Emacs).
If you want these commands to work, you need to start Emacs from the
command prompt, not from runemacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 18:18:01 GMT)
Full text and
rfc822 format available.
Message #281 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> It does, to stderr of the inferior.
How can I look at "stderror of the inferior" after M-x gdb?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 18:19:01 GMT)
Full text and
rfc822 format available.
Message #284 received at 9723 <at> debbugs.gnu.org (full text, mbox):
>> pr doesn't print anything.
>
> Ah, that is a different matter. My crystal ball says that you
> attached the debugger to an already running Emacs (as opposed to
> starting Emacs from GDB with "start" or "run"), is that true?
No. In a running Emacs I do M-x gdb, get a prompt and answer to it:
Run gdb (like this): gdb -i=mi c:/emacs/quickfixes/bin/emacs.exe
Hittin RET the rest of my dialogue goes like:
Current directory is c:/emacs/quickfixes/src/
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY =
TERM = emacs
(gdb) break window.c:3681
Breakpoint 3 at 0x114c6e3: file window.c, line 3681.
(gdb) run
Starting program: c:/emacs/quickfixes/bin/emacs.exe
[New thread 1496.0x704]
[New thread 1496.0x6a0]
[New thread 1496.0x474]
[New thread 1496.0x5bc]
[New thread 1496.0x598]
[New thread 1496.0x1fc]
[New thread 1496.0x1f0]
[New thread 1496.0x4c8]
[New thread 1496.0x288]
[New thread 1496.0x378]
[New thread 1496.0x2b8]
[New thread 1496.0x70c]
[New thread 1496.0x790]
[New thread 1496.0x230]
[New thread 1496.0x150]
Breakpoint 3, Fsplit_window_internal (old=52893701, total_size=116,
side=50301626, normal_size=50140399) at window.c:3681
3681 combination_limit =
(gdb) step
3689 if (WINDOW_LIVE_P (old))
(gdb) p o->parent
$1 = 50153498
(gdb) p o->total_cols
$2 = 640
(gdb) pr o->total_cols
(gdb) p o->total_cols
$3 = 640
(gdb) xint
$4 = 80
(gdb)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 05 Feb 2012 18:24:01 GMT)
Full text and
rfc822 format available.
Message #287 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 05 Feb 2012 19:16:28 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, josejones <at> expedia.com,
> 9723 <at> debbugs.gnu.org
>
> > It does, to stderr of the inferior.
>
> How can I look at "stderror of the inferior" after M-x gdb?
You can't, not on Windows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 11 Feb 2012 18:51:01 GMT)
Full text and
rfc822 format available.
Message #290 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Eli,
Emacs 24.0.92, built 1/22/2012
Getting back to the original issue, I can reproduce the clipboard crash 100% running Emacs -nw in a command prompt. Here is the thread and bt info I have right now:
[Switching to thread 51 (Thread 8980.0x1390)]#0 0x7d61c846 in ?? ()
(gdb) bt
#0 0x7d61c846 in ?? ()
#1 0x7d4d8c0d in RegisterWaitForInputIdle () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000230 in ?? ()
#3 0xffffffff in ?? ()
#4 0x00000000 in ?? ()
(gdb) t 3
[Switching to thread 3 (Thread 8980.0x2164)]#0 0x7d61c846 in ?? ()
(gdb) bt
#0 0x7d61c846 in ?? ()
#1 0x7d4d8c0d in RegisterWaitForInputIdle () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000248 in ?? ()
#3 0xffffffff in ?? ()
#4 0x00000000 in ?? ()
(gdb) t 2
[Switching to thread 2 (Thread 8980.0x1b48)]#0 0x7d61d06f in ?? ()
(gdb) bt
#0 0x7d61d06f in ?? ()
#1 0x7d63f948 in ?? ()
#2 0x7d4dfe37 in KERNEL32!GetConsoleOutputCP () from C:\WINDOWS\syswow64\kernel32.dll
#3 0x00000000 in ?? ()
(gdb) t 1
[Switching to thread 1 (Thread 8980.0x2040)]#0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
1491 term.c: No such file or directory.
in term.c
(gdb) bt
#0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
#1 0x0125a221 in produce_glyphs (it=0x82ad3c) at term.c:1576
#2 0x0125bb74 in produce_special_glyphs (it=0x82b604, what=IT_TRUNCATION) at term.c:1946
#3 0x0120dc3d in insert_left_trunc_glyphs (it=0x82c890) at xdisp.c:17934
#4 0x012125ec in display_line (it=0x82c890) at xdisp.c:19369
#5 0x01207dba in try_window (window=54815237, pos=..., flags=1) at xdisp.c:15955
#6 0x012059da in redisplay_window (window=54815237, just_this_one_p=0) at xdisp.c:15480
#7 0x011ff611 in redisplay_window_0 (window=54815237) at xdisp.c:13603
#8 0x01032c47 in internal_condition_case_1 (bfun=0x11ff5de <redisplay_window_0>, arg=54815237, handlers=54725470,
hfun=0x11ff5bd <redisplay_window_error>) at eval.c:1537
#9 0x011ff5a4 in redisplay_windows (window=54815237) at xdisp.c:13583
#10 0x011fda72 in redisplay_internal () at xdisp.c:13160
#11 0x011feab7 in redisplay_preserve_echo_area (from_where=12) at xdisp.c:13411
#12 0x0104bd28 in wait_reading_process_output (time_limit=60, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54741018,
wait_proc=0x0, just_wait_proc=0) at process.c:4854
#13 0x010f87ce in sit_for (timeout=240, reading=1, do_display=1) at dispnew.c:6060
#14 0x010091b1 in read_char (commandflag=1, nmaps=6, maps=0x82f9a0, prev_event=54741018, used_mouse_menu=0x82fa88,
end_time=0x0) at keyboard.c:2688
#15 0x0101c1d2 in read_key_sequence (keybuf=0x82fc04, bufsize=30, prompt=54741018, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9300
#16 0x01005c17 in command_loop_1 () at keyboard.c:1448
#17 0x01032b5f in internal_condition_case (bfun=0x100561f <command_loop_1>, handlers=54798746, hfun=0x1004e3e <cmd_error>)
at eval.c:1499
#18 0x0100527b in command_loop_2 (ignore=54741018) at keyboard.c:1159
#19 0x01032582 in internal_catch (tag=54796770, func=0x1005257 <command_loop_2>, arg=54741018) at eval.c:1256
#20 0x01005237 in command_loop () at keyboard.c:1138
#21 0x01004813 in recursive_edit_1 () at keyboard.c:758
#22 0x01004b2e in Frecursive_edit () at keyboard.c:822
#23 0x01002839 in main (argc=2, argv=0xb04a28) at emacs.c:1715
(gdb)
I realize this doesn't say anything about clipboard, but if I run it without GDB attached, that is the error alert box I get.
---------------------------
Emacs Clipboard: emacs.exe - Application Error
---------------------------
The exception unknown software exception (0xc0000005) occurred in the application at location 0x01259f9f.
Click on OK to terminate the program
Click on CANCEL to debug the program
---------------------------
OK Cancel
---------------------------
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Sunday, February 05, 2012 10:22 AM
To: martin rudalics
Cc: schwab <at> linux-m68k.org; Joseph Jones; 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> Date: Sun, 05 Feb 2012 19:16:28 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, josejones <at> expedia.com,
> 9723 <at> debbugs.gnu.org
>
> > It does, to stderr of the inferior.
>
> How can I look at "stderror of the inferior" after M-x gdb?
You can't, not on Windows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 11 Feb 2012 19:09:01 GMT)
Full text and
rfc822 format available.
Message #293 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Another data point with this build:
1) In GUI mode (I think mostly when connected over RDP), eventually Emacs will lock up using 12.5% CPU and not even running it under GDB will let me break into the process to see what is up.
24 is almost useless for me right now, at least when working remotely (which I have to do to connected to some of my machines). It would suck to have to abandon Emacs on Windows. I have NEVER had Emacs crash on any other platform in almost 20 years of usage (really lucky I guess) but the last 5 months have seen it almost unusable. :-(
-----Original Message-----
From: Joseph Jones
Sent: Saturday, February 11, 2012 10:49 AM
To: 'Eli Zaretskii'
Cc: 9723 <at> debbugs.gnu.org
Subject: RE: bug#9723: 24.0.50; Emacs Clipboard crash
Eli,
Emacs 24.0.92, built 1/22/2012
Getting back to the original issue, I can reproduce the clipboard crash 100% running Emacs -nw in a command prompt. Here is the thread and bt info I have right now:
[Switching to thread 51 (Thread 8980.0x1390)]#0 0x7d61c846 in ?? ()
(gdb) bt
#0 0x7d61c846 in ?? ()
#1 0x7d4d8c0d in RegisterWaitForInputIdle () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000230 in ?? ()
#3 0xffffffff in ?? ()
#4 0x00000000 in ?? ()
(gdb) t 3
[Switching to thread 3 (Thread 8980.0x2164)]#0 0x7d61c846 in ?? ()
(gdb) bt
#0 0x7d61c846 in ?? ()
#1 0x7d4d8c0d in RegisterWaitForInputIdle () from C:\WINDOWS\syswow64\kernel32.dll
#2 0x00000248 in ?? ()
#3 0xffffffff in ?? ()
#4 0x00000000 in ?? ()
(gdb) t 2
[Switching to thread 2 (Thread 8980.0x1b48)]#0 0x7d61d06f in ?? ()
(gdb) bt
#0 0x7d61d06f in ?? ()
#1 0x7d63f948 in ?? ()
#2 0x7d4dfe37 in KERNEL32!GetConsoleOutputCP () from C:\WINDOWS\syswow64\kernel32.dll
#3 0x00000000 in ?? ()
(gdb) t 1
[Switching to thread 1 (Thread 8980.0x2040)]#0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
1491 term.c: No such file or directory.
in term.c
(gdb) bt
#0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
#1 0x0125a221 in produce_glyphs (it=0x82ad3c) at term.c:1576
#2 0x0125bb74 in produce_special_glyphs (it=0x82b604, what=IT_TRUNCATION) at term.c:1946
#3 0x0120dc3d in insert_left_trunc_glyphs (it=0x82c890) at xdisp.c:17934
#4 0x012125ec in display_line (it=0x82c890) at xdisp.c:19369
#5 0x01207dba in try_window (window=54815237, pos=..., flags=1) at xdisp.c:15955
#6 0x012059da in redisplay_window (window=54815237, just_this_one_p=0) at xdisp.c:15480
#7 0x011ff611 in redisplay_window_0 (window=54815237) at xdisp.c:13603
#8 0x01032c47 in internal_condition_case_1 (bfun=0x11ff5de <redisplay_window_0>, arg=54815237, handlers=54725470,
hfun=0x11ff5bd <redisplay_window_error>) at eval.c:1537
#9 0x011ff5a4 in redisplay_windows (window=54815237) at xdisp.c:13583
#10 0x011fda72 in redisplay_internal () at xdisp.c:13160
#11 0x011feab7 in redisplay_preserve_echo_area (from_where=12) at xdisp.c:13411
#12 0x0104bd28 in wait_reading_process_output (time_limit=60, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54741018,
wait_proc=0x0, just_wait_proc=0) at process.c:4854
#13 0x010f87ce in sit_for (timeout=240, reading=1, do_display=1) at dispnew.c:6060
#14 0x010091b1 in read_char (commandflag=1, nmaps=6, maps=0x82f9a0, prev_event=54741018, used_mouse_menu=0x82fa88,
end_time=0x0) at keyboard.c:2688
#15 0x0101c1d2 in read_key_sequence (keybuf=0x82fc04, bufsize=30, prompt=54741018, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9300
#16 0x01005c17 in command_loop_1 () at keyboard.c:1448
#17 0x01032b5f in internal_condition_case (bfun=0x100561f <command_loop_1>, handlers=54798746, hfun=0x1004e3e <cmd_error>)
at eval.c:1499
#18 0x0100527b in command_loop_2 (ignore=54741018) at keyboard.c:1159
#19 0x01032582 in internal_catch (tag=54796770, func=0x1005257 <command_loop_2>, arg=54741018) at eval.c:1256
#20 0x01005237 in command_loop () at keyboard.c:1138
#21 0x01004813 in recursive_edit_1 () at keyboard.c:758
#22 0x01004b2e in Frecursive_edit () at keyboard.c:822
#23 0x01002839 in main (argc=2, argv=0xb04a28) at emacs.c:1715
(gdb)
I realize this doesn't say anything about clipboard, but if I run it without GDB attached, that is the error alert box I get.
---------------------------
Emacs Clipboard: emacs.exe - Application Error
---------------------------
The exception unknown software exception (0xc0000005) occurred in the application at location 0x01259f9f.
Click on OK to terminate the program
Click on CANCEL to debug the program
---------------------------
OK Cancel
---------------------------
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Sunday, February 05, 2012 10:22 AM
To: martin rudalics
Cc: schwab <at> linux-m68k.org; Joseph Jones; 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> Date: Sun, 05 Feb 2012 19:16:28 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, josejones <at> expedia.com,
> 9723 <at> debbugs.gnu.org
>
> > It does, to stderr of the inferior.
>
> How can I look at "stderror of the inferior" after M-x gdb?
You can't, not on Windows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 11 Feb 2012 19:22:01 GMT)
Full text and
rfc822 format available.
Message #296 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 10:48:52 -0800
>
> Emacs 24.0.92, built 1/22/2012
>
> Getting back to the original issue, I can reproduce the clipboard
> crash 100% running Emacs -nw in a command prompt.
Reproduce how? What is the recipe for reproducing this?
> #0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
In this frame #0 of thread 1, what do the following commands produce?
(gdb) print glyph
(gdb) print i
(gdb) print it->area
(gdb) print it->glyph_row->used[it->area]
> I realize this doesn't say anything about clipboard
Not only, that, but also the -nw session doesn't even access the
clipboard.
> ---------------------------
> Emacs Clipboard: emacs.exe - Application Error
> ---------------------------
> The exception unknown software exception (0xc0000005) occurred in the application at location 0x01259f9f.
Where does this message come from? Do you perhaps have some
clipboard-related utility installed that is not part of the default
Windows configuration?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 11 Feb 2012 19:27:01 GMT)
Full text and
rfc822 format available.
Message #299 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 11:06:51 -0800
>
> Another data point with this build:
>
> 1) In GUI mode (I think mostly when connected over RDP), eventually Emacs will lock up using 12.5% CPU and not even running it under GDB will let me break into the process to see what is up.
If you run it not under GDB, then attaching GDB to it ("gdb -p PID",
where PID is the process ID of the running Emacs) should interrupt
whatever it is doing and let you examine the call-stack backtrace.
Are you saying that this is not working?
Anyway, can it be that you have C source files loaded in that Emacs,
and you have JIT stealth font-lock enabled? There are some problems
in C mode in that area at the moment (I had similar lockups myself),
so perhaps this is what you are hitting.
> 24 is almost useless for me right now, at least when working remotely (which I have to do to connected to some of my machines). It would suck to have to abandon Emacs on Windows. I have NEVER had Emacs crash on any other platform in almost 20 years of usage (really lucky I guess) but the last 5 months have seen it almost unusable. :-(
I'm sorry for your trouble. I can only say that no one else reported
anything similar for this version. You can always go back to Emacs 23
if you find this unbearable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 11 Feb 2012 19:46:02 GMT)
Full text and
rfc822 format available.
Message #302 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 11 Feb 2012 21:19:22 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 9723 <at> debbugs.gnu.org
>
> > I realize this doesn't say anything about clipboard
>
> Not only, that, but also the -nw session doesn't even access the
> clipboard.
>
> > ---------------------------
> > Emacs Clipboard: emacs.exe - Application Error
> > ---------------------------
> > The exception unknown software exception (0xc0000005) occurred in the application at location 0x01259f9f.
>
> Where does this message come from? Do you perhaps have some
> clipboard-related utility installed that is not part of the default
> Windows configuration?
Can you try disabling the "clipboard redirection" between your local
and remote machines? This page:
http://technet.microsoft.com/en-us/library/bb457106.aspx
has the details about disabling that (search for "Disabling Clipboard
Redirection").
Maybe this sharing is something Emacs doesn't live well with.
Still, if you have a recipe for reproducing this crash, and the data I
requested from the GDB session, please give those as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 01:53:01 GMT)
Full text and
rfc822 format available.
Message #305 received at 9723 <at> debbugs.gnu.org (full text, mbox):
*** inline
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Saturday, February 11, 2012 11:19 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 10:48:52 -0800
>
> Emacs 24.0.92, built 1/22/2012
>
> Getting back to the original issue, I can reproduce the clipboard
> crash 100% running Emacs -nw in a command prompt.
Reproduce how? What is the recipe for reproducing this?
*** Open Emacs in an NT cmd shell prompt. In Emacs, open up a cmd shell prompt. Start something that will cause a huge amount of text and scrolling. I run a build in the command prompt and then just wait for it to crash.
> #0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
In this frame #0 of thread 1, what do the following commands produce?
(gdb) print glyph
(gdb) print i
(gdb) print it->area
(gdb) print it->glyph_row->used[it->area]
***
(gdb) f 0
#0 0x01259f9f in append_glyph (it=0x82acec) at term.c:1491
1491 in term.c
(gdb) print glyph
$1 = (struct glyph *) 0x0
(gdb) print i
$2 = 0
(gdb) print it->area
$3 = LEFT_MARGIN_AREA
(gdb) print it->glyph_row->used[it->area]
$4 = 0
(gdb)
***
> I realize this doesn't say anything about clipboard
Not only, that, but also the -nw session doesn't even access the clipboard.
> ---------------------------
> Emacs Clipboard: emacs.exe - Application Error
> ---------------------------
> The exception unknown software exception (0xc0000005) occurred in the application at location 0x01259f9f.
Where does this message come from? Do you perhaps have some clipboard-related utility installed that is not part of the default Windows configuration?
*** That is the UI based alert that pops up on a crash when the debugger is not attached. I have EmacsW32 installed here for Emacs23 but I am not suing that and I have no global path pointing to that installation. There is nothing in my service list that shows as Emacs either except the application itself.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 01:54:02 GMT)
Full text and
rfc822 format available.
Message #308 received at 9723 <at> debbugs.gnu.org (full text, mbox):
***inline
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Saturday, February 11, 2012 11:25 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 11:06:51 -0800
>
> Another data point with this build:
>
> 1) In GUI mode (I think mostly when connected over RDP), eventually Emacs will lock up using 12.5% CPU and not even running it under GDB will let me break into the process to see what is up.
If you run it not under GDB, then attaching GDB to it ("gdb -p PID", where PID is the process ID of the running Emacs) should interrupt whatever it is doing and let you examine the call-stack backtrace.
Are you saying that this is not working?
*** I haven't tried attaching, But if I start Emacs within GDB then I run into the issue above.
Anyway, can it be that you have C source files loaded in that Emacs, and you have JIT stealth font-lock enabled? There are some problems in C mode in that area at the moment (I had similar lockups myself), so perhaps this is what you are hitting.
*** Well, since I do all C/C++ programming then that could be it. I'd hate to have to disable C-mode though...
> 24 is almost useless for me right now, at least when working remotely
> (which I have to do to connected to some of my machines). It would
> suck to have to abandon Emacs on Windows. I have NEVER had Emacs crash
> on any other platform in almost 20 years of usage (really lucky I
> guess) but the last 5 months have seen it almost unusable. :-(
I'm sorry for your trouble. I can only say that no one else reported anything similar for this version. You can always go back to Emacs 23 if you find this unbearable.
*** 23 still repros the clipboard and I prefer 24 for other reason. Just venting, sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 02:10:02 GMT)
Full text and
rfc822 format available.
Message #311 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Well, it was a nice thought but disabling clipboard didn't resolve the issue. :-(
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Saturday, February 11, 2012 11:44 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> Date: Sat, 11 Feb 2012 21:19:22 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 9723 <at> debbugs.gnu.org
>
> > I realize this doesn't say anything about clipboard
>
> Not only, that, but also the -nw session doesn't even access the
> clipboard.
>
> > ---------------------------
> > Emacs Clipboard: emacs.exe - Application Error
> > ---------------------------
> > The exception unknown software exception (0xc0000005) occurred in the application at location 0x01259f9f.
>
> Where does this message come from? Do you perhaps have some
> clipboard-related utility installed that is not part of the default
> Windows configuration?
Can you try disabling the "clipboard redirection" between your local and remote machines? This page:
http://technet.microsoft.com/en-us/library/bb457106.aspx
has the details about disabling that (search for "Disabling Clipboard Redirection").
Maybe this sharing is something Emacs doesn't live well with.
Still, if you have a recipe for reproducing this crash, and the data I requested from the GDB session, please give those as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 16:42:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 17:50:41 -0800
>
> *** Open Emacs in an NT cmd shell prompt. In Emacs, open up a cmd shell prompt. Start something that will cause a huge amount of text and scrolling. I run a build in the command prompt and then just wait for it to crash.
Any estimation of the length of output that is needed to have a crash?
Also, would just "type LARGE_SOME_FILE" do, for example?
> > #0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
>
> In this frame #0 of thread 1, what do the following commands produce?
>
> (gdb) print glyph
> (gdb) print i
> (gdb) print it->area
> (gdb) print it->glyph_row->used[it->area]
>
> ***
> (gdb) f 0
> #0 0x01259f9f in append_glyph (it=0x82acec) at term.c:1491
> 1491 in term.c
> (gdb) print glyph
> $1 = (struct glyph *) 0x0
> (gdb) print i
> $2 = 0
> (gdb) print it->area
> $3 = LEFT_MARGIN_AREA
This doesn't make any sense. Maybe again some snafu with frame
dimensions?
Please type "source .gdbinit" (unless you started GDB from a directory
where that file lives), and then go to this frame:
#4 0x012125ec in display_line (it=0x82c890) at xdisp.c:19369
and type these commands:
(gdb) pit
(gdb) print *it->w
(gdb) pmtxrows it->w->current_matrix
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 16:45:02 GMT)
Full text and
rfc822 format available.
Message #317 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 17:52:26 -0800
>
> > 24 is almost useless for me right now, at least when working remotely
> > (which I have to do to connected to some of my machines). It would
> > suck to have to abandon Emacs on Windows. I have NEVER had Emacs crash
> > on any other platform in almost 20 years of usage (really lucky I
> > guess) but the last 5 months have seen it almost unusable. :-(
>
> I'm sorry for your trouble. I can only say that no one else reported anything similar for this version. You can always go back to Emacs 23 if you find this unbearable.
>
> *** 23 still repros the clipboard and I prefer 24 for other reason. Just venting, sorry.
Did everything you reported for this bug happened when Emacs was used
in Remote Desktop, or did something happen in a "normal" local
session? If the latter, could you please identify the crashes that
happened locally?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 20:07:01 GMT)
Full text and
rfc822 format available.
Message #320 received at 9723 <at> debbugs.gnu.org (full text, mbox):
I have something better for you now that I can repro this reliably.
1) Make sure you have a text file > 6500 (do 7000 just to be sure) lines with lines > width of the display (i.e. would wrap normally)
2) Put ONLY this in your .emacs
;; linum
(setq-default truncate-lines t)
(require 'linum)
(global-linum-mode 1)
3) Open up a cmd shell and run Emacs -nw
4) M-x shell
5) run "type (your file from 1)"
Should crash around 6500 lines every time. Note this is on Win Server 2003 sp2 64bit running in a 64bit command shell.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Sunday, February 12, 2012 8:40 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 17:50:41 -0800
>
> *** Open Emacs in an NT cmd shell prompt. In Emacs, open up a cmd shell prompt. Start something that will cause a huge amount of text and scrolling. I run a build in the command prompt and then just wait for it to crash.
Any estimation of the length of output that is needed to have a crash?
Also, would just "type LARGE_SOME_FILE" do, for example?
> > #0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
>
> In this frame #0 of thread 1, what do the following commands produce?
>
> (gdb) print glyph
> (gdb) print i
> (gdb) print it->area
> (gdb) print it->glyph_row->used[it->area]
>
> ***
> (gdb) f 0
> #0 0x01259f9f in append_glyph (it=0x82acec) at term.c:1491
> 1491 in term.c
> (gdb) print glyph
> $1 = (struct glyph *) 0x0
> (gdb) print i
> $2 = 0
> (gdb) print it->area
> $3 = LEFT_MARGIN_AREA
This doesn't make any sense. Maybe again some snafu with frame dimensions?
Please type "source .gdbinit" (unless you started GDB from a directory where that file lives), and then go to this frame:
#4 0x012125ec in display_line (it=0x82c890) at xdisp.c:19369
and type these commands:
(gdb) pit
(gdb) print *it->w
(gdb) pmtxrows it->w->current_matrix
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 20:08:01 GMT)
Full text and
rfc822 format available.
Message #323 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Oh yeah, this was all in a remote desktop session. I am not at the office to see if this repros in a local session. That will have to wait till tomorrow at earliest.
-----Original Message-----
From: Joseph Jones
Sent: Sunday, February 12, 2012 12:05 PM
To: 'Eli Zaretskii'
Cc: 9723 <at> debbugs.gnu.org
Subject: RE: bug#9723: 24.0.50; Emacs Clipboard crash
I have something better for you now that I can repro this reliably.
1) Make sure you have a text file > 6500 (do 7000 just to be sure) lines with lines > width of the display (i.e. would wrap normally)
2) Put ONLY this in your .emacs
;; linum
(setq-default truncate-lines t)
(require 'linum)
(global-linum-mode 1)
3) Open up a cmd shell and run Emacs -nw
4) M-x shell
5) run "type (your file from 1)"
Should crash around 6500 lines every time. Note this is on Win Server 2003 sp2 64bit running in a 64bit command shell.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Sunday, February 12, 2012 8:40 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 17:50:41 -0800
>
> *** Open Emacs in an NT cmd shell prompt. In Emacs, open up a cmd shell prompt. Start something that will cause a huge amount of text and scrolling. I run a build in the command prompt and then just wait for it to crash.
Any estimation of the length of output that is needed to have a crash?
Also, would just "type LARGE_SOME_FILE" do, for example?
> > #0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
>
> In this frame #0 of thread 1, what do the following commands produce?
>
> (gdb) print glyph
> (gdb) print i
> (gdb) print it->area
> (gdb) print it->glyph_row->used[it->area]
>
> ***
> (gdb) f 0
> #0 0x01259f9f in append_glyph (it=0x82acec) at term.c:1491
> 1491 in term.c
> (gdb) print glyph
> $1 = (struct glyph *) 0x0
> (gdb) print i
> $2 = 0
> (gdb) print it->area
> $3 = LEFT_MARGIN_AREA
This doesn't make any sense. Maybe again some snafu with frame dimensions?
Please type "source .gdbinit" (unless you started GDB from a directory where that file lives), and then go to this frame:
#4 0x012125ec in display_line (it=0x82c890) at xdisp.c:19369
and type these commands:
(gdb) pit
(gdb) print *it->w
(gdb) pmtxrows it->w->current_matrix
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 21:08:01 GMT)
Full text and
rfc822 format available.
Message #326 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sun, 12 Feb 2012 12:05:32 -0800
>
> Oh yeah, this was all in a remote desktop session. I am not at the office to see if this repros in a local session. That will have to wait till tomorrow at earliest.
FWIW, I cannot reproduce the crash with your recipe on my machine (in
a local session).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sun, 12 Feb 2012 22:15:02 GMT)
Full text and
rfc822 format available.
Message #329 received at 9723 <at> debbugs.gnu.org (full text, mbox):
(gdb) pit
cur=635852 pos=0 start=634607 end=6 stop=6 face=13 nov=1 sp=2 ch=' ' next=GET_FROM_STRING[0]
BIDI: base_stop=0 prev_stop=0 level=0
vpos=47 hpos=121 y=47 lvy=57 x=624 vx=503-624 w=1 a+d=0+1=1 max=0+1=1
stack[0]: GET_FROM_BUFFER[635851]
stack[1]: GET_FROM_STRING[1]
56: edges=(632703,632714),r2l=0,cont=0,trunc=(0,0),at_zv=1
(gdb) print *it->w
$2 = {
header = {
size = 1073745975,
next = {
buffer = 0x3446c00,
vector = 0x3446c00
}
},
frame = 54815749,
mini_p = 54741018,
next = 54814725,
prev = 54741018,
hchild = 54741018,
vchild = 54741018,
parent = 54741018,
left_col = 0,
top_line = 4,
total_lines = 232,
total_cols = 512,
normal_lines = 54727727,
normal_cols = 54727735,
new_total = 232,
new_normal = 54741018,
buffer = 94267397,
start = 54769715,
pointm = 54769739,
force_start = 54741018,
optional_new_start = 54741018,
hscroll = 2012,
min_hscroll = 0,
use_time = 1292,
sequence_number = 4,
temslot = 0,
last_modified = 0,
last_overlay_modified = 0,
last_point = 2530856,
last_had_star = 54741042,
vertical_scroll_bar = 54741018,
left_margin_cols = 24,
right_margin_cols = 54741018,
left_fringe_width = 54741018,
right_fringe_width = 54741018,
fringes_outside_margins = 54741018,
scroll_bar_width = 54741018,
vertical_scroll_bar_type = 54741042,
last_mark_x = 54741018,
last_mark_y = 54741018,
window_end_pos = 0,
window_end_vpos = 224,
window_end_valid = 54741018,
update_mode_line = 54741042,
start_at_line_beg = 54741042,
display_table = 54741018,
dedicated = 54741018,
base_line_number = 25244,
base_line_pos = 2486108,
region_showing = 54741018,
column_number_displayed = 54741018,
redisplay_end_trigger = 54741018,
combination_limit = 54741018,
prev_buffers = 94427926,
next_buffers = 54741018,
window_parameters = 94427958,
current_matrix = 0x3714f80,
desired_matrix = 0x3714000,
nrows_scale_factor = 1,
ncols_scale_factor = 1,
last_cursor = {
x = 11,
y = 56,
hpos = 11,
vpos = 56
},
cursor = {
x = 122,
y = 56,
hpos = 122,
vpos = -1
},
phys_cursor = {
x = 0,
y = 0,
hpos = 0,
vpos = 0
},
phys_cursor_type = -1,
phys_cursor_width = -1,
phys_cursor_ascent = 0,
phys_cursor_height = 0,
phys_cursor_on_p = 0,
cursor_off_p = 0,
last_cursor_off_p = 0,
must_be_updated_p = 0,
pseudo_window_p = 0,
frozen_window_start_p = 0,
vscroll = 0,
window_end_bytepos = 0
}
(gdb)
(gdb) pmtxrows it->w->current_matrix
0: edges=(628376,628438),r2l=0,cont=0,trunc=(0,0),at_zv=0
1: edges=(628438,628457),r2l=0,cont=0,trunc=(0,0),at_zv=0
2: edges=(628457,628483),r2l=0,cont=0,trunc=(0,0),at_zv=0
3: edges=(628483,628524),r2l=0,cont=0,trunc=(0,0),at_zv=0
4: edges=(628524,628679),r2l=0,cont=0,trunc=(0,1),at_zv=0
5: edges=(628679,628743),r2l=0,cont=0,trunc=(0,0),at_zv=0
6: edges=(628743,628812),r2l=0,cont=0,trunc=(0,0),at_zv=0
7: edges=(628812,628853),r2l=0,cont=0,trunc=(0,0),at_zv=0
8: edges=(628853,629015),r2l=0,cont=0,trunc=(0,1),at_zv=0
9: edges=(629015,629082),r2l=0,cont=0,trunc=(0,0),at_zv=0
10: edges=(629082,629154),r2l=0,cont=0,trunc=(0,0),at_zv=0
11: edges=(629154,629195),r2l=0,cont=0,trunc=(0,0),at_zv=0
12: edges=(629195,629364),r2l=0,cont=0,trunc=(0,1),at_zv=0
13: edges=(629364,629435),r2l=0,cont=0,trunc=(0,0),at_zv=0
14: edges=(629435,629511),r2l=0,cont=0,trunc=(0,0),at_zv=0
15: edges=(629511,629578),r2l=0,cont=0,trunc=(0,0),at_zv=0
16: edges=(629578,629596),r2l=0,cont=0,trunc=(0,0),at_zv=0
17: edges=(629596,629627),r2l=0,cont=0,trunc=(0,0),at_zv=0
18: edges=(629627,629668),r2l=0,cont=0,trunc=(0,0),at_zv=0
19: edges=(629668,629834),r2l=0,cont=0,trunc=(0,1),at_zv=0
20: edges=(629834,629902),r2l=0,cont=0,trunc=(0,0),at_zv=0
21: edges=(629902,629975),r2l=0,cont=0,trunc=(0,0),at_zv=0
22: edges=(629975,630016),r2l=0,cont=0,trunc=(0,0),at_zv=0
23: edges=(630016,630178),r2l=0,cont=0,trunc=(0,1),at_zv=0
24: edges=(630178,630245),r2l=0,cont=0,trunc=(0,0),at_zv=0
25: edges=(630245,630317),r2l=0,cont=0,trunc=(0,0),at_zv=0
26: edges=(630317,630395),r2l=0,cont=0,trunc=(0,0),at_zv=0
27: edges=(630395,630413),r2l=0,cont=0,trunc=(0,0),at_zv=0
28: edges=(630413,630455),r2l=0,cont=0,trunc=(0,0),at_zv=0
29: edges=(630455,630496),r2l=0,cont=0,trunc=(0,0),at_zv=0
30: edges=(630496,630679),r2l=0,cont=0,trunc=(0,1),at_zv=0
31: edges=(630679,630758),r2l=0,cont=0,trunc=(0,0),at_zv=0
32: edges=(630758,630842),r2l=0,cont=0,trunc=(0,0),at_zv=0
33: edges=(630842,630883),r2l=0,cont=0,trunc=(0,0),at_zv=0
34: edges=(630883,631041),r2l=0,cont=0,trunc=(0,1),at_zv=0
35: edges=(631041,631106),r2l=0,cont=0,trunc=(0,0),at_zv=0
36: edges=(631106,631176),r2l=0,cont=0,trunc=(0,0),at_zv=0
37: edges=(631176,631217),r2l=0,cont=0,trunc=(0,0),at_zv=0
38: edges=(631217,631362),r2l=0,cont=0,trunc=(0,1),at_zv=0
39: edges=(631362,631425),r2l=0,cont=0,trunc=(0,0),at_zv=0
40: edges=(631425,631493),r2l=0,cont=0,trunc=(0,0),at_zv=0
41: edges=(631493,631534),r2l=0,cont=0,trunc=(0,0),at_zv=0
42: edges=(631534,631693),r2l=0,cont=0,trunc=(0,1),at_zv=0
43: edges=(631693,631734),r2l=0,cont=0,trunc=(0,0),at_zv=0
44: edges=(631734,631888),r2l=0,cont=0,trunc=(0,1),at_zv=0
45: edges=(631888,631958),r2l=0,cont=0,trunc=(0,0),at_zv=0
46: edges=(631958,632033),r2l=0,cont=0,trunc=(0,0),at_zv=0
47: edges=(632033,632074),r2l=0,cont=0,trunc=(0,0),at_zv=0
48: edges=(632074,632232),r2l=0,cont=0,trunc=(0,1),at_zv=0
49: edges=(632232,632306),r2l=0,cont=0,trunc=(0,0),at_zv=0
50: edges=(632306,632385),r2l=0,cont=0,trunc=(0,0),at_zv=0
51: edges=(632385,632426),r2l=0,cont=0,trunc=(0,0),at_zv=0
52: edges=(632426,632564),r2l=0,cont=0,trunc=(0,1),at_zv=0
53: edges=(632564,632613),r2l=0,cont=0,trunc=(0,0),at_zv=0
54: edges=(632613,632662),r2l=0,cont=0,trunc=(0,0),at_zv=0
55: edges=(632662,632703),r2l=0,cont=0,trunc=(0,0),at_zv=0
56: edges=(632703,632714),r2l=0,cont=0,trunc=(0,0),at_zv=1
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Sunday, February 12, 2012 8:40 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sat, 11 Feb 2012 17:50:41 -0800
>
> *** Open Emacs in an NT cmd shell prompt. In Emacs, open up a cmd shell prompt. Start something that will cause a huge amount of text and scrolling. I run a build in the command prompt and then just wait for it to crash.
Any estimation of the length of output that is needed to have a crash?
Also, would just "type LARGE_SOME_FILE" do, for example?
> > #0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
>
> In this frame #0 of thread 1, what do the following commands produce?
>
> (gdb) print glyph
> (gdb) print i
> (gdb) print it->area
> (gdb) print it->glyph_row->used[it->area]
>
> ***
> (gdb) f 0
> #0 0x01259f9f in append_glyph (it=0x82acec) at term.c:1491
> 1491 in term.c
> (gdb) print glyph
> $1 = (struct glyph *) 0x0
> (gdb) print i
> $2 = 0
> (gdb) print it->area
> $3 = LEFT_MARGIN_AREA
This doesn't make any sense. Maybe again some snafu with frame dimensions?
Please type "source .gdbinit" (unless you started GDB from a directory where that file lives), and then go to this frame:
#4 0x012125ec in display_line (it=0x82c890) at xdisp.c:19369
and type these commands:
(gdb) pit
(gdb) print *it->w
(gdb) pmtxrows it->w->current_matrix
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 13 Feb 2012 18:02:02 GMT)
Full text and
rfc822 format available.
Message #332 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Here is the thread stack trace for the active thread see when Emacs gui hangs at 12.5% CPU:
(gdb) bt
#0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
#1 0x7d6671e1 in ntdll!RtlUshortByteSwap () from C:\WINDOWS\system32\ntdll.dll
#2 0x00000000 in ?? ()
Lisp Backtrace:
"parse-partial-sexp" (0x82d0b4)
"c-in-literal" (0x82d3b4)
"c-at-macro-vsemi-p" (0x82d6a4)
"c-beginning-of-statement-1" (0x82d9f4)
"byte-code" (0x82dc54)
"c-beginning-of-decl-1" (0x82e094)
"c-set-fl-decl-start" (0x82e384)
"c-change-set-fl-decl-start" (0x82e674)
0x6153320 PVEC_COMPILED
"mapc" (0x82eac4)
"c-after-change" (0x82ee78)
"comment-region-internal" (0x82f2e0)
"comment-region-default" (0x82f600)
"comment-region" (0x82f944)
"call-interactively" (0x82fb74)
Is this the c-mode issue you were talking about?
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Sunday, February 12, 2012 1:06 PM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sun, 12 Feb 2012 12:05:32 -0800
>
> Oh yeah, this was all in a remote desktop session. I am not at the office to see if this repros in a local session. That will have to wait till tomorrow at earliest.
FWIW, I cannot reproduce the crash with your recipe on my machine (in a local session).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 13 Feb 2012 18:18:01 GMT)
Full text and
rfc822 format available.
Message #335 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 13 Feb 2012 09:59:48 -0800
>
> Here is the thread stack trace for the active thread see when Emacs gui hangs at 12.5% CPU:
>
> (gdb) bt
> #0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
> #1 0x7d6671e1 in ntdll!RtlUshortByteSwap () from C:\WINDOWS\system32\ntdll.dll
> #2 0x00000000 in ?? ()
>
> Lisp Backtrace:
> "parse-partial-sexp" (0x82d0b4)
> "c-in-literal" (0x82d3b4)
> "c-at-macro-vsemi-p" (0x82d6a4)
> "c-beginning-of-statement-1" (0x82d9f4)
> "byte-code" (0x82dc54)
> "c-beginning-of-decl-1" (0x82e094)
> "c-set-fl-decl-start" (0x82e384)
> "c-change-set-fl-decl-start" (0x82e674)
> 0x6153320 PVEC_COMPILED
> "mapc" (0x82eac4)
> "c-after-change" (0x82ee78)
> "comment-region-internal" (0x82f2e0)
> "comment-region-default" (0x82f600)
> "comment-region" (0x82f944)
> "call-interactively" (0x82fb74)
>
> Is this the c-mode issue you were talking about?
Yes. See the patches in bugs #10664 and #10792. You can find them
here:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-02/msg00420.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-02/msg00476.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 13 Feb 2012 18:20:02 GMT)
Full text and
rfc822 format available.
Message #338 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Cool. I assume these will be in an upcoming release at the ftp point you pointed me to earlier?
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, February 13, 2012 10:16 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 13 Feb 2012 09:59:48 -0800
>
> Here is the thread stack trace for the active thread see when Emacs gui hangs at 12.5% CPU:
>
> (gdb) bt
> #0 0x7d61002e in strchr () from C:\WINDOWS\system32\ntdll.dll
> #1 0x7d6671e1 in ntdll!RtlUshortByteSwap () from
> C:\WINDOWS\system32\ntdll.dll
> #2 0x00000000 in ?? ()
>
> Lisp Backtrace:
> "parse-partial-sexp" (0x82d0b4)
> "c-in-literal" (0x82d3b4)
> "c-at-macro-vsemi-p" (0x82d6a4)
> "c-beginning-of-statement-1" (0x82d9f4) "byte-code" (0x82dc54)
> "c-beginning-of-decl-1" (0x82e094) "c-set-fl-decl-start" (0x82e384)
> "c-change-set-fl-decl-start" (0x82e674)
> 0x6153320 PVEC_COMPILED
> "mapc" (0x82eac4)
> "c-after-change" (0x82ee78)
> "comment-region-internal" (0x82f2e0)
> "comment-region-default" (0x82f600)
> "comment-region" (0x82f944)
> "call-interactively" (0x82fb74)
>
> Is this the c-mode issue you were talking about?
Yes. See the patches in bugs #10664 and #10792. You can find them
here:
http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-02/msg00420.html
http://lists.gnu.org/archive/html/bug-gnu-emacs/2012-02/msg00476.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 13 Feb 2012 18:37:01 GMT)
Full text and
rfc822 format available.
Message #341 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 13 Feb 2012 10:17:26 -0800
>
> Cool. I assume these will be in an upcoming release at the ftp point you pointed me to earlier?
Yes. But you can apply the patches even now, byte-compile the 2 *.el
files involved, and restart Emacs, to get rid of those hangs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 13 Feb 2012 18:44:01 GMT)
Full text and
rfc822 format available.
Message #344 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Awesome, thanx.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, February 13, 2012 10:35 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 13 Feb 2012 10:17:26 -0800
>
> Cool. I assume these will be in an upcoming release at the ftp point you pointed me to earlier?
Yes. But you can apply the patches even now, byte-compile the 2 *.el files involved, and restart Emacs, to get rid of those hangs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Sat, 18 Feb 2012 17:20:02 GMT)
Full text and
rfc822 format available.
Message #347 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sun, 12 Feb 2012 14:13:18 -0800
>
> (gdb) pit
> cur=635852 pos=0 start=634607 end=6 stop=6 face=13 nov=1 sp=2 ch=' ' next=GET_FROM_STRING[0]
> BIDI: base_stop=0 prev_stop=0 level=0
> vpos=47 hpos=121 y=47 lvy=57 x=624 vx=503-624 w=1 a+d=0+1=1 max=0+1=1
> stack[0]: GET_FROM_BUFFER[635851]
> stack[1]: GET_FROM_STRING[1]
>
> 56: edges=(632703,632714),r2l=0,cont=0,trunc=(0,0),at_zv=1
> (gdb) print *it->w
> $2 = {
> header = {
> size = 1073745975,
> next = {
> buffer = 0x3446c00,
> vector = 0x3446c00
> }
> },
> frame = 54815749,
> mini_p = 54741018,
> next = 54814725,
> prev = 54741018,
> hchild = 54741018,
> vchild = 54741018,
> parent = 54741018,
> left_col = 0,
> top_line = 4,
> total_lines = 232,
> total_cols = 512,
OK. What about this command? what does it display?
(gdb) p it->glyph_row->glyphs
Please do this in the following stack frame of the crash backtrace:
#0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Mon, 20 Feb 2012 17:23:01 GMT)
Full text and
rfc822 format available.
Message #350 received at 9723 <at> debbugs.gnu.org (full text, mbox):
If I can get another crash I can look into that. However, since patching cc-mode and removing truncate I haven't seen this. I want to update to latest 24 build (93) and then I can try to look into it some more.
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Saturday, February 18, 2012 9:16 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Sun, 12 Feb 2012 14:13:18 -0800
>
> (gdb) pit
> cur=635852 pos=0 start=634607 end=6 stop=6 face=13 nov=1 sp=2 ch=' ' next=GET_FROM_STRING[0]
> BIDI: base_stop=0 prev_stop=0 level=0
> vpos=47 hpos=121 y=47 lvy=57 x=624 vx=503-624 w=1 a+d=0+1=1 max=0+1=1
> stack[0]: GET_FROM_BUFFER[635851]
> stack[1]: GET_FROM_STRING[1]
>
> 56: edges=(632703,632714),r2l=0,cont=0,trunc=(0,0),at_zv=1
> (gdb) print *it->w
> $2 = {
> header = {
> size = 1073745975,
> next = {
> buffer = 0x3446c00,
> vector = 0x3446c00
> }
> },
> frame = 54815749,
> mini_p = 54741018,
> next = 54814725,
> prev = 54741018,
> hchild = 54741018,
> vchild = 54741018,
> parent = 54741018,
> left_col = 0,
> top_line = 4,
> total_lines = 232,
> total_cols = 512,
OK. What about this command? what does it display?
(gdb) p it->glyph_row->glyphs
Please do this in the following stack frame of the crash backtrace:
#0 0x01259f9f in append_glyph (it=0x82ad3c) at term.c:1491
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 03 Apr 2012 17:18:01 GMT)
Full text and
rfc822 format available.
Message #353 received at 9723 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It appears that pretest build 95 still isn't patched. Any ideas when these will be fixed?
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, February 13, 2012 10:35 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Mon, 13 Feb 2012 10:17:26 -0800
>
> Cool. I assume these will be in an upcoming release at the ftp point you pointed me to earlier?
Yes. But you can apply the patches even now, byte-compile the 2 *.el files involved, and restart Emacs, to get rid of those hangs.
[winmail.dat (application/ms-tnef, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 03 Apr 2012 18:06:02 GMT)
Full text and
rfc822 format available.
Message #356 received at 9723 <at> debbugs.gnu.org (full text, mbox):
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Tue, 3 Apr 2012 10:17:05 -0700
>
> It appears that pretest build 95 still isn't patched. Any ideas when these will be fixed?
These patches are in, see
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10664#50
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10792#38
If you still see the same problems in the latest pretest, please
report them as bugs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#9723; Package
emacs.
(Tue, 03 Apr 2012 18:16:02 GMT)
Full text and
rfc822 format available.
Message #359 received at 9723 <at> debbugs.gnu.org (full text, mbox):
Interesting as the diff of the patched cc-engine file in 92 and the unpatched file in 95 appear to show that the patch isn't in. Then again, applying the patch to the 95 file failed. I do know that both 93 and 94 experienced the same issues as pre-patched 92. It will be a few days till I can test unpatched 95 since I need to wait for a time when crashing emacs will not cause me serious downtime.
Thanx,
Joe
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Tuesday, April 03, 2012 11:05 AM
To: Joseph Jones
Cc: 9723 <at> debbugs.gnu.org
Subject: Re: bug#9723: 24.0.50; Emacs Clipboard crash
> From: Joseph Jones <josejones <at> expedia.com>
> CC: "9723 <at> debbugs.gnu.org" <9723 <at> debbugs.gnu.org>
> Date: Tue, 3 Apr 2012 10:17:05 -0700
>
> It appears that pretest build 95 still isn't patched. Any ideas when these will be fixed?
These patches are in, see
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10664#50
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10792#38
If you still see the same problems in the latest pretest, please report them as bugs.
bug closed, send any further explanations to
9723 <at> debbugs.gnu.org and Joseph Jones <josejones <at> expedia.com>
Request was from
Chong Yidong <cyd <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 14 Jul 2012 01:43:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 11 Aug 2012 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 13 years and 7 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.