GNU bug report logs - #5710
23.1; Fatal error in format

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5710 in the body.
You can then email your comments to 5710 AT debbugs.gnu.org in the normal way.

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

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

From: Andreas Politz <politza <at> fh-trier.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; Fatal error in format
Date: Fri, 12 Mar 2010 14:22:44 +0100

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs <at> gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

(format "%16.s"
	"0123456789abcdef")

makes emacs abort.  This reflects the following situation in editfns.c :

total = 5 + 5 + 1 = 11
field_width = 16
precision = 0
thissize = 0
actual_width = 16

thissize += max(0,16 - 16) = 0
total += 0 + 4 = 15

I think it is clearly a mistake to substract the width of the
whole argument-string from the field_width, regardless of how
much of it will actually end up in the result, depending
on the precision mod.

That's the basis for the following patch.

diff --git a/src/editfns.c b/src/editfns.c
index c2c5d26..b1af0fc 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -3779,6 +3779,8 @@ usage: (format STRING &rest OBJECTS)  */)
 	       the case PRECISION = 0. */
 	    thissize = precision[n] ? CONVERTED_BYTE_SIZE (multibyte, args[n]) : 0;
 	    actual_width = lisp_string_width (args[n], -1, NULL, NULL);
+            if (precision[n] != -1)
+              actual_width = min(actual_width,precision[n]);
 	  }
 	/* Would get MPV otherwise, since Lisp_Int's `point' to low memory.  */
 	else if (INTEGERP (args[n]) && *format != 's')

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.1/etc/DEBUG for instructions.


In GNU Emacs 23.1.1 (x86_64-pc-linux-gnu, GTK+ Version 2.18.3)
 of 2009-11-02 on excelsior, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10605000
configured using `configure  '--build=x86_64-linux-gnu' '--host=x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'host_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: C
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  narrow-stack-mode: t
  easy-repeat-mode: t
  recentf-mode: t
  ido-hacks-mode: t
  window-numbering-mode: t
  show-paren-mode: t
  icomplete-mode: t
  global-hi-lock-mode: t
  hi-lock-mode: t
  display-time-mode: t
  savehist-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
u a l RET M-b M-s C-r C-r C-r C-r C-r C-s C-s RET C-x
o M-m M-f M-f M-f M-b C-e C-j a c t u a M-/ SPC = SPC
p r e c M-/ [ n ] SPC > SPC M-b M-b C-b C-b C-e M-m
M-d M-d C-d C-d C-d i f SPC ( C-e C-h = SPC 0 ) M-b
C-b C-h C-h ! = C-f C-d - 1 C-f C-j a c t u M-/ SPC
= SPC m i n ( a c M-/ , p r e M-/ [ n ] ) ; C-c C-c
C-p C-a C-2 M-; C-x C-g C-c C-c C-/ TAB C-n TAB C-p
M-m C-k C-k M-f M-f M-f M-f C-p M-b M-b C-k C-n M-f
M-b M-f M-f M-b C-y C-M-k C-h C-j C-f m a x ( 0 , M-f
M-f C-f C-f ) TAB C-f C-p C-p C-a C-k C-M-f C-M-f C-M-f
C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/ C-/
C-/ C-/ M-f C-M-f M-v M-v M-v M-v C-v C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-v C-v C-s t h i s C-s C-s C-s RET C-r f i e l
d RET C-v C-v C-v M-v C-/ C-f C-/ C-x v C-. C-x 1 C-,
C-, C-x b <return> C-x v C-. C-x v = y M-: M-p M-f
M-f C-b . 1 <return> M-: M-p ( l e n d t h C-h C-h
C-h g t h SPC C-e ) <return> M-1 M-x b u g p r e <backspace>
C-g M-x e m a c s - b u <return>

Recent messages:
Auto-saving...done
Redo! [2 times]
Type "q" to restore this window.
Type C-x 1 to delete the help window.
Buffer editfns.c modified; save it? (y or n)
Saving file /home/politza/src/emacs23/src/editfns.c...
Wrote /home/politza/src/emacs23/src/editfns.c
Finding changes in /home/politza/src/emacs23/src/editfns.c...done
"                   H"
20 (#o24, #x14)
Quit

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Andreas Politz <politza <at> fh-trier.de>,
	Stefan Monnier  <monnier <at> iro.umontreal.ca>
Cc: 5710 <at> debbugs.gnu.org
Subject: Re: 23.1; Fatal error in format
Date: Sat, 13 Mar 2010 14:57:18 -0500

> (format "%16.s" "0123456789abcdef")
>
> makes emacs abort.  This reflects the following situation in editfns.c :
>
> total = 5 + 5 + 1 = 11
> field_width = 16
> precision = 0
> thissize = 0
> actual_width = 16
>
> thissize += max(0,16 - 16) = 0
> total += 0 + 4 = 15
>
> I think it is clearly a mistake to substract the width of the
> whole argument-string from the field_width, regardless of how
> much of it will actually end up in the result, depending
> on the precision mod.

Thanks.  I agree with your analysis, and have checked your patch into
the trunk.

Stefan, I think it's worthwhile to include this patch in the release
branch as well, though it's not a regression (it appears to be a
longstanding bug).  Aborts in `format' are not good.  What's your
opinion?

Previous Next

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