* Emacs crashes accidentally
@ 2006-08-09 9:37 Herbert Euler
2006-08-10 16:27 ` Richard Stallman
0 siblings, 1 reply; 12+ messages in thread
From: Herbert Euler @ 2006-08-09 9:37 UTC (permalink / raw)
Hello,
Emacs crashed accidentally when I edited a file. I can't
reproduce that crashing, and only have a .core file in
hand. Before crashing, I wanted to undo some deletion
so I typed C-x u C-x z z z ... When some `z' was pressed,
Emacs suddenly crashed. Back trace with gdb shows:
$ gdb emacs emacs.core
GNU gdb 6.3
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 "i386-unknown-freebsd4.11"...
Core was generated by `emacs'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libutil.so.3...done.
Loaded symbols for /usr/lib/libutil.so.3
Reading symbols from /usr/lib/libncurses.so.5...done.
Loaded symbols for /usr/lib/libncurses.so.5
Reading symbols from /usr/lib/libm.so.2...done.
Loaded symbols for /usr/lib/libm.so.2
Reading symbols from /usr/lib/libc.so.4...done.
Loaded symbols for /usr/lib/libc.so.4
Reading symbols from /usr/libexec/ld-elf.so.1...done.
Loaded symbols for /usr/libexec/ld-elf.so.1
#0 0x211c8104 in kill () from /usr/lib/libc.so.4
(gdb) bt
#0 0x211c8104 in kill () from /usr/lib/libc.so.4
#1 0x01059900 in fatal_error_signal (sig=11) at emacs.c:430
#2 <signal handler called>
#3 0x010c10b3 in strout (ptr=0x2469648 <Address 0x2469648 out of bounds>,
size=27, size_byte=27, printcharfun=19413041,
multibyte=0) at print.c:417
#4 0x010c1385 in print_string (string=37526819, printcharfun=19413041) at
print.c:506
#5 0x010c552d in print_object (obj=37526819, printcharfun=19413041,
escapeflag=0) at print.c:2050
#6 0x010c3c4a in print (obj=37526819, printcharfun=19413041, escapeflag=0)
at print.c:1301
#7 0x010c3059 in Fprinc (object=37526819, printcharfun=19413041) at
print.c:847
#8 0x010c3870 in print_error_message (data=36753309, stream=19413041,
context=0x9fbff70c "", caller=19764345)
at print.c:1090
#9 0x0105bd82 in cmd_error_internal (data=36753309, context=0x9fbff70c "")
at keyboard.c:1268
#10 0x0105bc80 in cmd_error (data=36753309) at keyboard.c:1205
#11 0x010b3dfb in internal_condition_case (bfun=0x105bfe0 <command_loop_1>,
handlers=19471817, hfun=0x105bbd8 <cmd_error>)
at eval.c:1465
#12 0x0105be78 in command_loop_2 () at keyboard.c:1328
#13 0x010b399c in internal_catch (tag=19460913, func=0x105be54
<command_loop_2>, arg=19412993) at eval.c:1213
#14 0x0105be28 in command_loop () at keyboard.c:1307
#15 0x0105ba0f in recursive_edit_1 () at keyboard.c:1000
#16 0x0105bb2a in Frecursive_edit () at keyboard.c:1061
#17 0x0105a9f6 in main (argc=1, argv=0x9fbff9ec) at emacs.c:1814
(gdb)
Regards,
Guanpeng Xu
_________________________________________________________________
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] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-08-09 9:37 Emacs crashes accidentally Herbert Euler
@ 2006-08-10 16:27 ` Richard Stallman
2006-09-06 12:50 ` Herbert Euler
0 siblings, 1 reply; 12+ messages in thread
From: Richard Stallman @ 2006-08-10 16:27 UTC (permalink / raw)
Cc: emacs-devel
Before crashing, I wanted to undo some deletion
so I typed C-x u C-x z z z ... When some `z' was pressed,
Emacs suddenly crashed.
The term "to crash" is often synonymous with "getting some z's" ;-).
#3 0x010c10b3 in strout (ptr=0x2469648 <Address 0x2469648 out of bounds>,
size=27, size_byte=27, printcharfun=19413041,
multibyte=0) at print.c:417
#4 0x010c1385 in print_string (string=37526819, printcharfun=19413041) at
print.c:506
It looks like STRING is invalid Lisp data. Please look inside it
and see precisely what is wrong with it.
#5 0x010c552d in print_object (obj=37526819, printcharfun=19413041,
escapeflag=0) at print.c:2050
#6 0x010c3c4a in print (obj=37526819, printcharfun=19413041, escapeflag=0)
at print.c:1301
#7 0x010c3059 in Fprinc (object=37526819, printcharfun=19413041) at
print.c:847
#8 0x010c3870 in print_error_message (data=36753309, stream=19413041,
context=0x9fbff70c "", caller=19764345)
at print.c:1090
Where did print_error_message get the string? Where did it come from?
If it came from DATA, then please try to trace it back.
What are the elements of DATA?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-08-10 16:27 ` Richard Stallman
@ 2006-09-06 12:50 ` Herbert Euler
2006-09-07 10:13 ` Herbert Euler
2006-09-07 21:15 ` Richard Stallman
0 siblings, 2 replies; 12+ messages in thread
From: Herbert Euler @ 2006-09-06 12:50 UTC (permalink / raw)
Cc: emacs-devel
>From: Richard Stallman <rms@gnu.org>
>Reply-To: rms@gnu.org
>To: "Herbert Euler" <herberteuler@hotmail.com>
>CC: emacs-devel@gnu.org
>Subject: Re: Emacs crashes accidentally
>Date: Thu, 10 Aug 2006 12:27:42 -0400
I'm so sorry I was required to have some training
these days and I could not read mails. Please
forgive me.
> Before crashing, I wanted to undo some deletion
> so I typed C-x u C-x z z z ... When some `z' was pressed,
> Emacs suddenly crashed.
>
>The term "to crash" is often synonymous with "getting some z's" ;-).
>
> #3 0x010c10b3 in strout (ptr=0x2469648 <Address 0x2469648 out of
>bounds>,
> size=27, size_byte=27, printcharfun=19413041,
> multibyte=0) at print.c:417
> #4 0x010c1385 in print_string (string=37526819,
>printcharfun=19413041) at
> print.c:506
>
>It looks like STRING is invalid Lisp data. Please look inside it
>and see precisely what is wrong with it.
(gdb) up
#4 0x010c1385 in print_string (string=37526819, printcharfun=19413041) at
print.c:506
506 strout (SDATA (string),
(gdb) p string
$1 = 37526819
(gdb) xpr
Lisp_String
$2 = (struct Lisp_String *) 0x23c9d20
"No further undo information"
(gdb) p *$
$3 = {
size = 27,
size_byte = -1,
intervals = 0x0,
data = 0x243d8ac "No further undo information"
}
(gdb)
I don't know whether it's wrong with STRING.
> #5 0x010c552d in print_object (obj=37526819, printcharfun=19413041,
> escapeflag=0) at print.c:2050
> #6 0x010c3c4a in print (obj=37526819, printcharfun=19413041,
>escapeflag=0)
> at print.c:1301
> #7 0x010c3059 in Fprinc (object=37526819, printcharfun=19413041) at
> print.c:847
> #8 0x010c3870 in print_error_message (data=36753309, stream=19413041,
> context=0x9fbff70c "", caller=19764345)
> at print.c:1090
>
>Where did print_error_message get the string? Where did it come from?
>If it came from DATA, then please try to trace it back.
>What are the elements of DATA?
#8 0x010c3870 in print_error_message (data=36753309, stream=19413041,
context=0x9fbff70c "", caller=19764345) at print.c:1090
#9 0x0105bd82 in cmd_error_internal (data=36753309, context=0x9fbff70c "")
at keyboard.c:1268
#10 0x0105bc80 in cmd_error (data=36753309) at keyboard.c:1205
#11 0x010b3dfb in internal_condition_case (bfun=0x105bfe0 <command_loop_1>,
handlers=19471817, hfun=0x105bbd8 <cmd_error>)
at eval.c:1465
Having seen this, I traced into INTERNAL_CONDITION_CASE.
It's version 1.210.4.35 of EVAL.C, line 1465. Lines near that
are:
if (_setjmp (c.jmp))
{
return (*hfun) (c.val);
}
I don't know how INTERNAL_CONDITION_CASE is invoked here,
is it invoked by jumping? Now please take a look at what DATA
is inside CMD_ERROR, which is the same as those in
CMD_ERROR_INTERNAL and PRINT_ERROR_MESSAGE:
(gdb) up
#10 0x0105bc80 in cmd_error (data=36753309) at keyboard.c:1205
1205 cmd_error_internal (data, macroerror);
(gdb) p data
$25 = 36753309
(gdb) xpr
Lisp_Cons
$26 = (struct Lisp_Cons *) 0x230cf98
{
car = 0x1291dc9,
u = {
cdr = 0x230cfad,
chain = 0x230cfad
}
}
(gdb) p $26->car
$27 = 19471817
(gdb) xpr
Lisp_Symbol
$28 = (struct Lisp_Symbol *) 0x1291dc8
"error"
(gdb) p $26->u->cdr
$29 = 36753325
(gdb) xpr
Lisp_Cons
$30 = (struct Lisp_Cons *) 0x230cfa8
{
car = 0x23c9d23,
u = {
cdr = 0x1283801,
chain = 0x1283801
}
}
(gdb) p $30->car
$31 = 37526819
(gdb) xpr
Lisp_String
$32 = (struct Lisp_String *) 0x23c9d20
"No further undo information"
(gdb) p $30->u->cdr
$33 = 19412993
(gdb) xpr
Lisp_Symbol
$34 = (struct Lisp_Symbol *) 0x1283800
"nil"
(gdb)
Hope the information can help.
Beg your pardon for my late reply again. I'm so sorry.
Regards,
Guanpeng Xu
_________________________________________________________________
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] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-06 12:50 ` Herbert Euler
@ 2006-09-07 10:13 ` Herbert Euler
2006-09-08 11:55 ` Richard Stallman
2006-09-07 21:15 ` Richard Stallman
1 sibling, 1 reply; 12+ messages in thread
From: Herbert Euler @ 2006-09-07 10:13 UTC (permalink / raw)
Having found that the followings:
(gdb) bt
#0 0x211c8104 in kill () from /usr/lib/libc.so.4
#1 0x01059900 in fatal_error_signal (sig=11) at emacs.c:430
#2 <signal handler called>
#3 0x010c10b3 in strout (ptr=0x2469648 <Address 0x2469648 out of bounds>,
size=27, size_byte=27, printcharfun=19413041,
multibyte=0) at print.c:417
#4 0x010c1385 in print_string (string=37526819, printcharfun=19413041) at
print.c:506
#5 0x010c552d in print_object (obj=37526819, printcharfun=19413041,
escapeflag=0) at print.c:2050
#6 0x010c3c4a in print (obj=37526819, printcharfun=19413041, escapeflag=0)
at print.c:1301
#7 0x010c3059 in Fprinc (object=37526819, printcharfun=19413041) at
print.c:847
#8 0x010c3870 in print_error_message (data=36753309, stream=19413041,
context=0x9fbff70c "", caller=19764345) at print.c:1090
#9 0x0105bd82 in cmd_error_internal (data=36753309, context=0x9fbff70c "")
at keyboard.c:1268
#10 0x0105bc80 in cmd_error (data=36753309) at keyboard.c:1205
#11 0x010b3dfb in internal_condition_case (bfun=0x105bfe0 <command_loop_1>,
handlers=19471817, hfun=0x105bbd8 <cmd_error>)
at eval.c:1465
#12 0x0105be78 in command_loop_2 () at keyboard.c:1328
#13 0x010b399c in internal_catch (tag=19460913, func=0x105be54
<command_loop_2>, arg=19412993) at eval.c:1213
#14 0x0105be28 in command_loop () at keyboard.c:1307
#15 0x0105ba0f in recursive_edit_1 () at keyboard.c:1000
#16 0x0105bb2a in Frecursive_edit () at keyboard.c:1061
#17 0x0105a9f6 in main (argc=1, argv=0x9fbff9ec) at emacs.c:1814
(gdb) p string
$10 = 37526819
(gdb) xstring
$11 = (struct Lisp_String *) 0x23c9d20
"No further undo information"
(gdb) p *$
$12 = {
size = 27,
size_byte = -1,
intervals = 0x0,
data = 0x243d8ac "No further undo information"
}
(gdb)
PRINT_STRING calls STROUT in this way:
(print.c, version 1.190.2.21, line 505-508)
/* strout is safe for output to a frame (echo area) or to
print_buffer. */
strout (SDATA (string),
chars, SBYTES (string),
printcharfun, STRING_MULTIBYTE (string));
"SDATA (string)" shall be 0x243d8ac, but value of the first argument
(PTR) of STROUT is 0x2469648. This is the reason why Emacs
crashed.
But, why this happened? Memory leak?
Regards,
Guanpeng Xu
_________________________________________________________________
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] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-07 10:13 ` Herbert Euler
@ 2006-09-08 11:55 ` Richard Stallman
2006-09-08 13:32 ` Herbert Euler
0 siblings, 1 reply; 12+ messages in thread
From: Richard Stallman @ 2006-09-08 11:55 UTC (permalink / raw)
Cc: emacs-devel
"SDATA (string)" shall be 0x243d8ac, but value of the first argument
(PTR) of STROUT is 0x2469648. This is the reason why Emacs
crashed.
But, why this happened? Memory leak?
I don't see how a memory leak could possibly have such an effect.
Please examine the value of printcharfun and figure out what Lisp
object it is. That way we can tell what path the code took through
strout. And what is the value of `i' in strout's frame?
strout increments PTR as it runs. Maybe it has incremented PTR too
far.
Or maybe message_dolog somehow clobbered the stack and altered PTR.
Basically I am as puzzled as you are.
We need more facts.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-08 11:55 ` Richard Stallman
@ 2006-09-08 13:32 ` Herbert Euler
2006-09-08 13:38 ` David Kastrup
0 siblings, 1 reply; 12+ messages in thread
From: Herbert Euler @ 2006-09-08 13:32 UTC (permalink / raw)
Cc: emacs-devel
>From: Richard Stallman <rms@gnu.org>
>Reply-To: rms@gnu.org
>To: "Herbert Euler" <herberteuler@hotmail.com>
>CC: emacs-devel@gnu.org
>Subject: Re: Emacs crashes accidentally
>Date: Fri, 08 Sep 2006 07:55:59 -0400
>
> "SDATA (string)" shall be 0x243d8ac, but value of the first argument
> (PTR) of STROUT is 0x2469648. This is the reason why Emacs
> crashed.
>
> But, why this happened? Memory leak?
>
>I don't see how a memory leak could possibly have such an effect.
>
>Please examine the value of printcharfun and figure out what Lisp
>object it is. That way we can tell what path the code took through
>strout. And what is the value of `i' in strout's frame?
>
>strout increments PTR as it runs. Maybe it has incremented PTR too
>far.
>
>Or maybe message_dolog somehow clobbered the stack and altered PTR.
>
>Basically I am as puzzled as you are.
>We need more facts.
(print.c, version 1.190.2.21, function STROUT)
static void
strout (ptr, size, size_byte, printcharfun, multibyte)
char *ptr;
int size, size_byte;
Lisp_Object printcharfun;
int multibyte;
{
[ The value of SIZE is 27, so SIZE_BYTE is not reset. ]
if (size < 0)
size_byte = size = strlen (ptr);
[ PRINTCHARFUN is 'T, and NONINTERACTIVE is 0, so
the third branch gets executed. ]
if (NILP (printcharfun))
{
if (print_buffer_pos_byte + size_byte > print_buffer_size)
{
print_buffer_size = print_buffer_size * 2 + size_byte;
print_buffer = (char *) xrealloc (print_buffer,
print_buffer_size);
}
bcopy (ptr, print_buffer + print_buffer_pos_byte, size_byte);
print_buffer_pos += size;
print_buffer_pos_byte += size_byte;
#ifdef MAX_PRINT_CHARS
if (max_print)
print_chars += size;
#endif /* MAX_PRINT_CHARS */
}
else if (noninteractive && EQ (printcharfun, Qt))
{
fwrite (ptr, 1, size_byte, stdout);
noninteractive_need_newline = 1;
}
[ This branch gets executed. ]
else if (EQ (printcharfun, Qt))
{
/* Output to echo area. We're trying to avoid a little overhead
here, that's the reason we don't call printchar to do the
job. */
int i;
[ CURRENT_BUFFER->ENABLE_MULTIBYTE_CHARACTERS is 'T.
I don't think I can remember whether the buffer I typed z's
contains multibyte characters. ]
int multibyte_p
= !NILP (current_buffer->enable_multibyte_characters);
[ I assume SETUP_ECHO_AREA_FOR_PRINTING behaves well
so I didn't trace into it. ]
setup_echo_area_for_printing (multibyte_p);
[ I see MESSAGE_DOLOG is in xdisp.c, but I compiled Emacs
without X. What's the behavior here? Since MESSAGE_DOLOG
is very long, I didn't post the tracing. Btw, Vmemory_full is
'NIL and Vmessage_log_max is 400. ]
message_dolog (ptr, size_byte, 0, multibyte_p);
[ Both SIZE and SIZE_BYTE are 27. ]
if (size == size_byte)
{
[ gdb shows that crashing happened on INSERT_CHAR.
While the value of I is 26, so iteration was not finished.
The value of PTR is 0x2469649, but PRINT_STRINT
calls STROUT with (I think) 0x243d8ac, so even the
starting address is not valid. ]
for (i = 0; i < size; ++i)
insert_char ((unsigned char )*ptr++);
}
else
{
This is what I can know now from the .core file. Andreas
Schwab told to find out whether GC was called, but I
don't know how.
Regards,
Guanpeng Xu
_________________________________________________________________
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] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-08 13:32 ` Herbert Euler
@ 2006-09-08 13:38 ` David Kastrup
2006-09-08 13:46 ` Herbert Euler
0 siblings, 1 reply; 12+ messages in thread
From: David Kastrup @ 2006-09-08 13:38 UTC (permalink / raw)
Cc: rms, emacs-devel
"Herbert Euler" <herberteuler@hotmail.com> writes:
[...]
> This is what I can know now from the .core file.
Just to be sure: if you are debugging post mortem, have you followed
the advice in DEBUG saying:
** When you are trying to analyze failed assertions, it will be
essential to compile Emacs either completely without optimizations or
at least (when using GCC) with the -fno-crossjumping option. Failure
to do so may make the compiler recycle the same abort call for all
assertions in a given function, rendering the stack backtrace useless
for identifying the specific failed assertion.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-08 13:38 ` David Kastrup
@ 2006-09-08 13:46 ` Herbert Euler
0 siblings, 0 replies; 12+ messages in thread
From: Herbert Euler @ 2006-09-08 13:46 UTC (permalink / raw)
Cc: rms, emacs-devel
I configured with
../configure --prefix=... --without-x
And I cannot reproduce the crashing, what I have
now is the compiled Emacs and a .core file.
Regards,
Guanpeng Xu
>From: David Kastrup <dak@gnu.org>
>To: "Herbert Euler" <herberteuler@hotmail.com>
>CC: rms@gnu.org, emacs-devel@gnu.org
>Subject: Re: Emacs crashes accidentally
>Date: Fri, 08 Sep 2006 15:38:41 +0200
>
>"Herbert Euler" <herberteuler@hotmail.com> writes:
>
>[...]
>
> > This is what I can know now from the .core file.
>
>Just to be sure: if you are debugging post mortem, have you followed
>the advice in DEBUG saying:
>
>** When you are trying to analyze failed assertions, it will be
>essential to compile Emacs either completely without optimizations or
>at least (when using GCC) with the -fno-crossjumping option. Failure
>to do so may make the compiler recycle the same abort call for all
>assertions in a given function, rendering the stack backtrace useless
>for identifying the specific failed assertion.
>
>--
>David Kastrup, Kriemhildstr. 15, 44793 Bochum
>
>
>_______________________________________________
>Emacs-devel mailing list
>Emacs-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/emacs-devel
_________________________________________________________________
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] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-06 12:50 ` Herbert Euler
2006-09-07 10:13 ` Herbert Euler
@ 2006-09-07 21:15 ` Richard Stallman
2006-09-08 2:50 ` Herbert Euler
1 sibling, 1 reply; 12+ messages in thread
From: Richard Stallman @ 2006-09-07 21:15 UTC (permalink / raw)
Cc: emacs-devel
$2 = (struct Lisp_String *) 0x23c9d20
"No further undo information"
(gdb) p *$
$3 = {
size = 27,
size_byte = -1,
intervals = 0x0,
data = 0x243d8ac "No further undo information"
}
It looks valid to me.
So what directly caused strout to crash?
Please investigate its code and its data
and figure out the immediate cause of the crash.
I don't know how INTERNAL_CONDITION_CASE is invoked here,
is it invoked by jumping?
It is invoked from its caller in keyboard.c,
but errors return to it with longjmp.
longjmp could be how control got to it this time.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-07 21:15 ` Richard Stallman
@ 2006-09-08 2:50 ` Herbert Euler
2006-09-08 8:49 ` Andreas Schwab
0 siblings, 1 reply; 12+ messages in thread
From: Herbert Euler @ 2006-09-08 2:50 UTC (permalink / raw)
Cc: emacs-devel
Having found the followings:
(gdb) bt
#0 0x211c8104 in kill () from /usr/lib/libc.so.4
#1 0x01059900 in fatal_error_signal (sig=11) at emacs.c:430
#2 <signal handler called>
[ Please pay attention to these two frames ]
#3 0x010c10b3 in strout (ptr=0x2469648 <Address 0x2469648 out of bounds>,
size=27, size_byte=27, printcharfun=19413041,
multibyte=0) at print.c:417
#4 0x010c1385 in print_string (string=37526819, printcharfun=19413041) at
print.c:506
#5 0x010c552d in print_object (obj=37526819, printcharfun=19413041,
escapeflag=0) at print.c:2050
#6 0x010c3c4a in print (obj=37526819, printcharfun=19413041, escapeflag=0)
at print.c:1301
#7 0x010c3059 in Fprinc (object=37526819, printcharfun=19413041) at
print.c:847
#8 0x010c3870 in print_error_message (data=36753309, stream=19413041,
context=0x9fbff70c "", caller=19764345) at print.c:1090
#9 0x0105bd82 in cmd_error_internal (data=36753309, context=0x9fbff70c "")
at keyboard.c:1268
#10 0x0105bc80 in cmd_error (data=36753309) at keyboard.c:1205
#11 0x010b3dfb in internal_condition_case (bfun=0x105bfe0 <command_loop_1>,
handlers=19471817, hfun=0x105bbd8 <cmd_error>)
at eval.c:1465
#12 0x0105be78 in command_loop_2 () at keyboard.c:1328
#13 0x010b399c in internal_catch (tag=19460913, func=0x105be54
<command_loop_2>, arg=19412993) at eval.c:1213
#14 0x0105be28 in command_loop () at keyboard.c:1307
#15 0x0105ba0f in recursive_edit_1 () at keyboard.c:1000
#16 0x0105bb2a in Frecursive_edit () at keyboard.c:1061
#17 0x0105a9f6 in main (argc=1, argv=0x9fbff9ec) at emacs.c:1814
(gdb) p string
$10 = 37526819
(gdb) xstring
$11 = (struct Lisp_String *) 0x23c9d20
"No further undo information"
(gdb) p *$
$12 = {
size = 27,
size_byte = -1,
intervals = 0x0,
data = 0x243d8ac "No further undo information"
}
(gdb)
PRINT_STRING calls STROUT in this way:
(print.c, version 1.190.2.21, line 505-508)
/* strout is safe for output to a frame (echo area) or to print_buffer.
*/
strout (SDATA (string),
chars, SBYTES (string),
printcharfun, STRING_MULTIBYTE (string));
"SDATA (string)" shall be 0x243d8ac (see also result of P *$ in gdb),
but value of the first argument (PTR) of STROUT is 0x2469648.
This is the reason why Emacs crashed.
But, why did this happen? Memory leak?
Regards,
Guanpeng Xu
_________________________________________________________________
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] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-08 2:50 ` Herbert Euler
@ 2006-09-08 8:49 ` Andreas Schwab
2006-09-08 15:12 ` Richard Stallman
0 siblings, 1 reply; 12+ messages in thread
From: Andreas Schwab @ 2006-09-08 8:49 UTC (permalink / raw)
Cc: rms, emacs-devel
"Herbert Euler" <herberteuler@hotmail.com> writes:
> PRINT_STRING calls STROUT in this way:
>
> (print.c, version 1.190.2.21, line 505-508)
>
> /* strout is safe for output to a frame (echo area) or to
> print_buffer. */
> strout (SDATA (string),
> chars, SBYTES (string),
> printcharfun, STRING_MULTIBYTE (string));
>
> "SDATA (string)" shall be 0x243d8ac (see also result of P *$ in gdb),
> but value of the first argument (PTR) of STROUT is 0x2469648.
> This is the reason why Emacs crashed.
>
> But, why did this happen? Memory leak?
Looks like a GC violation. See the comment for message_nolog:
This may GC (insert may run before/after change hooks),
so the buffer M must NOT point to a Lisp string. */
Can you find out whether GC was called during the call to message_nolog
in strout?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs crashes accidentally
2006-09-08 8:49 ` Andreas Schwab
@ 2006-09-08 15:12 ` Richard Stallman
0 siblings, 0 replies; 12+ messages in thread
From: Richard Stallman @ 2006-09-08 15:12 UTC (permalink / raw)
Cc: herberteuler, emacs-devel
Looks like a GC violation. See the comment for message_nolog:
This may GC (insert may run before/after change hooks),
so the buffer M must NOT point to a Lisp string. */
You're right. In fact, that's not the only thing in strout
that is likely to cause lossage if GC relocates the string.
print_string is supposed to be the function to use for a Lisp string.
So I think the bug is that print_string calls strout in a case where
that is not safe.
Does this fix it?
*** print.c 08 Sep 2006 07:47:26 -0400 1.227
--- print.c 08 Sep 2006 10:37:18 -0400
***************
*** 497,506 ****
else
chars = SBYTES (string);
! /* strout is safe for output to a frame (echo area) or to print_buffer. */
! strout (SDATA (string),
! chars, SBYTES (string),
! printcharfun, STRING_MULTIBYTE (string));
}
else
{
--- 497,524 ----
else
chars = SBYTES (string);
! if (EQ (printcharfun, Qt))
! {
! int nbytes = SBYTES (string);
! char *buffer;
!
! /* Output to echo area. Copy the string contents so that
! relocation by GC does not cause trouble. */
! USE_SAFE_ALLOCA;
!
! SAFE_ALLOCA (buffer, char *, nbytes);
! bcopy (SDATA (string), buffer, nbytes);
!
! strout (buffer, chars, SBYTES (string),
! printcharfun, STRING_MULTIBYTE (string));
!
! SAFE_FREE ();
! }
! else
! /* strout is safe for output to print_buffer. */
! strout (SDATA (string),
! chars, SBYTES (string),
! printcharfun, STRING_MULTIBYTE (string));
}
else
{
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-09-08 15:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-09 9:37 Emacs crashes accidentally Herbert Euler
2006-08-10 16:27 ` Richard Stallman
2006-09-06 12:50 ` Herbert Euler
2006-09-07 10:13 ` Herbert Euler
2006-09-08 11:55 ` Richard Stallman
2006-09-08 13:32 ` Herbert Euler
2006-09-08 13:38 ` David Kastrup
2006-09-08 13:46 ` Herbert Euler
2006-09-07 21:15 ` Richard Stallman
2006-09-08 2:50 ` Herbert Euler
2006-09-08 8:49 ` Andreas Schwab
2006-09-08 15:12 ` Richard Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.