* Re: is there a cygwin maintainer for gnu emacs?
2005-08-09 18:15 ` Joe Buehler
@ 2005-08-10 10:47 ` emacs user
2005-08-10 11:37 ` Joe Buehler
2005-08-16 8:47 ` stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?) emacs user
` (2 subsequent siblings)
3 siblings, 1 reply; 22+ messages in thread
From: emacs user @ 2005-08-10 10:47 UTC (permalink / raw)
Cc: emacs-devel, cygwin
>From: Joe Buehler <jbuehler@spirentcom.com>
>1. Run emacs under gdb and see if you can get a stack backtrace
>from gdb after emacs dies. It will depend on how emacs dies
>whether you can do this.
>
>2. Failing that, run strace on emacs and send me the output (say,
>the last couple thousand lines) after it dies. I may be able to
>deduce something from that.
>--
>Joe Buehler
>
here is a backtrace on a sample emacs crash under cygwin; let me know if I
can provide additional info. this is not easily reproducible (involves my
.emacs file and happens quite randomly), but such crashes occur often enough
that I can try and print useful information if you can direct me.
/usr/local/emacs/src $ gdb emacs
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x2009a5e6: file emacs.c, line 461.
Breakpoint 2 at 0x2007d83c: file xterm.c, line 7795.
(gdb) run
Starting program: /usr/local/emacs/src/emacs.exe -geometry 80x40+0+0
---Type <return> to continue, or q <return> to quit---
Breakpoint 1, abort () at emacs.c:461
461 kill (getpid (), SIGABRT);
(gdb) xbacktrace
(gdb) backtrace
#0 abort () at emacs.c:461
#1 0x200ed181 in mark_object (arg=536986839) at alloc.c:5468
#2 0x200edaff in Fgarbage_collect () at alloc.c:4810
#3 0x20101cfe in Feval (form=583791917) at eval.c:2101
#4 0x20100788 in internal_condition_case_1 (bfun=0x201019c0 <Feval>,
arg=583791917, handlers=539863641,
hfun=0x200a06c0 <menu_item_eval_property_1>) at eval.c:1493
#5 0x200a0752 in menu_item_eval_property (sexpr=583791917) at
keyboard.c:7152
#6 0x200acb7e in get_keyelt (object=540049153, autoload=1) at keymap.c:811
#7 0x200ad1d3 in access_keymap (map=539822333, idx=539845257, t_ok=2,
noinherit=0, autoload=1) at keymap.c:643
#8 0x200a13dc in tool_bar_items (reuse=601188356, nitems=0x22dcf8)
at keyboard.c:7609
#9 0x2001c6bf in update_tool_bar (f=0x20cc4600, save_match_data=0)
at xdisp.c:8857
#10 0x2002a4d0 in prepare_menu_bars () at xdisp.c:8563
#11 0x2002a8e6 in redisplay_internal (preserve_echo_area=7) at xdisp.c:10245
#12 0x200a4bf1 in read_char (commandflag=1, nmaps=2, maps=0x22e930,
prev_event=539791361, used_mouse_menu=0x22e978) at keyboard.c:2541
#13 0x200a75c7 in read_key_sequence (keybuf=0x22ead0, bufsize=30,
prompt=539791361, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8818
#14 0x200a90d1 in command_loop_1 () at keyboard.c:1529
#15 0x20100a82 in internal_condition_case (bfun=0x200a8f30 <command_loop_1>,
---Type <return> to continue, or q <return> to quit---
handlers=539863641, hfun=0x200a2a90 <cmd_error>) at eval.c:1452
#16 0x2009cc2e in command_loop_2 () at keyboard.c:1319
#17 0x2010098f in internal_catch (tag=539852761,
func=0x2009cc00 <command_loop_2>, arg=539791361) at eval.c:1211
#18 0x2009ca13 in command_loop () at keyboard.c:1298
#19 0x2009cab4 in recursive_edit_1 () at keyboard.c:991
#20 0x2009cbc0 in Frecursive_edit () at keyboard.c:1052
#21 0x2009bf0d in main (argc=3, argv=0x202c25c0) at emacs.c:1782
(gdb) where
#0 abort () at emacs.c:461
#1 0x200ed181 in mark_object (arg=536986839) at alloc.c:5468
#2 0x200edaff in Fgarbage_collect () at alloc.c:4810
#3 0x20101cfe in Feval (form=583791917) at eval.c:2101
#4 0x20100788 in internal_condition_case_1 (bfun=0x201019c0 <Feval>,
arg=583791917, handlers=539863641,
hfun=0x200a06c0 <menu_item_eval_property_1>) at eval.c:1493
#5 0x200a0752 in menu_item_eval_property (sexpr=583791917) at
keyboard.c:7152
#6 0x200acb7e in get_keyelt (object=540049153, autoload=1) at keymap.c:811
#7 0x200ad1d3 in access_keymap (map=539822333, idx=539845257, t_ok=2,
noinherit=0, autoload=1) at keymap.c:643
#8 0x200a13dc in tool_bar_items (reuse=601188356, nitems=0x22dcf8)
at keyboard.c:7609
#9 0x2001c6bf in update_tool_bar (f=0x20cc4600, save_match_data=0)
at xdisp.c:8857
#10 0x2002a4d0 in prepare_menu_bars () at xdisp.c:8563
#11 0x2002a8e6 in redisplay_internal (preserve_echo_area=7) at xdisp.c:10245
#12 0x200a4bf1 in read_char (commandflag=1, nmaps=2, maps=0x22e930,
prev_event=539791361, used_mouse_menu=0x22e978) at keyboard.c:2541
#13 0x200a75c7 in read_key_sequence (keybuf=0x22ead0, bufsize=30,
prompt=539791361, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8818
#14 0x200a90d1 in command_loop_1 () at keyboard.c:1529
#15 0x20100a82 in internal_condition_case (bfun=0x200a8f30 <command_loop_1>,
---Type <return> to continue, or q <return> to quit---
handlers=539863641, hfun=0x200a2a90 <cmd_error>) at eval.c:1452
#16 0x2009cc2e in command_loop_2 () at keyboard.c:1319
#17 0x2010098f in internal_catch (tag=539852761,
func=0x2009cc00 <command_loop_2>, arg=539791361) at eval.c:1211
#18 0x2009ca13 in command_loop () at keyboard.c:1298
#19 0x2009cab4 in recursive_edit_1 () at keyboard.c:991
#20 0x2009cbc0 in Frecursive_edit () at keyboard.c:1052
#21 0x2009bf0d in main (argc=3, argv=0x202c25c0) at emacs.c:1782
(gdb) quit
The program is running. Exit anyway? (y or n) y
/usr/local/emacs/src $
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: is there a cygwin maintainer for gnu emacs?
2005-08-10 10:47 ` emacs user
@ 2005-08-10 11:37 ` Joe Buehler
2005-08-10 17:56 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Joe Buehler @ 2005-08-10 11:37 UTC (permalink / raw)
Cc: ehud, emacs-devel, cygwin
emacs user wrote:
> (gdb) backtrace
> #0 abort () at emacs.c:461
> #1 0x200ed181 in mark_object (arg=536986839) at alloc.c:5468
> #2 0x200edaff in Fgarbage_collect () at alloc.c:4810
> #3 0x20101cfe in Feval (form=583791917) at eval.c:2101
Ugh -- the emacs garbage collector encountered something it didn't like
and intentionally aborted emacs. If you run this in a console window
do you get any messages? I would think that emacs would say why it
is aborting.
Is there an expert on the emacs internals that would care to comment
on what this abort might mean?
--
Joe Buehler
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: is there a cygwin maintainer for gnu emacs?
2005-08-10 11:37 ` Joe Buehler
@ 2005-08-10 17:56 ` Eli Zaretskii
2005-08-10 20:18 ` emacs user
2005-08-11 14:27 ` Richard M. Stallman
0 siblings, 2 replies; 22+ messages in thread
From: Eli Zaretskii @ 2005-08-10 17:56 UTC (permalink / raw)
Cc: emacs_user, cygwin, emacs-devel
> Date: Wed, 10 Aug 2005 07:37:43 -0400
> From: Joe Buehler <jbuehler@spirentcom.com>
> Cc: ehud@unix.mvs.co.il, cygwin@cygwin.com, emacs-devel@gnu.org
>
> I would think that emacs would say why it is aborting.
When GC encounters a fatal inconsistency in the Emacs data structures,
it is generally unsafe to say anything, since that could easily cause
a nested fatal signal.
> Is there an expert on the emacs internals that would care to comment
> on what this abort might mean?
I'm not sure I'm such an expert on this, but the file etc/DEBUG has a
special section on debugging crashes inside GC. I don't think there's
a general recipe, one just needs to follow the advice in etc/DEBUG and
find out the corrupted data structure. Once the bad data structure is
found, the next step is to trace its life cycle and find what piece of
code corrupted it.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: is there a cygwin maintainer for gnu emacs?
2005-08-10 17:56 ` Eli Zaretskii
@ 2005-08-10 20:18 ` emacs user
2005-08-11 3:37 ` Eli Zaretskii
2005-08-11 14:27 ` Richard M. Stallman
1 sibling, 1 reply; 22+ messages in thread
From: emacs user @ 2005-08-10 20:18 UTC (permalink / raw)
Cc: cygwin, emacs-devel
I guess my question as a fairly naive user is who will bedoing that GC
debugging. I am happy to check things in gdb following instructions from
one of you experts...
>From: Eli Zaretskii <eliz@gnu.org>
> > Date: Wed, 10 Aug 2005 07:37:43 -0400
> > From: Joe Buehler <jbuehler@spirentcom.com>
> > Cc: ehud@unix.mvs.co.il, cygwin@cygwin.com, emacs-devel@gnu.org
> >
> > I would think that emacs would say why it is aborting.
>
>When GC encounters a fatal inconsistency in the Emacs data structures,
>it is generally unsafe to say anything, since that could easily cause
>a nested fatal signal.
>
> > Is there an expert on the emacs internals that would care to comment
> > on what this abort might mean?
>
>I'm not sure I'm such an expert on this, but the file etc/DEBUG has a
>special section on debugging crashes inside GC. I don't think there's
>a general recipe, one just needs to follow the advice in etc/DEBUG and
>find out the corrupted data structure. Once the bad data structure is
>found, the next step is to trace its life cycle and find what piece of
>code corrupted it.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: is there a cygwin maintainer for gnu emacs?
2005-08-10 20:18 ` emacs user
@ 2005-08-11 3:37 ` Eli Zaretskii
0 siblings, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2005-08-11 3:37 UTC (permalink / raw)
Cc: jbuehler, cygwin, emacs-devel
> From: "emacs user" <emacs_user@hotmail.com>
> Cc: cygwin@cygwin.com, emacs-devel@gnu.org
> Date: Wed, 10 Aug 2005 16:18:20 -0400
>
> I guess my question as a fairly naive user is who will bedoing that GC
> debugging.
Someone who can reproduce the problem. If that's only you, then you
will have to do the debugging.
> I am happy to check things in gdb following instructions from
> one of you experts...
Like I said: the instructions are in etc/DEBUG. We can help interpret
the results, if you cannot figure them out, but there's no sense for
us to repeat what's already in etc/DEBUG before you post some more
information using the methodology described there.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: is there a cygwin maintainer for gnu emacs?
2005-08-10 17:56 ` Eli Zaretskii
2005-08-10 20:18 ` emacs user
@ 2005-08-11 14:27 ` Richard M. Stallman
2005-08-11 15:12 ` Joe Buehler
2005-08-11 17:17 ` emacs user
1 sibling, 2 replies; 22+ messages in thread
From: Richard M. Stallman @ 2005-08-11 14:27 UTC (permalink / raw)
Cc: jbuehler, emacs_user, cygwin, emacs-devel
When GC encounters a fatal inconsistency in the Emacs data structures,
it is generally unsafe to say anything, since that could easily cause
a nested fatal signal.
It would also not be very useful, since any info we could put into
such an error message could be quickly discovered by a little
investigation with a debugger.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: is there a cygwin maintainer for gnu emacs?
2005-08-11 14:27 ` Richard M. Stallman
@ 2005-08-11 15:12 ` Joe Buehler
2005-08-12 14:59 ` Richard M. Stallman
2005-08-11 17:17 ` emacs user
1 sibling, 1 reply; 22+ messages in thread
From: Joe Buehler @ 2005-08-11 15:12 UTC (permalink / raw)
Cc: Eli Zaretskii, emacs_user, cygwin, emacs-devel
Richard M. Stallman wrote:
> When GC encounters a fatal inconsistency in the Emacs data structures,
> it is generally unsafe to say anything, since that could easily cause
> a nested fatal signal.
>
> It would also not be very useful, since any info we could put into
> such an error message could be quickly discovered by a little
> investigation with a debugger.
I have to disgree with that, it's the instant gut ueber-programmer
reaction to such problems. Currently the user just gets an exiting
emacs, leaving me with no clue as to why emacs exited. I then have to
provide instructions to the user as to how to run the $*&$%#!!! debugger
to help me figure out what happened. The debugger that he may or may
not have installed, and may or may not even be ABLE to install.
A simple last-ditch printf that says "corruption detected during
garbage collection, see you later" would be a much easier way to get an
initial handle on what the heck the problem is. As it was, without any
message, my initial suspicion was a SEGV or similar, which would be
much more likely to be a Cygwin problem than an emacs problem.
--
Joe Buehler
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: is there a cygwin maintainer for gnu emacs?
2005-08-11 15:12 ` Joe Buehler
@ 2005-08-12 14:59 ` Richard M. Stallman
2005-08-12 17:02 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Richard M. Stallman @ 2005-08-12 14:59 UTC (permalink / raw)
Cc: eliz, emacs-devel, emacs_user, cygwin
I have to disgree with that, it's the instant gut ueber-programmer
reaction to such problems. Currently the user just gets an exiting
emacs, leaving me with no clue as to why emacs exited.
It crashed. It has a bug. What more is there to say?
I then have to
provide instructions to the user as to how to run the $*&$%#!!! debugger
to help me figure out what happened. The debugger that he may or may
not have installed, and may or may not even be ABLE to install.
Printing a message would not change this situation. Debugging the bug
will always require doing these things, and if they can't be done, the
bug can't be debugged.
A simple last-ditch printf that says "corruption detected during
garbage collection, see you later" would be a much easier way to get an
initial handle on what the heck the problem is.
How would such a message have helped anyone? Practically speaking, I
don't see how it would change anything.
As it was, without any
message, my initial suspicion was a SEGV or similar, which would be
much more likely to be a Cygwin problem than an emacs problem.
Until the bug is debugged, we know nothing about where the cause lies.
The fact that it manifested itself in this way, that it was GC where the
bug bit, really tells us nothing.
That is why a message would not really help. The visible details of
the crash tell us nothing about its cause. It was caused by a long
chain of events, and we know nothing about where it started. Any
feeling you might get, from such a message, that you know what's going
on would be a false feeling.
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: is there a cygwin maintainer for gnu emacs?
2005-08-12 14:59 ` Richard M. Stallman
@ 2005-08-12 17:02 ` Eli Zaretskii
0 siblings, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2005-08-12 17:02 UTC (permalink / raw)
Cc: jbuehler, emacs-devel, emacs_user, cygwin
> From: "Richard M. Stallman" <rms@gnu.org>
> CC: eliz@gnu.org, emacs-devel@gnu.org, emacs_user@hotmail.com,
> cygwin@cygwin.com
> Date: Fri, 12 Aug 2005 10:59:49 -0400
>
> As it was, without any
> message, my initial suspicion was a SEGV or similar, which would be
> much more likely to be a Cygwin problem than an emacs problem.
>
> Until the bug is debugged, we know nothing about where the cause lies.
That's true, but it should have been clear that it's not a SEGV, since
Emacs says something like "Abort (core dumped)", which clearly tells
that it got SIGABRT, not SIGSEGV.
So, while Emacs doesn't say that it happened within GC, it does tell
that it committed suicide (aborted), not hit a SIGSEGV.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: is there a cygwin maintainer for gnu emacs?
2005-08-11 14:27 ` Richard M. Stallman
2005-08-11 15:12 ` Joe Buehler
@ 2005-08-11 17:17 ` emacs user
1 sibling, 0 replies; 22+ messages in thread
From: emacs user @ 2005-08-11 17:17 UTC (permalink / raw)
Cc: jbuehler, cygwin, emacs-devel
can someone please just tell me what to do in the debugger to try and
diagnose the problem? the DEBUG text was not useful to me. I am happy to
work on this, but I am afraid I need very explicit gdb instructions.
thanks... Eli
>From: "Richard M. Stallman" <rms@gnu.org>
>Reply-To: rms@gnu.org
>To: Eli Zaretskii <eliz@gnu.org>
>CC: jbuehler@spirentcom.com, emacs_user@hotmail.com,cygwin@cygwin.com,
>emacs-devel@gnu.org
>Subject: Re: is there a cygwin maintainer for gnu emacs?
>Date: Thu, 11 Aug 2005 10:27:11 -0400
>
> When GC encounters a fatal inconsistency in the Emacs data structures,
> it is generally unsafe to say anything, since that could easily cause
> a nested fatal signal.
>
>It would also not be very useful, since any info we could put into
>such an error message could be quickly discovered by a little
>investigation with a debugger.
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
^ permalink raw reply [flat|nested] 22+ messages in thread
* stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?)
2005-08-09 18:15 ` Joe Buehler
2005-08-10 10:47 ` emacs user
@ 2005-08-16 8:47 ` emacs user
2005-08-16 9:05 ` Brian Dessent
2005-08-17 4:09 ` Eli Zaretskii
2005-08-18 6:45 ` is there a cygwin maintainer for gnu emacs? emacs user
2005-08-28 20:57 ` emacs user
3 siblings, 2 replies; 22+ messages in thread
From: emacs user @ 2005-08-16 8:47 UTC (permalink / raw)
Cc: emacs-devel, cygwin, eliz, ehud
here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
absence of a detailed gdb GC debugging which I dont know how to do, does
this help?
Exception: STATUS_ACCESS_VIOLATION at eip=610C4974
eax=21121CB8 ebx=80000014 ecx=20000005 edx=00000000 esi=A1121CC8
edi=A315B51C
ebp=0022AF4C esp=0022AF40 program=C:\cygwin\usr\local\emacs\src\emacs.exe,
pid 2804, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0022AF4C 610C4974 (2315B50C, 21121CB8, 80000014, 200EBA35)
0022AFFC 201090F2 (00000003, 00000000, 00000000, 00000002)
0022B01C 20109495 (2113F033, 7C9155C9, 0022B158, 00002DD3)
0022B13C 200FBE8A (00000002, 0022B1D8, 7C9167A4, 0022B1C0)
0022B1AC 20102D35 (00000003, 0022B1D4, 20E96508, 00000000)
0022B24C 2012E75D (2113F003, 21111484, 00000030, 21134599)
0022B28C 20102607 (0022B314, 7C91056D, 00254E58, 00254E38)
0022B2FC 20102A9B (00000003, 0022B310, 00000008, 21134599)
0022B36C 20104247 (00000002, 0022B3A4, 7C91056D, 00000000)
0022B39C 20104371 (21134599, 218F75A5, 0022B4EC, 20100788)
0022B3AC 2013448D (218F75AD, 0022B314, 00000000, 00240198)
0022B4EC 20100788 (20134470, 218F75AD, 202DAA59, 20135750)
0022B52C 201345F5 (21140E04, 0022B560, 0022B564, 0022B568)
0022B5AC 2013594A (202E09E1, 218F7585, 00000001, 211BB4ED)
0022B5CC 201382A2 (21140E04, 00000001, 0022B5EC, 00000AF4)
0022B5EC 20138387 (202C9001, 00000000, 10000000, 0000000B)
End of stack trace (more stack frames may be present)
>From: Joe Buehler <jbuehler@spirentcom.com>
>Reply-To: jbuehler@spirentcom.com
>To: ehud@unix.mvs.co.il
>CC: emacs_user@hotmail.com, emacs-devel@gnu.org, cygwin@cygwin.com
>Subject: Re: is there a cygwin maintainer for gnu emacs?
>Date: Tue, 09 Aug 2005 14:15:39 -0400
>
>On Tue, 09 Aug 2005 01:08:36 -0400, emacs user <emacs_user@hotmail.com>
>wrote:
>
> >>
> >> Ehud, thnx for the reply; I didn't do any rebasing (don't know what
>that
> >> is), and the problem is that emacs crashes about every 5 minutes,
>mostly in
> >> latex mode when I use the combination of auctex/preview/x-symbol. very
> >> painful... I don't have any such difficulties when using precisely
>the
> >> same combination under linux.
> >>
>
>1. Run emacs under gdb and see if you can get a stack backtrace
>from gdb after emacs dies. It will depend on how emacs dies
>whether you can do this.
>
>2. Failing that, run strace on emacs and send me the output (say,
>the last couple thousand lines) after it dies. I may be able to
>deduce something from that.
>--
>Joe Buehler
>
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?)
2005-08-16 8:47 ` stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?) emacs user
@ 2005-08-16 9:05 ` Brian Dessent
2005-08-17 4:09 ` Eli Zaretskii
1 sibling, 0 replies; 22+ messages in thread
From: Brian Dessent @ 2005-08-16 9:05 UTC (permalink / raw)
Cc: jbuehler, emacs-devel
emacs user wrote:
> here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
> absence of a detailed gdb GC debugging which I dont know how to do, does
> this help?
I don't know anything about emacs, but I don't think this will help
anyone find the problem. A stack trace without symbols (i.e. just
numbers) contains no useable information. And since it appears that you
are running a self-compiled version (in /usr/local) then it is even more
useless since your offsets are going to be unique.
It would be better for you to set the error_start parameter of the
CYGWIN environment variable so that gdb is launched on the fault, and
get a stack backtrace. Though this will suffer from the same problem
unless you've compiled from source with debugging information enabled.
A backtrace with symbolic function names and/or line numbers is really
the only useful form.
Brian
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?)
2005-08-16 8:47 ` stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?) emacs user
2005-08-16 9:05 ` Brian Dessent
@ 2005-08-17 4:09 ` Eli Zaretskii
1 sibling, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2005-08-17 4:09 UTC (permalink / raw)
Cc: jbuehler, cygwin, emacs-devel
> From: "emacs user" <emacs_user@hotmail.com>
> Bcc:
> Date: Tue, 16 Aug 2005 04:47:39 -0400
> Cc: cygwin@cygwin.com, ehud@unix.mvs.co.il, eliz@gnu.org, emacs-devel@gnu.org
>
> here is a sample emacs.exe.stackdump file I get when emacs crashes. in the
> absence of a detailed gdb GC debugging which I dont know how to do, does
> this help?
It doesn't. You need to get an Emacs compiled with -g and not
stripped, then run it under GDB, and when it crashes, type "bt", the
GDB command that shows the function call traceback.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: is there a cygwin maintainer for gnu emacs?
2005-08-09 18:15 ` Joe Buehler
2005-08-10 10:47 ` emacs user
2005-08-16 8:47 ` stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?) emacs user
@ 2005-08-18 6:45 ` emacs user
2005-08-19 8:38 ` Eli Zaretskii
2005-08-28 20:57 ` emacs user
3 siblings, 1 reply; 22+ messages in thread
From: emacs user @ 2005-08-18 6:45 UTC (permalink / raw)
Cc: emacs-devel, cygwin
some more diagnostics of the GC problem, with the help of some advice from
eliz. does this help?
>From: Joe Buehler <jbuehler@spirentcom.com>
>Reply-To: jbuehler@spirentcom.com
>To: ehud@unix.mvs.co.il
>CC: emacs_user@hotmail.com, emacs-devel@gnu.org, cygwin@cygwin.com
>Subject: Re: is there a cygwin maintainer for gnu emacs?
>Date: Tue, 09 Aug 2005 14:15:39 -0400
>
>On Tue, 09 Aug 2005 01:08:36 -0400, emacs user <emacs_user@hotmail.com>
>wrote:
>
> >>
> >> Ehud, thnx for the reply; I didn't do any rebasing (don't know what
>that
> >> is), and the problem is that emacs crashes about every 5 minutes,
>mostly in
> >> latex mode when I use the combination of auctex/preview/x-symbol. very
> >> painful... I don't have any such difficulties when using precisely
>the
> >> same combination under linux.
> >>
>
>1. Run emacs under gdb and see if you can get a stack backtrace
>from gdb after emacs dies. It will depend on how emacs dies
>whether you can do this.
>
>2. Failing that, run strace on emacs and send me the output (say,
>the last couple thousand lines) after it dies. I may be able to
>deduce something from that.
>--
>Joe Buehler
>
/usr/local/emacs/src $ gdb emacs
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x2009a626: file emacs.c, line 461.
Breakpoint 2 at 0x2007d87c: file xterm.c, line 7795.
(gdb) run
Starting program: /usr/local/emacs/src/emacs.exe -geometry 80x40+0+0
---Type <return> to continue, or q <return> to quit---
Breakpoint 1, abort () at emacs.c:461
461 kill (getpid (), SIGABRT);
(gdb) where
#0 abort () at emacs.c:461
#1 0x200ed1c1 in mark_object (arg=536986871) at alloc.c:5468
#2 0x200edb3f in Fgarbage_collect () at alloc.c:4810
#3 0x20101d3e in Feval (form=578722485) at eval.c:2101
#4 0x201007c8 in internal_condition_case_1 (bfun=0x20101a00 <Feval>,
arg=578722485, handlers=539863641,
hfun=0x200a0700 <menu_item_eval_property_1>) at eval.c:1493
#5 0x200a0792 in menu_item_eval_property (sexpr=578722485) at
keyboard.c:7152
#6 0x200acbbe in get_keyelt (object=540049153, autoload=1) at keymap.c:811
#7 0x200ad213 in access_keymap (map=539822333, idx=539845257, t_ok=2,
noinherit=0, autoload=1) at keymap.c:643
#8 0x200a141c in tool_bar_items (reuse=578739204, nitems=0x22db18)
at keyboard.c:7609
#9 0x2001c6df in update_tool_bar (f=0x20cc4600, save_match_data=0)
at xdisp.c:8863
#10 0x2002a500 in prepare_menu_bars () at xdisp.c:8569
#11 0x2002a916 in redisplay_internal (preserve_echo_area=7) at xdisp.c:10251
#12 0x2002b938 in redisplay_preserve_echo_area (from_where=12) at
xdisp.c:10862
#13 0x20136f29 in wait_reading_process_output (time_limit=30, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=539791361, wait_proc=0x0,
just_wait_proc=0) at process.c:4575
#14 0x20009437 in sit_for (sec=30, usec=0, reading=1, display=1,
initial_display=0) at dispnew.c:6405
#15 0x200a56ce in read_char (commandflag=1, nmaps=6, maps=0x22e920,
---Type <return> to continue, or q <return> to quit---
prev_event=539791361, used_mouse_menu=0x22e978) at keyboard.c:2769
#16 0x200a7607 in read_key_sequence (keybuf=0x22ead0, bufsize=30,
prompt=539791361, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8818
#17 0x200a9111 in command_loop_1 () at keyboard.c:1529
#18 0x20100ac2 in internal_condition_case (bfun=0x200a8f70 <command_loop_1>,
handlers=539863641, hfun=0x200a2ad0 <cmd_error>) at eval.c:1452
#19 0x2009cc6e in command_loop_2 () at keyboard.c:1319
#20 0x201009cf in internal_catch (tag=539852761,
func=0x2009cc40 <command_loop_2>, arg=539791361) at eval.c:1211
#21 0x2009ca53 in command_loop () at keyboard.c:1298
#22 0x2009caf4 in recursive_edit_1 () at keyboard.c:991
#23 0x2009cc00 in Frecursive_edit () at keyboard.c:1052
#24 0x2009bf4d in main (argc=3, argv=0x202c25c0) at emacs.c:1782
(gdb) print last_marked_index
$6 = 22
(gdb) print last_marked[22]
$7 = 539791361
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$8 = (struct Lisp_Symbol *) 0x202c9000
"nil"
(gdb)
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: is there a cygwin maintainer for gnu emacs?
2005-08-18 6:45 ` is there a cygwin maintainer for gnu emacs? emacs user
@ 2005-08-19 8:38 ` Eli Zaretskii
0 siblings, 0 replies; 22+ messages in thread
From: Eli Zaretskii @ 2005-08-19 8:38 UTC (permalink / raw)
Cc: jbuehler, ehud, cygwin, emacs-devel
> From: "emacs user" <emacs_user@hotmail.com>
> Date: Thu, 18 Aug 2005 02:45:21 -0400
> Cc: cygwin@cygwin.com, emacs-devel@gnu.org
>
> some more diagnostics of the GC problem, with the help of some advice from
> eliz. does this help?
It's a beginning. Thanks.
> Breakpoint 1, abort () at emacs.c:461
> 461 kill (getpid (), SIGABRT);
> (gdb) where
> #0 abort () at emacs.c:461
> #1 0x200ed1c1 in mark_object (arg=536986871) at alloc.c:5468
The next step is to find out what object is the argument passed to
mark_object in frame #1. This is the object that caused the abort.
Also, please send the output of the GDB command xbacktrace, it should
produce the Lisp traceback at this point (although it looks like Emacs
crashed right at startup, so the Lisp traceback will not tell anything
important).
> (gdb) print last_marked_index
> $6 = 22
> (gdb) print last_marked[22]
> $7 = 539791361
This is wrong. etc/DEBUG says:
The variable
`last_marked_index' holds the index into the `last_marked' array one
place beyond where the pointer to the very last marked object is
stored.
See that ``one place beyond'' part? So you should have said
(gdb) print last_marked[21]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: is there a cygwin maintainer for gnu emacs?
2005-08-09 18:15 ` Joe Buehler
` (2 preceding siblings ...)
2005-08-18 6:45 ` is there a cygwin maintainer for gnu emacs? emacs user
@ 2005-08-28 20:57 ` emacs user
3 siblings, 0 replies; 22+ messages in thread
From: emacs user @ 2005-08-28 20:57 UTC (permalink / raw)
Cc: emacs-devel, cygwin
some more diagnostics on the bug that causes repeated crashes under cygwin;
I'd be happy to get additional advice as to what else I can do to help
identify the source of the problem:
/usr/local/emacs/src $ gdb emacs
GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
DISPLAY = :0.0
TERM = xterm
Breakpoint 1 at 0x2009a9d6: file emacs.c, line 461.
Breakpoint 2 at 0x2007d92c: file xterm.c, line 7795.
(gdb) run
Starting program: /usr/local/emacs/src/emacs.exe -geometry 80x40+0+0
Breakpoint 1, abort () at emacs.c:461
---Type <return> to continue, or q <return> to quit---
461 kill (getpid (), SIGABRT);
(gdb) bt
#0 abort () at emacs.c:461
#1 0x200ed701 in mark_object (arg=536986903) at alloc.c:5468
#2 0x200ee07f in Fgarbage_collect () at alloc.c:4810
#3 0x2010229f in Feval (form=598803029) at eval.c:2101
#4 0x20100d28 in internal_condition_case_1 (bfun=0x20101f60 <Feval>,
arg=598803029, handlers=539867737,
hfun=0x200a0ab0 <menu_item_eval_property_1>) at eval.c:1493
#5 0x200a0b42 in menu_item_eval_property (sexpr=598803029) at
keyboard.c:7152
#6 0x200acfae in get_keyelt (object=540053249, autoload=1) at keymap.c:811
#7 0x200ad603 in access_keymap (map=539826429, idx=539849353, t_ok=2,
noinherit=0, autoload=1) at keymap.c:643
#8 0x200a17cc in tool_bar_items (reuse=598839300, nitems=0x22db38)
at keyboard.c:7609
#9 0x2001c6ff in update_tool_bar (f=0x202be400, save_match_data=0)
at xdisp.c:8877
#10 0x2002a540 in prepare_menu_bars () at xdisp.c:8583
#11 0x2002a956 in redisplay_internal (preserve_echo_area=7) at xdisp.c:10265
#12 0x2002b978 in redisplay_preserve_echo_area (from_where=12) at
xdisp.c:10876
#13 0x20137629 in wait_reading_process_output (time_limit=30, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=539795457, wait_proc=0x0,
just_wait_proc=0) at process.c:4575
#14 0x20009437 in sit_for (sec=30, usec=0, reading=1, display=1,
initial_display=0) at dispnew.c:6405
#15 0x200a5a7e in read_char (commandflag=1, nmaps=2, maps=0x22e930,
---Type <return> to continue, or q <return> to quit---
prev_event=539795457, used_mouse_menu=0x22e978) at keyboard.c:2769
#16 0x200a79b7 in read_key_sequence (keybuf=0x22ead0, bufsize=30,
prompt=539795457, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8818
#17 0x200a94e1 in command_loop_1 () at keyboard.c:1529
#18 0x20101022 in internal_condition_case (bfun=0x200a9340 <command_loop_1>,
handlers=539867737, hfun=0x200a2e80 <cmd_error>) at eval.c:1452
#19 0x2009d01e in command_loop_2 () at keyboard.c:1319
#20 0x20100f2f in internal_catch (tag=539856857,
func=0x2009cff0 <command_loop_2>, arg=539795457) at eval.c:1211
#21 0x2009ce03 in command_loop () at keyboard.c:1298
#22 0x2009cea4 in recursive_edit_1 () at keyboard.c:991
#23 0x2009cfb0 in Frecursive_edit () at keyboard.c:1052
#24 0x2009c2fd in main (argc=3, argv=0x202c35c0) at emacs.c:1782
(gdb) print last_marked_index
$1 = 389
(gdb) print last_marked[388]
$2 = 536986903
(gdb) xbt
Undefined command: "xbt". Try "help".
(gdb) xtype
Lisp_Type_Limit
(gdb) print last_marked[388]
$3 = 536986903
(gdb) xtype
Lisp_Type_Limit
(gdb)
>From: Joe Buehler <jbuehler@spirentcom.com>
>Reply-To: jbuehler@spirentcom.com
>To: ehud@unix.mvs.co.il
>CC: emacs_user@hotmail.com, emacs-devel@gnu.org, cygwin@cygwin.com
>Subject: Re: is there a cygwin maintainer for gnu emacs?
>Date: Tue, 09 Aug 2005 14:15:39 -0400
>
>On Tue, 09 Aug 2005 01:08:36 -0400, emacs user <emacs_user@hotmail.com>
>wrote:
>
> >>
> >> Ehud, thnx for the reply; I didn't do any rebasing (don't know what
>that
> >> is), and the problem is that emacs crashes about every 5 minutes,
>mostly in
> >> latex mode when I use the combination of auctex/preview/x-symbol. very
> >> painful... I don't have any such difficulties when using precisely
>the
> >> same combination under linux.
> >>
>
>1. Run emacs under gdb and see if you can get a stack backtrace
>from gdb after emacs dies. It will depend on how emacs dies
>whether you can do this.
>
>2. Failing that, run strace on emacs and send me the output (say,
>the last couple thousand lines) after it dies. I may be able to
>deduce something from that.
>--
>Joe Buehler
>
_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
^ permalink raw reply [flat|nested] 22+ messages in thread