GNU bug report logs - #45159
28.0.50; crash when no space on disk

Previous Next

To reply to this bug, email your comments to 45159 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; crash when no space on disk
Date: Thu, 10 Dec 2020 16:01:14 +0300

Emacs crushes on lack of disk space. I was running it under Carlos's
O'Donnel mtrace and it was taking space and space, and crushes then.

I was using function to loop over database entries and to update
external database. There are 200000+ entries to update. I do not see
why it should crush as the database is not large by size. It handles
one entry after the other, very small entries, like integers.

I can replicate. Should I send xbacktrace?



-- 
Thanks,
Jean Louis
⎔ λ 🄯 𝍄 𝌡 𝌚

Message #8 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jean Louis <bugs <at> gnu.support>, 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Thu, 10 Dec 2020 08:05:56 -0600

Jean Louis <bugs <at> gnu.support> writes:

> Should I send xbacktrace?

Yes, send the output of bt and xbacktrace.

Message #11 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Thu, 10 Dec 2020 16:23:55 +0200

> Date: Thu, 10 Dec 2020 16:01:14 +0300
> From: Jean Louis <bugs <at> gnu.support>
> 
> 
> Emacs crushes on lack of disk space. I was running it under Carlos's
> O'Donnel mtrace and it was taking space and space, and crushes then.
> 
> I was using function to loop over database entries and to update
> external database. There are 200000+ entries to update. I do not see
> why it should crush as the database is not large by size. It handles
> one entry after the other, very small entries, like integers.
> 
> I can replicate. Should I send xbacktrace?

Yes, please post the backtrace and any other details pertaining to
this problem.

Message #14 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Thu, 10 Dec 2020 19:34:42 +0300

[Message part 1 (text/plain, inline)]

* Stefan Kangas <stefankangas <at> gmail.com> [2020-12-10 17:06]:
> Jean Louis <bugs <at> gnu.support> writes:
> 
> > Should I send xbacktrace?
> 
> Yes, send the output of bt and xbacktrace.

I hope that format in attachment makes sense. gdb failed, it got
problem itself, and I could just save XTerm log.

If it does not help I will do nexti.

[XTerm2020-12-10.17:20:56 (text/plain, attachment)]

Message #17 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Thu, 10 Dec 2020 19:59:52 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2020-12-10 17:24]:
> > Date: Thu, 10 Dec 2020 16:01:14 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > 
> > 
> > Emacs crushes on lack of disk space. I was running it under Carlos's
> > O'Donnel mtrace and it was taking space and space, and crushes then.
> > 
> > I was using function to loop over database entries and to update
> > external database. There are 200000+ entries to update. I do not see
> > why it should crush as the database is not large by size. It handles
> > one entry after the other, very small entries, like integers.
> > 
> > I can replicate. Should I send xbacktrace?
> 
> Yes, please post the backtrace and any other details pertaining to
> this problem.

It is reproducible only if Emacs runs under gmalloc trace utils. Do
you need that?

Additionally I can see that if there is any package like
persistent-scratch, Emacs cannot be killed with C-x C-c as package
asked to be saved. There is no way to exit Emacs is disk space is full
and some package want to save data on exit.

Message #20 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Thu, 10 Dec 2020 19:13:50 +0200

> Date: Thu, 10 Dec 2020 19:59:52 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 45159 <at> debbugs.gnu.org
> 
> > Yes, please post the backtrace and any other details pertaining to
> > this problem.
> 
> It is reproducible only if Emacs runs under gmalloc trace utils. Do
> you need that?

Yes.  Once we understand the reason, we can think whether it needs to
be fixed or not, but it's hard to do that without knowing which code
crashes and why.

> Additionally I can see that if there is any package like
> persistent-scratch, Emacs cannot be killed with C-x C-c as package
> asked to be saved. There is no way to exit Emacs is disk space is full
> and some package want to save data on exit.

That is also a bug.

Message #23 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: stefankangas <at> gmail.com, 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Thu, 10 Dec 2020 20:18:43 +0200

