GNU bug report logs - #28505
26.0.60; Crash in Fmove_point_visually

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 28505 in the body.
You can then email your comments to 28505 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: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.60; Crash in Fmove_point_visually
Date: Mon, 18 Sep 2017 22:09:10 +0200

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

I read my mails in Gnus in an "emacs -nw" instance that I access via SSH
(this instance where I am writing this uses the same setup).  When I
have read my mails, I can make Emacs crash with the sequence <M-x a LEFT
RIGHT>.  GDB says this is in Fmove_point_visually at "BUFFERP
(g->object)".  I am attaching a GDB log with my commands added manually.

This does not reproduce without running Gnus before, so I can not run
this from a plain emacs -Q.  It looks to me like there is garbage in the
"row" struct, or the pointer row itself is garbage.

Let me know if I can do some more usefull debugging next time.

[gdb.txt (text/plain, attachment)]

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

In GNU Emacs 26.0.60 (build 1, i686-pc-linux-gnu, GTK+ Version 2.24.25)
 of 2017-09-17 built on justinian
Repository revision: 57249fb297237bb942ead1f7a0af0ac20811a9cf
System Description:	Debian GNU/Linux 8.9 (jessie)

Recent messages:
scroll-down-command: Beginning of buffer [3 times]
previous-line: Beginning of buffer [4 times]
Auto-saving...done
next-line: End of buffer [2 times]
Auto-saving...done
Mark set
next-line: End of buffer [19 times]
scroll-down-command: Beginning of buffer [5 times]
Saving file /home/benny/Projects/emacs-26/gdb.txt...
Wrote /home/benny/Projects/emacs-26/gdb.txt

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM GSETTINGS NOTIFY LIBSELINUX GNUTLS
LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK2 X11

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  shell-dirtrack-mode: t
  gpm-mouse-mode: t
  desktop-save-mode: t
  delete-selection-mode: t
  display-time-mode: t
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort emacsbug dirtrack shell pcomplete t-mouse term/linux imenu
elec-pair desktop frameset highline benny-calendar-cfg ange-ftp
benny-unicode generic-x autoinsert cc-cmds cc-engine cc-vars cc-defs
ps-print ps-print-loaddefs ps-def lpr advice benny-url cmuscheme comint
ansi-color ring scheme delsel disp-table time server protbuf cal-china
lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs
vc-git diff-mode easy-mmode vc-fossil vc vc-dispatcher diary-lib
diary-loaddefs cal-menu calendar cal-loaddefs benny-file-cache message-x
message subr-x puny dired dired-loaddefs format-spec mml mml-sec epa
derived epg gnus-util rmail rmail-loaddefs time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 gmm-utils mailheader bbdb-snarf mail-extr
rfc822 bbdb-com mailabbrev bbdb-autoloads bbdb cl timezone sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils .loaddefs
browse-url autoload radix-tree lisp-mnt finder-inf gh-common gh-profile
rx s marshal eieio-compat ht json map dash info package easymenu
epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 8 193041 22460)
 (symbols 24 31276 1)
 (miscs 20 40 333)
 (strings 16 60409 2969)
 (string-bytes 1 1885315)
 (vectors 8 24621)
 (vector-slots 4 613375 18028)
 (floats 8 822 684)
 (intervals 28 254 0)
 (buffers 528 13)
 (heap 1024 9005 788))

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

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: 28505 <at> debbugs.gnu.org
Subject: Re: 26.0.60; Crash in Fmove_point_visually
Date: Mon, 18 Sep 2017 23:02:12 +0200

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

Benjamin Riefenstahl writes:
> Let me know if I can do some more usefull debugging next time.

So I recompiled with -O0 and after reading the code I added a few more
"p"s in GDB.  I see that "w->current_matrix" has "rows_allocated = 1,
nrows = 1", but still "row" was initialized from "rows" and than
incremented by "dir" (1).  Is that as it should be?

