crash in RC branch

crash in RC branch

[Francesco Potorti`]

While running under dbg under screen with ssh remote login, I had a
crash of an Emacs built about ten days ago from the RC branch.

I had mistakenly visited a long (about 14MB) rmail file, and I hit C-g
while Emacs was reading it.  Since the connection is relatively slow,
and I was forward typing, I do not know exactly what were the last
commands.  However, this reminds me of a similar crash that I
experienced some months ago in a similar situation.

Today I have no time to try to debug it, and I do not expect to have
much in the next days.  Here is a backtrace:

Switch to buffer: (default *shell*) SMAIL
Breakpoint 1, abort () at emacs.c:387
387       kill (getpid (), SIGABRT);
(gdb) bt
#0  abort () at emacs.c:387
#1  0x08173d2b in get_local_map () at intervals.c:2183
#2  0x080e597f in read_key_sequence (keybuf=0xbfffee00, bufsize=30, prompt=405319004, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8015
#3  0x080dd2b4 in command_loop_1 () at keyboard.c:1440
#4  0x0813733a in internal_condition_case (bfun=0x80dd0e0 <command_loop_1>, handlers=405415348,
    hfun=0x80dcc80 <cmd_error>) at eval.c:1267
#5  0x080dcf9d in command_loop_2 () at keyboard.c:1245
#6  0x08136ea9 in internal_catch (tag=405525148, func=0x80dcf70 <command_loop_2>, arg=405319004) at
eval.c:1030
#7  0x080dcf47 in command_loop () at keyboard.c:1224
#8  0x080dca0e in recursive_edit_1 () at keyboard.c:950
#9  0x080dcb42 in Frecursive_edit () at keyboard.c:1006
#10 0x080db38b in main (argc=3, argv=0xbffff484, envp=0xbffff494) at emacs.c:1547
(gdb) xbacktrace
(gdb)

Re: crash in RC branch

[Francesco Potorti`]

Following up to my own post about an Emacs pretest crash, I discovered
that it is apparently the same as a crash that I reported on June, and
that I stopped debugging because a power outage destroyed the live gdb
session.

I'll try to reread the mail I had with you in June and see if I can go
any further.

Is there any way to save a live gdb session, so that a power outage does
not utterly destroy it?

Re: crash in RC branch

[Francesco Potorti`]

I need help, because I don't know where to go from now on.  I suspect it
has something to do with latin-1 characters, and with C-g, but both of
these may be wrong.

The crash I am debugging is of the same nature of a crash that rms
helped me debugging on June, but I had not yet finished when I was
interrupted by a power outage.  These are the facts.

I visited a big (about 17 MB) rmail file.  After a while, since Emacs
took a long time to load it, I hit C-g.  Then I don't know exactly what
I did, and I do not manage to print the value of recent_keys in a
coprehensible way.  However, these are the last two messages in the
*Messages* buffer:

 rmail-decode-babyl-format: Quit
 kill-buffer: Quit

Notice that, in the previous instance of the crash I had on June, the
last message was:

 rmail-decode-babyl-format: Quit

This should mean that the file was in fact all in memory, and Emacs had
begun to convert it.

After that, Emacs aborted in get_local_map at intervals.c:

  /* Perhaps we should just change `position' to the limit.  */
  if (position > BUF_Z (buffer) || position < BUF_BEG (buffer))
    abort ();

What made it abort is the first condition.  In fact, in current_buffer:
 pt          = 17566287 (position)
 own_text.z  = 981      (BUF_Z)

The current buffer is the big rmail file, whose lenght is 17566288, and
in fact, in current_buffer:
 save_length = 17566288

The string in current_buffer at own_text.beg+pt is apparently nothing
strange: pure ASCII text in the middle of a line.

The buffer contents in memory are in the internal Emacs format, that is,
every latin-1 character is preceded by \201.

The gap size is big (as it was in the previous crash)
    gpt = 970, 
    z = 981, 
    gpt_byte = 970, 
    z_byte = 981, 
    gap_size = 17571308, 

The character in the file at point 970 is the first non-ASCII character
in the file, a latin-1 character (0350 octal).  In the buffer in memory:
 (gdb) p current_buffer->own_text.beg[969]
 $349 = 129 '\201'
 (gdb) p current_buffer->own_text.beg[970]
 $350 = 232 '\350'

I cannot look at the undo list, because it is nil (this is normal, I
think, in an rmail buffer during initialisation).

Here is some gdb output:

================================================================
-IT<-11:**-F1  *mail* 00:01 0.25 Mail   (Mail H Fa Abbrev Fill)--L2--C43--Top---
Switch to buffer: (default *shell*) SMAIL
Breakpoint 1, abort () at emacs.c:387
387       kill (getpid (), SIGABRT);

(gdb) bt
#0  abort () at emacs.c:387
#1  0x08173d2b in get_local_map () at intervals.c:2183
#2  0x080e597f in read_key_sequence (keybuf=0xbfffee00, bufsize=30, prompt=405319004, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8015
#3  0x080dd2b4 in command_loop_1 () at keyboard.c:1440
#4  0x0813733a in internal_condition_case (bfun=0x80dd0e0 <command_loop_1>, handlers=405415348,
    hfun=0x80dcc80 <cmd_error>) at eval.c:1267