> Date: Thu, 10 Dec 2020 19:34:42 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 45159 <at> debbugs.gnu.org
> 
> > > Should I send xbacktrace?
> > 
> > Yes, send the output of bt and xbacktrace.
> 
> I hope that format in attachment makes sense. gdb failed, it got
> problem itself, and I could just save XTerm log.
> 
> If it does not help I will do nexti.
> 
> #9  0x00000000004f982e in timer_check () at keyboard.c:4403
>         nexttime = <optimized out>
>         timers = 0x1bceb43
>         idle_timers = 0x5434ce3
>         tem = <optimized out>
> #10 0x00000000004f9c39 in readable_events (flags=flags <at> entry=1) at keyboard.c:3405
> #11 0x00000000004fa688 in get_input_pending (flags=flags <at> entry=1) at keyboard.c:6795
> #12 0x00000000004fd658 in detect_input_pending_run_timers (do_display=do_display <at> entry=false)
>     at keyboard.c:10350
>         old_timers_run = <optimized out>

Thanks, but this is incomplete: frames below #9 are missing.  They are
the most important ones, as they show where exactly Emacs crashes.  If
you reproduce this at will, please show the first 9 frames.

Message #26 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Fri, 11 Dec 2020 00:23:23 +0300

[Message part 1 (text/plain, inline)]

* Eli Zaretskii <eliz <at> gnu.org> [2020-12-10 20:14]:
> > Date: Thu, 10 Dec 2020 19:59:52 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 45159 <at> debbugs.gnu.org
> > 
> > > Yes, please post the backtrace and any other details pertaining to
> > > this problem.
> > 
> > It is reproducible only if Emacs runs under gmalloc trace utils. Do
> > you need that?
> 
> Yes.  Once we understand the reason, we can think whether it needs to
> be fixed or not, but it's hard to do that without knowing which code
> crashes and why.
> 
> > Additionally I can see that if there is any package like
> > persistent-scratch, Emacs cannot be killed with C-x C-c as package
> > asked to be saved. There is no way to exit Emacs is disk space is full
> > and some package want to save data on exit.
> 
> That is also a bug.

Business of debugging makes my computer frozen. This time I have
attached gdb to Emacs and it did not crash. I could not do
anything. Operation interrupted and I could not do just nothin with
Emacs. xkilled it, and madde bt full which is attached. I will try
tomorrow again.

[out.log.gz (application/x-gunzip, attachment)]

Message #29 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Fri, 11 Dec 2020 10:12:25 +0200

> Date: Fri, 11 Dec 2020 00:23:23 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 45159 <at> debbugs.gnu.org
> 
> > > Additionally I can see that if there is any package like
> > > persistent-scratch, Emacs cannot be killed with C-x C-c as package
> > > asked to be saved. There is no way to exit Emacs is disk space is full
> > > and some package want to save data on exit.
> > 
> > That is also a bug.
> 
> Business of debugging makes my computer frozen. This time I have
> attached gdb to Emacs and it did not crash. I could not do
> anything. Operation interrupted and I could not do just nothin with
> Emacs. xkilled it, and madde bt full which is attached. I will try
> tomorrow again.

What Emacs command triggered the problem which happened before you
attached GDB?  Above, you are talking about not being able to kill
Emacs with "C-x C-c" when persistent-scratch is used -- is that what
you did there before attaching GDB?

> #0  0x00007f15991dedb0 in raise () at /lib/libpthread.so.0
> #1  0x0000000000418ccd in terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:408
> #2  0x0000000000418ea0 in emacs_abort () at sysdep.c:2282
> #3  0x000000000045a4ec in redisplay_internal () at xdisp.c:15474

What do you have on line 15474 of xdisp.c in the source tree from
which this binary was produced?  I don't think I understand how
redisplay_internal called emacs_abort in this case.

> #7  0x00000000004f3223 in shut_down_emacs (sig=sig <at> entry=6, stuff=stuff <at> entry=0x0) at emacs.c:2450
>         tpgrp = <optimized out>
> #8  0x0000000000418c9e in terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:391
> #9  0x0000000000418ea0 in emacs_abort () at sysdep.c:2282
> #10 0x000000000045c2a2 in message3_nolog (m=m <at> entry=0x4ccd694) at xdisp.c:11117
>         sf = <optimized out>

