I can try to get some more out of GDB, but I really think the problem is
that
EDE is blowing the stack with a recursive call. Perhaps Emacs should be
killing anything that does exceed a stack limit.
I am not sure what you mean by killing. Emacs has a limit on stack size,
and
Eli sent you some suggestions for how to proceed in debugging this.
Is there any progress? And does the bug still happen?
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
On Sunday 05 June 2005 16:26, Richard Stallman wrote:
Eli sent you some suggestions for how to proceed in debugging this.
Is there any progress? And does the bug still happen?
I can try to get some more out of GDB, but I really think the problem is that
EDE is blowing the stack with a
From: Steven T. Hatton [EMAIL PROTECTED]
Date: Sun, 5 Jun 2005 18:05:03 -0400
Cc: emacs-pretest-bug@gnu.org
I can try to get some more out of GDB, but I really think the problem is that
EDE is blowing the stack with a recursive call.
To see if this is the case, compare inside GDB the
Steven T. Hatton [EMAIL PROTECTED] writes:
The attached file contains the top and bottom of a Lisp backtrace I got from
C-g, after enabling enter debugger on quit.
Indeed it looks like a loop/recursion bug in EDE.
So can we conclude that emacs does not _crash_ ?
--
Kim F. Storm [EMAIL
The attached file contains the top and bottom of a Lisp backtrace I got from
C-g, after enabling enter debugger on quit.
Indeed it looks like a loop/recursion bug in EDE.
So can we conclude that emacs does not _crash_ ?
And since C-g works as well, it's not frozen.
I.e. it's not an Emacs
Steven T. Hatton [EMAIL PROTECTED] writes:
The backtrace I get when I type bt is 84000+ lines. I'm not sure that's what
you want.
Nor am I sure how to provide it, if it is what you want. I've been trying
to familiarize
myself with gdb lately, but I am very much a novice.
What does
The backtrace I get when I type bt is 84000+ lines.
When? If Emacs seems to hang, it means it's stuck in an (almost-)inf-loop,
and you can try stopping it a few times and compare the backtraces.
The one you show was taken from within the GC, which always leads to such
long lists of
On Tuesday 31 May 2005 08:33, Stefan Monnier wrote:
The backtrace I get when I type bt is 84000+ lines.
When? If Emacs seems to hang, it means it's stuck in an (almost-)inf-loop,
and you can try stopping it a few times and compare the backtraces.
The one you show was taken from within the
On Sunday 29 May 2005 09:32, Stefan Monnier wrote:
This is the output from gdb:
as i586-suse-linux...Using host libthread_db library
/lib/tls/libthread_db.so.1. (gdb) run
Have you tried with -q --no-site-file?
Stefan
Sorry about not following up on this. I tried to find out
On Monday 30 May 2005 17:21, Stefan Monnier wrote:
This is the output from gdb:
as i586-suse-linux...Using host libthread_db library
/lib/tls/libthread_db.so.1. (gdb) run
Have you tried with -q --no-site-file?
Sorry about not following up on this. I tried to find out where the
From: Steven T. Hatton [EMAIL PROTECTED]
Date: Mon, 30 May 2005 18:47:27 -0400
The first anomaly appears at line 2146:
#2142 0x08130380 in mark_object (arg=139610081) at
/download/org/gnu/emacs/emacs/src/alloc.c:5316
#2143 0x08130508 in mark_object (arg=138258477) at
Would you please send us the text of the file that is needed to
reproduce this problem?
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
This is the output from gdb:
as i586-suse-linux...Using host libthread_db library
/lib/tls/libthread_db.so.1.
(gdb) run
Have you tried with -q --no-site-file?
Stefan
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
Symptoms:
C-x C-f
/download/org/kdevelop/repository/root/kdevelop/parts/astyle/astyleconfig.h
Where kdevelop/parts/astyle/astyleconfig.h is from the KDevelop source
repository. The file is never displayed in the buffer, and Emacs
appears to be locked up with the exception tht some text may
15 matches
Mail list logo