#5  0x080dcf9d in command_loop_2 () at keyboard.c:1245
#6  0x08136ea9 in internal_catch (tag=405525148, func=0x80dcf70 <command_loop_2>, arg=405319004) at eval.c:1030
#7  0x080dcf47 in command_loop () at keyboard.c:1224
#8  0x080dca0e in recursive_edit_1 () at keyboard.c:950
#9  0x080dcb42 in Frecursive_edit () at keyboard.c:1006
#10 0x080db38b in main (argc=3, argv=0xbffff484, envp=0xbffff494) at emacs.c:1547

(gdb) xbacktrace

(gdb) p position
$1 = 17566287

(gdb) p current_buffer[0]
$3 = {
  size = 537002092, 
  next = 0x8e7cbb8, 
  own_text = {
    beg = 0x41116008 "BABYL OPTIONS: -*- rmail -*-\nVersion: 5\nLabels:\nNote:   This is the header of an rmail file.\nNote:   If you are seeing it in rmail,\nNote:    it means the file has no messages in it.\n\037\f\n1,,\nDate: 1 Jan"..., 
    gpt = 970, 
    z = 981, 
    gpt_byte = 970, 
    z_byte = 981, 
    gap_size = 17571308, 
    modiff = 3, 
    save_modiff = 0, 
    overlay_modiff = 1, 
    beg_unchanged = -1, 
    end_unchanged = 0, 
    unchanged_modified = 1, 
    overlay_unchanged_modified = 1, 
    intervals = 0x828bd70, 
    markers = 677474904
  }, 
  text = 0x914edf0, 
  pt = 17566287, 
  pt_byte = 17566287, 
  begv = 1, 
  begv_byte = 1, 
  zv = 981, 
  zv_byte = 981, 
  base_buffer = 0x0, 
  local_flags = '\0' <repeats 13 times>, "\001\0\001\0\0\0\001\0\0\0\0\0\0\0\0P\356\024\t\0\0\0\0\a\0\0\01\001\0\0p\3229\t\260W", 
  modtime = 1036364301, 
  auto_save_modified = 2, 
  auto_save_failure_time = -1, 
  last_window_start = 1, 
  clip_changed = 1, 
  newline_cache = 0x0, 
  width_run_cache = 0x0, 
  prevent_redisplay_optimizations_p = 1, 
  undo_list = 405319004, 
  name = 957615556, 
  filename = 958398396, 
  directory = 952295716, 
  backed_up = 405319004, 
  save_length = 17566288, 
  auto_save_file_name = 405319004, 
---Type <return> to continue, or q <return> to quit---
  read_only = 405319052, 
  mark = 682055496, 
  local_var_alist = 1479512436, 
  major_mode = 406061884, 
  mode_name = 944593516, 
  mode_line_format = 1479455276, 
  header_line_format = 405319004, 
  keymap = 1480516916, 
  abbrev_table = 1212524312, 
  syntax_table = 1212524560, 
  category_table = 1210667592, 
  case_fold_search = 405319052, 
  tab_width = 8, 
  fill_column = 72, 
  left_margin = 0, 
  auto_fill_function = 405319004, 
  buffer_file_type = 405319004, 
  downcase_table = 1210669688, 
  upcase_table = 1211642584, 
  case_canon_table = 1211834432, 
  case_eqv_table = 1211849408, 
  truncate_lines = 405319004, 
  ctl_arrow = 405319052, 
  direction_reversed = 405319004, 
  selective_display = 405319004, 
  selective_display_ellipses = 405319052, 
  minor_modes = 405319004, 
  overwrite_mode = 405319004, 
  abbrev_mode = 405319004, 
  display_table = 405319004, 
  mark_active = 405319004, 
  overlays_before = 405319004, 
  overlays_after = 405319004, 
  overlay_center = 17566289, 
  enable_multibyte_characters = 405319004, 
  buffer_file_coding_system = 405319004, 
  file_format = 405319004, 
  cache_long_line_scans = 405319004, 
  width_table = 405319004, 
  pt_marker = 405319004, 
  begv_marker = 405319004, 
  zv_marker = 405319004, 
  point_before_scroll = 405319004, 
  file_truename = 952295732, 
  invisibility_spec = 405319052, 
  last_selected_window = 1226800416, 
  display_count = 1, 
---Type <return> to continue, or q <return> to quit---
  left_margin_width = 0, 
  right_margin_width = 0, 
  indicate_empty_lines = 405319052, 
  display_time = 1483133916, 
  scroll_up_aggressively = 405319004, 
  scroll_down_aggressively = 405319004, 
  cursor_type = 405319052, 
  extra_line_spacing = 405319004
}