Likewise here: what do you have on line 11117 of xdisp.c, in
message3_nolog function?  I don't understand how emacs_abort got
called here, either.

Thanks.

Message #32 received at 45159 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 45159 <at> debbugs.gnu.org
Subject: Re: bug#45159: 28.0.50; crash when no space on disk
Date: Sat, 12 Dec 2020 04:36:20 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2020-12-11 11:13]:
> > Date: Fri, 11 Dec 2020 00:23:23 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 45159 <at> debbugs.gnu.org
> > 
> > > > Additionally I can see that if there is any package like
> > > > persistent-scratch, Emacs cannot be killed with C-x C-c as package
> > > > asked to be saved. There is no way to exit Emacs is disk space is full
> > > > and some package want to save data on exit.
> > > 
> > > That is also a bug.
> > 
> > Business of debugging makes my computer frozen. This time I have
> > attached gdb to Emacs and it did not crash. I could not do
> > anything. Operation interrupted and I could not do just nothin with
> > Emacs. xkilled it, and madde bt full which is attached. I will try
> > tomorrow again.
> 
> What Emacs command triggered the problem which happened before you
> attached GDB?  Above, you are talking about not being able to kill
> Emacs with "C-x C-c" when persistent-scratch is used -- is that what
> you did there before attaching GDB?

I use persistent scratch all the time. In few first attempts, Emacs
crashed when hard disk was not enough. It was working full time
without user interactions as it was handling the database processing
for many minutes iterating over 200000+ numbers and for each number
looking into how many emails belong to specific person and how many
SMS, chat and other interactions each person have got and recording it
to the database by using dynamic module emacs-libpq.

In the subsequent attempt to crash Emacs and find the bug instead of
crushing it stopped its job or work, debugge opened, but I was not
able to do anything like using keyboard, or C-g multiple times or
similar.

> > #0  0x00007f15991dedb0 in raise () at /lib/libpthread.so.0
> > #1  0x0000000000418ccd in terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:408
> > #2  0x0000000000418ea0 in emacs_abort () at sysdep.c:2282
> > #3  0x000000000045a4ec in redisplay_internal () at xdisp.c:15474
> 
> What do you have on line 15474 of xdisp.c in the source tree from
> which this binary was produced?  I don't think I understand how
> redisplay_internal called emacs_abort in this case.

  /* No redisplay if running in batch mode or frame is not yet fully
15474     initialized, or redisplay is explicitly turned off by setting
     Vinhibit_redisplay.  */
  if ((FRAME_INITIAL_P (SELECTED_FRAME ())
       && redisplay_skip_initial_frame)
      || !NILP (Vinhibit_redisplay))
    return;

By the way, when opening xdisp.c I got this error:

