is there a cygwin maintainer for gnu emacs?

is there a cygwin maintainer for gnu emacs?

[emacs user]

Hello, I find emacs to be very unstable under cygwin, crashing every couple 
of minures (both emacs 21.X and cvs emacs with and without gtk).  I 
submitted a few bug reports but received no reply.  I was hoping to find the 
maintainer and interact directly with her/ him.  any advice?  EU

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: is there a cygwin maintainer for gnu emacs?

[Ehud Karni]

On Mon, 08 Aug 2005 02:21:53 -0400, emacs user wrote:
>
> Hello, I find emacs to be very unstable under cygwin, crashing every couple
> of minures (both emacs 21.X and cvs emacs with and without gtk).  I
> submitted a few bug reports but received no reply.  I was hoping to find the
> maintainer and interact directly with her/ him.  any advice?  EU

AFAIK Joe Buehler is maintaining Cygwin Emacs. But may be he is not
subscribed to emacs-devel@gnu.org.

Cygwin specific Emacs problems should be discussed on cygwin@cygwin.com,
not on emacs-devel@gnu.org.

What are your problems ?

May be you did rebasing (especially rebase all) - it is known to
have a negative effect on Emacs.

I work with both Emacs 21.2 (distributed with Cygwin, prepared by
Joe Buehler) and Emacs 22.0.50 (updated from CVS and compiled on
2005-08-01), both in terminal mode and on X, and they work fine.

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: is there a cygwin maintainer for gnu emacs?

[Joe Buehler]

Ehud Karni wrote:

> AFAIK Joe Buehler is maintaining Cygwin Emacs. But may be he is not
> subscribed to emacs-devel@gnu.org.
> 
> Cygwin specific Emacs problems should be discussed on cygwin@cygwin.com,
> not on emacs-devel@gnu.org.
> 
> What are your problems ?
> 
> May be you did rebasing (especially rebase all) - it is known to
> have a negative effect on Emacs.
> 
> I work with both Emacs 21.2 (distributed with Cygwin, prepared by
> Joe Buehler) and Emacs 22.0.50 (updated from CVS and compiled on
> 2005-08-01), both in terminal mode and on X, and they work fine.

I am aware that there are some emacs problems with recent versions
of the Cygwin dll and looking at this is on my todo list.  Various
things like a newborn and major layoffs at my place of employment
have made it difficult to do anything at the moment.

GNU emacs under Cygwin has been stable for quite a while, so my initial
take is that the problem is undoubtedly due to a change in the Cygwin
dll.  Having spent lots and lots of hours tracking down various Cygwin
problems (mostly not emacs-port related) I am dreading having to look at
this particular problem.  But like I said, it is on my todo list.

If you want a stable emacs at the moment, the best advice I can give
is to stick to older versions of the Cygwin dll until such time as I
can fix this.  It's not a great situation, but normally one does not
have to debug the OS in order to maintain emacs!
-- 
Joe Buehler

Re: is there a cygwin maintainer for gnu emacs?

[emacs user]

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.

Joe Buehler's advice is to use an old cygwin version.  I was hoping for 
someone who might be interested in detailed bug reports, but perhaps this 
indeed is a cygwin issue not an emacs one...

thanks...  EU


>From: "Ehud Karni" <ehud@unix.mvs.co.il>
>
>On Mon, 08 Aug 2005 02:21:53 -0400, emacs user wrote:
> >
> > Hello, I find emacs to be very unstable under cygwin, crashing every 
>couple
> > of minures (both emacs 21.X and cvs emacs with and without gtk).  I
> > submitted a few bug reports but received no reply.  I was hoping to find 
>the
> > maintainer and interact directly with her/ him.  any advice?  EU
>
>AFAIK Joe Buehler is maintaining Cygwin Emacs. But may be he is not
>subscribed to emacs-devel@gnu.org.
>
>Cygwin specific Emacs problems should be discussed on cygwin@cygwin.com,
>not on emacs-devel@gnu.org.
>
>What are your problems ?
>
>May be you did rebasing (especially rebase all) - it is known to
>have a negative effect on Emacs.
>
>I work with both Emacs 21.2 (distributed with Cygwin, prepared by
>Joe Buehler) and Emacs 22.0.50 (updated from CVS and compiled on
>2005-08-01), both in terminal mode and on X, and they work fine.
>
>Ehud.

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: is there a cygwin maintainer for gnu emacs?

[Ehud Karni]

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.
>

What X server do you use ? If it is not the Cygwin-xfree (XWin.exe)
I suggest you try it, because I saw some problems with a commercial
X server that disappeared after switching to Cygwin's XWin.

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7966-667  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry

Re: is there a cygwin maintainer for gnu emacs?

[Joe Buehler]

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

Re: is there a cygwin maintainer for gnu emacs?

[emacs user]

>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/

Re: is there a cygwin maintainer for gnu emacs?

[Joe Buehler]

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

Re: is there a cygwin maintainer for gnu emacs?

[Eli Zaretskii]

> 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.

Re: is there a cygwin maintainer for gnu emacs?

[emacs user]

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/

Re: is there a cygwin maintainer for gnu emacs?

[Eli Zaretskii]

> 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.

Re: is there a cygwin maintainer for gnu emacs?

[Richard M. Stallman]

    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.

Re: is there a cygwin maintainer for gnu emacs?

[Joe Buehler]

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

Re: is there a cygwin maintainer for gnu emacs?

[emacs user]

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/

Re: is there a cygwin maintainer for gnu emacs?

[Richard M. Stallman]

    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.

Re: is there a cygwin maintainer for gnu emacs?

[Eli Zaretskii]

> 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.

stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?)

[emacs user]

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/

Re: stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?)

[Brian Dessent]

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

Re: stackdump on cygwin (was: is there a cygwin maintainer for gnu emacs?)

[Eli Zaretskii]

> 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.

Re: is there a cygwin maintainer for gnu emacs?

[emacs user]

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/

Re: is there a cygwin maintainer for gnu emacs?

[Eli Zaretskii]

> 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]

Re: is there a cygwin maintainer for gnu emacs?

[emacs user]

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/