Re: crash in RC branch

[Richard Stallman]

    Is there any way to save a live gdb session, so that a power outage does
    not utterly destroy it?

I don't know of one.  There is no easy way to recreate it as a live
session, but it should not be hard to add a GDB command to create a
core dump from it.

With the HURD it should not be too hard to save and recreate it as a
live session.

Re: crash in RC branch

[Eli Zaretskii]

On Tue, 5 Nov 2002, Richard Stallman wrote:

> There is no easy way to recreate it as a live
> session, but it should not be hard to add a GDB command to create a
> core dump from it.

As a matter of fact, the current development sources of GDB already have 
such a command.

Re: crash in RC branch

[Francesco Potorti`]

>> session, but it should not be hard to add a GDB command to create a
>> core dump from it.
>
>As a matter of fact, the current development sources of GDB already have 
>such a command.

What is it called?  Just so that, when it arrive on Debian as a package
I can try to remember it.

Re: crash in RC branch

[Richard Stallman]

    I visited a big (about 17 MB) rmail file.  After a while, since Emacs
    took a long time to load it, I hit C-g.  Then I don't know exactly what
    I did, and I do not manage to print the value of recent_keys in a
    coprehensible way.

The only way to debug this is by working backwards from the crash
site.  Analize why it crashed, and then see where the data came from.
Try to work back as far as you can.

Information such as what you typed is relevant only if it helps you
do this backward analysis.

    What made it abort is the first condition.  In fact, in current_buffer:
     pt          = 17566287 (position)
     own_text.z  = 981      (BUF_Z)

Ok, so PT is wrong.  The question is, where did it get set wrong?
The value clearly relates to the size of the file

    The gap size is big (as it was in the previous crash)
	gpt = 970, 
	z = 981, 
	gpt_byte = 970, 
	z_byte = 981, 
	gap_size = 17571308, 

I suspect that the gap was made big in order to accommodate the file's
text, but then it did not all get inserted.  I suggest you take a look
at the code in Finsert_file_contents to see if there is a way it can
quit, setting PT based on the text it WOULD HAVE inserted.

Maybe you can insert some calls to abort at the places that can
QUIT in Finsert_file_contents, checking that PT is <= Z.
Then if this happens again it will abort earlier where you have
a chance of seeimg why;

Re: crash in RC branch

[Eli Zaretskii]

> From: Francesco Potorti` <pot@gnu.org>
> Date: 06 Nov 2002 13:22:42 +0100
> 
> >> session, but it should not be hard to add a GDB command to create a
> >> core dump from it.
> >
> >As a matter of fact, the current development sources of GDB already have 
> >such a command.
> 
> What is it called?

It's called `gcore'.

Re: crash in RC branch

[Richard Stallman]

    > There is no easy way to recreate it as a live
    > session, but it should not be hard to add a GDB command to create a
    > core dump from it.

    As a matter of fact, the current development sources of GDB already have 
    such a command.

Thank you, GDB maintainers, for adding this useful feature.

Re: crash in RC branch

[Francesco Potorti`]

>It's called `gcore'.

I just tried it and it works on my Debian testing (sarge) system.  I
feel better now :-)

Re: crash in RC branch

[Eli Zaretskii]

> From: Francesco Potorti` <pot@gnu.org>
> Date: 07 Nov 2002 23:05:30 +0100
> 
> >It's called `gcore'.
> 
> I just tried it and it works on my Debian testing (sarge) system.  I
> feel better now :-)