[gdb.txt (text/plain, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: 28505 <at> debbugs.gnu.org
Subject: Re: bug#28505: 26.0.60; Crash in Fmove_point_visually
Date: Tue, 19 Sep 2017 07:11:07 +0300

> From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
> Date: Mon, 18 Sep 2017 23:02:12 +0200
> 
> So I recompiled with -O0 and after reading the code I added a few more
> "p"s in GDB.  I see that "w->current_matrix" has "rows_allocated = 1,
> nrows = 1", but still "row" was initialized from "rows" and than
> incremented by "dir" (1).  Is that as it should be?

Yes, but the incremented value is then checked for validity with this
snippet:

	  if (row < MATRIX_FIRST_TEXT_ROW (w->current_matrix)
	      || row > MATRIX_BOTTOM_TEXT_ROW (w->current_matrix, w))
	    goto simulate_display;

Is something wrong with this test in your case?

Thanks for digging into this.

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

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28505 <at> debbugs.gnu.org
Subject: Re: bug#28505: 26.0.60; Crash in Fmove_point_visually
Date: Tue, 19 Sep 2017 18:13:05 +0200

>> From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
>> Date: Mon, 18 Sep 2017 23:02:12 +0200
>> 
>> So I recompiled with -O0 and after reading the code I added a few more
>> "p"s in GDB.  I see that "w->current_matrix" has "rows_allocated = 1,
>> nrows = 1", but still "row" was initialized from "rows" and than
>> incremented by "dir" (1).  Is that as it should be?

Eli Zaretskii writes:
> Yes, but the incremented value is then checked for validity with this
> snippet:
>
> 	  if (row < MATRIX_FIRST_TEXT_ROW (w->current_matrix)
> 	      || row > MATRIX_BOTTOM_TEXT_ROW (w->current_matrix, w))
> 	    goto simulate_display;

MATRIX_BOTTON_TEXT_ROW calculates "rows + nrows" (plus the mode-line,
but this is the minibuffer, so it does not have a mode-line).  So
despite the name of the macro the result points *after* the bottom row,
not *at* it.  Should that comparison be "row >= BOTTOM"?  I'll try that.
The macro seems to be misnamed though if that is the problem.

benny

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: 28505 <at> debbugs.gnu.org
Subject: Re: bug#28505: 26.0.60; Crash in Fmove_point_visually
Date: Tue, 19 Sep 2017 20:13:15 +0300

> From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
> Cc: 28505 <at> debbugs.gnu.org
> Date: Tue, 19 Sep 2017 18:13:05 +0200
> 
> > 	  if (row < MATRIX_FIRST_TEXT_ROW (w->current_matrix)
> > 	      || row > MATRIX_BOTTOM_TEXT_ROW (w->current_matrix, w))
> > 	    goto simulate_display;
> 
> MATRIX_BOTTON_TEXT_ROW calculates "rows + nrows" (plus the mode-line,
> but this is the minibuffer, so it does not have a mode-line).  So
> despite the name of the macro the result points *after* the bottom row,
> not *at* it.  Should that comparison be "row >= BOTTOM"?  I'll try that.
> The macro seems to be misnamed though if that is the problem.

Ah, yes.  MATRIX_BOTTON_TEXT_ROW gives the last row + 1, so this was
an off-by-one error.  Should be fixed now.

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

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28505 <at> debbugs.gnu.org
Subject: Re: bug#28505: 26.0.60; Crash in Fmove_point_visually
Date: Tue, 19 Sep 2017 21:22:50 +0200

Eli Zaretskii writes:
> Ah, yes.  MATRIX_BOTTON_TEXT_ROW gives the last row + 1, so this was
> an off-by-one error.  Should be fixed now.

I see what you did there ;-) I had the simpler ">= BOTTOM" running for
my last session and no problem so far.  I'll rebuild and tell you how it
goes.
 
PS: Would you be interested in a patch to rename that macro to, say
"MATRIX_END_OF_TEXT_ROWS"?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
Cc: 28505 <at> debbugs.gnu.org
Subject: Re: bug#28505: 26.0.60; Crash in Fmove_point_visually
Date: Wed, 20 Sep 2017 08:58:29 +0300

> From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
> Cc: 28505 <at> debbugs.gnu.org
> Date: Tue, 19 Sep 2017 21:22:50 +0200
> 
> Eli Zaretskii writes:
> > Ah, yes.  MATRIX_BOTTON_TEXT_ROW gives the last row + 1, so this was
> > an off-by-one error.  Should be fixed now.
> 
> I see what you did there ;-) I had the simpler ">= BOTTOM" running for
> my last session and no problem so far.  I'll rebuild and tell you how it
> goes.

Thanks.

> PS: Would you be interested in a patch to rename that macro to, say
> "MATRIX_END_OF_TEXT_ROWS"?

Doesn't seem to be worth the trouble, since the new name will probably
be longer, and this macro is rarely used.

Message #28 received at 28505-done <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 28505-done <at> debbugs.gnu.org
Subject: Re: bug#28505: 26.0.60; Crash in Fmove_point_visually
Date: Wed, 20 Sep 2017 18:27:29 +0200

From: Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net>
>> I see what you did there ;-) I had the simpler ">= BOTTOM" running for
>> my last session and no problem so far.  I'll rebuild and tell you how it
>> goes.

Works so far, I'm therefore closing the bug.

benny

Previous Next

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