Debugger entered--Lisp error: (error "Invalid face" font-lock-warning-face)
  internal-copy-lisp-face(font-lock-warning-face c-nonbreakable-space-face #<frame Movies - GNU Emacs at protected.rcdrun.com 0x33040b8> nil)
  copy-face(font-lock-warning-face c-nonbreakable-space-face #<frame Movies - GNU Emacs at protected.rcdrun.com 0x33040b8>)
  copy-face(font-lock-warning-face c-nonbreakable-space-face)
  c-make-inverse-face(font-lock-warning-face c-nonbreakable-space-face)
  (if (c-face-name-p 'c-nonbreakable-space-face) nil (c-make-inverse-face 'font-lock-warning-face 'c-nonbreakable-space-face))
  (unless (c-face-name-p 'c-nonbreakable-space-face) (c-make-inverse-face 'font-lock-warning-face 'c-nonbreakable-space-face))
  (progn (unless (c-face-name-p 'c-nonbreakable-space-face) (c-make-inverse-face 'font-lock-warning-face 'c-nonbreakable-space-face)) ''c-nonbreakable-space-face)
  (list "\240" 0 (progn (unless (c-face-name-p 'c-nonbreakable-space-face) (c-make-inverse-face 'font-lock-warning-face 'c-nonbreakable-space-face)) ''c-nonbreakable-space-face))
  eval((list "\240" 0 (progn (unless (c-face-name-p 'c-nonbreakable-space-face) (c-make-inverse-face 'font-lock-warning-face 'c-nonbreakable-space-face)) ''c-nonbreakable-space-face)))
  font-lock-compile-keyword((eval list "\240" 0 (progn (unless (c-face-name-p 'c-nonbreakable-space-face) (c-make-inverse-face 'font-lock-warning-face 'c-nonbreakable-space-face)) ''c-nonbreakable-space-face)))
  mapcar(font-lock-compile-keyword (c-font-lock-complex-decl-prepare (#f(compiled-function (limit) #<bytecode -0x143bb8fede1d832c>)) c-maybe-font-lock-wrong-style-comments ("\\(\\=\\|\\(\\=\\|[^\\]\\)[\n\15]\\)\\s *#\\s *\\(\\(?:error\\|warn..." 4 font-lock-string-face t) (#f(compiled-function (limit) #<bytecode -0x14cccc421df0d645>)) (#f(compiled-function (limit) #<bytecode 0x78b9b911fe031d6>)) (#f(compiled-function (limit) #<bytecode -0x8049f0b1d573359>)) (#f(compiled-function (limit) #<bytecode -0x90b56485ecd0475>)) (eval list #f(compiled-function (limit) #<bytecode 0x8ea6a5044794d01>) 3 c-negation-char-face-name 'append) (eval list "\240" 0 (progn (unless (c-face-name-p 'c-nonbreakable-space-face) (c-make-inverse-face 'font-lock-warning-face 'c-nonbreakable-space-face)) ''c-nonbreakable-space-face)) ("\\s|" 0 font-lock-warning-face t nil) c-font-lock-invalid-single-quotes (eval list "\\<\\(\\(?:NULL\\|\\(?:fals\\|tru\\)e\\)\\)\\>" 1 c-constant-face-name) ("\\<\\(\\(?:__\\(?:a\\(?:\\(?:sm\\|ttribute\\)__\\)\\|declspe..." 1 font-lock-keyword-face) (eval list "\\(!\\)[^=]" 1 c-negation-char-face-name) c-font-lock-cut-off-declarators c-font-lock-declarations c-font-lock-enclosing-decls c-font-lock-c++-using ("\\<\\(\\(?:_\\(?:Bool\\|Complex\\|Imaginary\\)\\|char\\|dou..." 1 'font-lock-type-face) c-font-lock-enum-tail c-font-lock-enum-body (eval list "\\<\\(\\(?:goto\\)\\)\\>\\s *\\([[:alpha:]_][[:alnum:]_$]*..." (list 2 c-label-face-name nil t))))
  font-lock-compile-keywords((c-font-lock-complex-decl-prepare (#f(compiled-function (limit) #<bytecode -0x143bb8fede1d832c>)) c-maybe-font-lock-wrong-style-comments ("\\(\\=\\|\\(\\=\\|[^\\]\\)[\n\15]\\)\\s *#\\s *\\(\\(?:error\\|warn..." 4 font-lock-string-face t) (#f(compiled-function (limit) #<bytecode -0x14cccc421df0d645>)) (#f(compiled-function (limit) #<bytecode 0x78b9b911fe031d6>)) (#f(compiled-function (limit) #<bytecode -0x8049f0b1d573359>)) (#f(compiled-function (limit) #<bytecode -0x90b56485ecd0475>)) (eval list #f(compiled-function (limit) #<bytecode 0x8ea6a5044794d01>) 3 c-negation-char-face-name 'append) (eval list "\240" 0 (progn (unless (c-face-name-p 'c-nonbreakable-space-face) (c-make-inverse-face 'font-lock-warning-face 'c-nonbreakable-space-face)) ''c-nonbreakable-space-face)) ("\\s|" 0 font-lock-warning-face t nil) c-font-lock-invalid-single-quotes (eval list "\\<\\(\\(?:NULL\\|\\(?:fals\\|tru\\)e\\)\\)\\>" 1 c-constant-face-name) ("\\<\\(\\(?:__\\(?:a\\(?:\\(?:sm\\|ttribute\\)__\\)\\|declspe..." 1 font-lock-keyword-face) (eval list "\\(!\\)[^=]" 1 c-negation-char-face-name) c-font-lock-cut-off-declarators c-font-lock-declarations c-font-lock-enclosing-decls c-font-lock-c++-using ("\\<\\(\\(?:_\\(?:Bool\\|Complex\\|Imaginary\\)\\|char\\|dou..." 1 'font-lock-type-face) c-font-lock-enum-tail c-font-lock-enum-body (eval list "\\<\\(\\(?:goto\\)\\)\\>\\s *\\([[:alpha:]_][[:alnum:]_$]*..." (list 2 c-label-face-name nil t))))
  font-lock-set-defaults()
  font-lock-mode-internal(t)
  font-lock-default-function(t)
  font-lock-mode()
  turn-on-font-lock()
  turn-on-font-lock-if-desired()
  global-font-lock-mode-enable-in-buffers()
  run-hooks(after-change-major-mode-hook)
  run-mode-hooks(c-mode-hook)
  c-mode()
  set-auto-mode-0(c-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer xdisp.c> "~/Programming/Software/emacs/src/xdisp.c" nil nil "~/Programming/Software/emacs/src/xdisp.c" (55584502 65024))
  find-file-noselect("/home/data1/protected/Programming/Software/emacs/s..." nil nil nil)
  find-file("/home/data1/protected/Programming/Software/emacs/s...")
  dired-find-file()
  funcall-interactively(dired-find-file)
  call-interactively(dired-find-file nil nil)
  command-execute(dired-find-file)
> 
> > #7  0x00000000004f3223 in shut_down_emacs (sig=sig <at> entry=6, stuff=stuff <at> entry=0x0) at emacs.c:2450
> >         tpgrp = <optimized out>
> > #8  0x0000000000418c9e in terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:391
> > #9  0x0000000000418ea0 in emacs_abort () at sysdep.c:2282
> > #10 0x000000000045c2a2 in message3_nolog (m=m <at> entry=0x4ccd694) at xdisp.c:11117
> >         sf = <optimized out>
> 
> Likewise here: what do you have on line 11117 of xdisp.c, in
> message3_nolog function?  I don't understand how emacs_abort got
> called here, either.

/* The non-logging version of message3.
   This does not cancel echoing, because it is used for echoing.
   Perhaps we need to make a separate function for echoing
   and make this cancel echoing.  */

void
11117: message3_nolog (Lisp_Object m)
{
  struct frame *sf = SELECTED_FRAME ();

  if (FRAME_INITIAL_P (sf))
    message_to_stderr (m);
  /* Error messages get reported properly by cmd_error, so this must be just an
     informative message; if the frame hasn't really been initialized yet, just
     toss it.  */
  else if (INTERACTIVE && sf->glyphs_initialized_p)
    {
      /* Get the frame containing the mini-buffer
	 that the selected frame is using.  */
      Lisp_Object mini_window = FRAME_MINIBUF_WINDOW (sf);
      Lisp_Object frame = XWINDOW (mini_window)->frame;
      struct frame *f = XFRAME (frame);

      if (FRAME_VISIBLE_P (sf) && !FRAME_VISIBLE_P (f))
	Fmake_frame_visible (frame);

      if (STRINGP (m) && SCHARS (m) > 0)
	{
	  set_message (m);
	  if (minibuffer_auto_raise)
	    Fraise_frame (frame);
	  /* Assume we are not echoing.
	     (If we are, echo_now will override this.)  */
	  echo_message_buffer = Qnil;
	}
      else
	clear_message (true, true);

      do_pending_window_change (false);
      echo_area_display (true);
      do_pending_window_change (false);
      if (FRAME_TERMINAL (f)->frame_up_to_date_hook)
	(*FRAME_TERMINAL (f)->frame_up_to_date_hook) (f);
    }
}

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.