On second thought, perhaps you actually need another command:
"maint dump-me".  That one is available for a very long time.

Re: crash in RC branch

[Francesco Potorti`]

>> >It's called `gcore'.
>> 
>> I just tried it and it works on my Debian testing (sarge) system.  I
>> feel better now :-)
>
>On second thought, perhaps you actually need another command:
>"maint dump-me".  That one is available for a very long time.

That makes gdb abort and dump its core.  That's not what one would want
normally.  gcore is what I wanted:

(gdb) help maint dump-me
Get fatal error; make debugger dump its core.
GDB sets it's handling of SIGQUIT back to SIG_DFL and then sends
itself a SIGQUIT signal.

(gdb) help gcore
Save a core file with the current state of the debugged process.
Argument is optional filename.  Default filename is 'core.<process_id>'.

Re: crash in RC branch

[Eli Zaretskii]

On Sun, 10 Nov 2002, Francesco Potorti` wrote:

> >On second thought, perhaps you actually need another command:
> >"maint dump-me".  That one is available for a very long time.
> 
> That makes gdb abort and dump its core.  That's not what one would want
> normally.

I wasn't sure whether you and Richard were talking about dumping the core 
of the debugger or the debuggee.

At least now you know how to do both ;-)

Re: crash in RC branch

[Richard Stallman]

    I had mistakenly visited a long (about 14MB) rmail file, and I hit C-g
    while Emacs was reading it.  Since the connection is relatively slow,
    and I was forward typing, I do not know exactly what were the last
    commands.  However, this reminds me of a similar crash that I
    experienced some months ago in a similar situation.

    Today I have no time to try to debug it, and I do not expect to have
    much in the next days.  Here is a backtrace:

What I can tell anything from the backtrace alone
is that PT is screwed up, not between BEGV and ZV.
I suspect that quitting out of insert-file-contents left the
data inconsistent.  However, I can't be sure none of your
type-ahead was executed.

If you can make this happen again, you could use recent_keys
to see how much of your input actually got executed.

Re: crash in RC branch

[Francesco Potorti`]

>    I had mistakenly visited a long (about 14MB) rmail file, and I hit C-g
>    while Emacs was reading it.  Since the connection is relatively slow,
>    and I was forward typing, I do not know exactly what were the last
>    commands.  However, this reminds me of a similar crash that I
>    experienced some months ago in a similar situation.
>
>    Today I have no time to try to debug it, and I do not expect to have
>    much in the next days.  Here is a backtrace:
>
>What I can tell anything from the backtrace alone
>is that PT is screwed up, not between BEGV and ZV.
>I suspect that quitting out of insert-file-contents left the
>data inconsistent.  However, I can't be sure none of your
>type-ahead was executed.
>
>If you can make this happen again, you could use recent_keys
>to see how much of your input actually got executed.

I still have the crashed emaca alive under gdb (in a `screen' window),
and perhaps during these holidays I'll find the time to look at it...

I tried to look at recent_keys, but wasn't able to parse its contents.

Re: crash in RC branch

[Eli Zaretskii]

On Mon, 23 Dec 2002, Francesco Potorti` wrote:

> I tried to look at recent_keys, but wasn't able to parse its contents.

What was the nature of your difficulty, specifically?  IIRC, recent_keys 
simply holds the numerical values of the keys, so an ASCII table should 
be enough to interpret it (that's an oversimplification: there are 
modifiers such as Meta etc., but the principle remains).

Re: crash in RC branch

[Richard Stallman]

    I tried to look at recent_keys, but wasn't able to parse its contents.

Look at the code that stores values in it, and you will see how
it is stored.