GNU bug report logs - #8219
23.3; Crash in indirect buffer

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 8219 in the body.
You can then email your comments to 8219 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: Chong Yidong <cyd <at> stupidchicken.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.3; Crash in indirect buffer
Date: Thu, 10 Mar 2011 15:24:41 -0500

Just came across this; it is present in (at least) 23.2, and in trunk.
I haven't had time to debug further; any help welcome.  The backtrace is
from trunk.

emacs -Q
M-<
M-x clone-indirect-buffer RET
C-n
C-k
C-x o
C-k   => abort

#0  abort () at emacs.c:372
#1  0x0000000000646ba0 in find_interval (tree=0xc569e0, position=78)
    at intervals.c:635
#2  0x0000000000649c9c in get_property_and_range (pos=78, prop=12679682,
    val=0x7fffffffacd8, start=0x7ffffffface8, end=0x7ffffffface0,
    object=22411973) at intervals.c:2263
#3  0x0000000000651631 in find_composition (pos=78, limit=-1,
    start=0x7ffffffface8, end=0x7ffffffface0, prop=0x7fffffffacd8,
    object=22411973) at composite.c:430
#4  0x0000000000448290 in check_point_in_composition (prev_buf=0x155fac0,
    prev_pt=78, buf=0x155fac0, pt=2) at xdisp.c:11311
#5  0x0000000000448857 in reconsider_clip_changes (w=0x1564480, b=0x155fac0)
    at xdisp.c:11358
#6  0x000000000044f0d7 in redisplay_window (window=22430853, just_this_one_p=0)
    at xdisp.c:13715
#7  0x000000000044addc in redisplay_window_0 (window=22430853) at xdisp.c:12362
#8  0x00000000005dc1dc in internal_condition_case_1 (
    bfun=0x44ad9d <redisplay_window_0>, arg=22430853, handlers=12412566,
    hfun=0x44ad6e <redisplay_window_error>) at eval.c:1453
#9  0x000000000044ad4f in redisplay_windows (window=22430853) at xdisp.c:12342
#10 0x000000000044ad09 in redisplay_windows (window=22430309) at xdisp.c:12336
#11 0x0000000000449e14 in redisplay_internal (preserve_echo_area=0)
    at xdisp.c:11919
#12 0x0000000000447cff in redisplay () at xdisp.c:11139
#13 0x00000000005419ca in read_char (commandflag=1, nmaps=2,
    maps=0x7fffffffdae0, prev_event=12442194, used_mouse_menu=0x7fffffffddb8,
    end_time=0x0) at keyboard.c:2357
#14 0x000000000054f450 in read_key_sequence (keybuf=0x7fffffffde20,
    bufsize=30, prompt=12442194, dont_downcase_last=0,
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9193
#15 0x000000000053fbae in command_loop_1 () at keyboard.c:1409
#16 0x00000000005dc067 in internal_condition_case (
    bfun=0x53f7f3 <command_loop_1>, handlers=12494210,
    hfun=0x53f0d8 <cmd_error>) at eval.c:1408
#17 0x000000000053f4f4 in command_loop_2 (ignore=12442194) at keyboard.c:1129
#18 0x00000000005dba31 in internal_catch (tag=12490226,
    func=0x53f4ce <command_loop_2>, arg=12442194) at eval.c:1152
#19 0x000000000053f4a7 in command_loop () at keyboard.c:1108
#20 0x000000000053ec0f in recursive_edit_1 () at keyboard.c:731
#21 0x000000000053edc2 in Frecursive_edit () at keyboard.c:793
#22 0x000000000053d0e8 in main (argc=2, argv=0x7fffffffe728) at emacs.c:1684

In GNU Emacs 24.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2011-03-10 on furball
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
configured using `configure  'CC=gcc' 'CFLAGS=-g''

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

From: Glenn Morris <rgm <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8219 <at> debbugs.gnu.org
Subject: Re: bug#8219: 23.3; Crash in indirect buffer
Date: Thu, 10 Mar 2011 15:56:05 -0500

Same as

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1242

?

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 8219 <at> debbugs.gnu.org
Subject: Re: bug#8219: 23.3; Crash in indirect buffer
Date: Thu, 10 Mar 2011 16:56:32 -0500

Glenn Morris <rgm <at> gnu.org> writes:

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1242

I guess we can assume this is the same bug.  So, now we have a
reproducible recipe.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: emacs-devel <at> gnu.org
Cc: 8219 <at> debbugs.gnu.org
Subject: Effect of deletions on indirect buffers (Bug#8219)
Date: Fri, 11 Mar 2011 14:48:21 -0500

Indirect bufffers are allowed to have their own values of point,
BUF_BEGV, and BUF_ZV (indeed, that's one of their roles).  Their other
attributes inherit from the base buffer, e.g.

#define BUF_Z(buf) ((buf)->text->z)

where `text' points to the base buffer's text object.

Now consider what happens when a deletion is performed in buffer A,
which is the base buffer for an indirect buffer B.  It appears that the
responsible functions, such as del_range_2, only update the attributes
of buffer A, making no effort to update buffer B.

Hence, in the aftermath of a deletion, buffer B's values of PT (and
BUF_BEGV and BUF_ZV) can be larger than BUF_ZV.  This is the proximate
cause of the crash in Bug#8219: there, we have

 if (prev_pt > BUF_BEGV (buf) && prev_pt < BUF_ZV (buf)
     && find_composition (prev_pt, -1, &start, &end, &prop, buffer)

and find_composition aborts because prev_pt is larger than the size of
the buffer.


I'm not sure what the best solution is.  The narrowest fix is to change
find_composition, and the functions it calls, so that it does not abort
when supplied with a position that's beyond BUF_Z.  This might be the
best approach for the emacs-23 branch.

However, I suspect that we have other places in the code that assumes
that if a point is smaller than BUF_ZV, it's necessarily smaller than
BUF_Z---which we now see if not that case.  So, a more comprehensive fix
is needed for the trunk.

Any thoughts?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: Effect of deletions on indirect buffers (Bug#8219)
Date: Fri, 11 Mar 2011 22:07:54 +0200

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Date: Fri, 11 Mar 2011 14:48:21 -0500
> Cc: 8219 <at> debbugs.gnu.org
> 
> Now consider what happens when a deletion is performed in buffer A,
> which is the base buffer for an indirect buffer B.  It appears that the
> responsible functions, such as del_range_2, only update the attributes
> of buffer A, making no effort to update buffer B.
> 
> Hence, in the aftermath of a deletion, buffer B's values of PT (and
> BUF_BEGV and BUF_ZV) can be larger than BUF_ZV.

Isn't that a bug, right there?  Why doesn't del_range_2 update the
indirect buffer (B) as well, when deletion removes text so that its PT
becomes invalid?

The ELisp manual says:

     The text of the indirect buffer is always identical to the text of
  its base buffer; changes made by editing either one are visible
  immediately in the other.  This includes the text properties as well as
  the characters themselves.

     In all other respects, the indirect buffer and its base buffer are
  completely separate.  They have different names, independent values of
  point, independent narrowing, independent markers and overlays (though
  inserting or deleting text in either buffer relocates the markers and
  overlays for both), [...]

This makes a lot of sense, but your description seems to point out
that the implementation does not behave according to the docs: if
markers are (or should be) relocated in sync as result of insertion
and deletion, the same should happen with PT, BUF_BEGV, etc.

Am I missing something?  If not, the solution is to update the
attributes of the indirect buffer so as to preserve the invariants,
like PT <= BUF_Z etc.

> However, I suspect that we have other places in the code that assumes
> that if a point is smaller than BUF_ZV, it's necessarily smaller than
> BUF_Z

It is madness IMO to allow BUF_Z and BUF_ZV be out of sync.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#8219: Effect of deletions on indirect buffers (Bug#8219)
Date: Fri, 11 Mar 2011 15:58:57 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Hence, in the aftermath of a deletion, buffer B's values of PT (and
>> BUF_BEGV and BUF_ZV) can be larger than BUF_ZV.
>
> Isn't that a bug, right there?  Why doesn't del_range_2 update the
> indirect buffer (B) as well, when deletion removes text so that its PT
> becomes invalid?

This is not currently easy.  We don't keep track of indirect buffers
(looping over the buffer list each time we do a deletion would be rather
inefficient), so this would need some new members of the buffer struct.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 8219 <at> debbugs.gnu.org,
	emacs-devel <at> gnu.org
Subject: Re: Effect of deletions on indirect buffers (Bug#8219)
Date: Fri, 11 Mar 2011 18:19:25 -0500

> This makes a lot of sense, but your description seems to point out
> that the implementation does not behave according to the docs: if
> markers are (or should be) relocated in sync as result of insertion
> and deletion, the same should happen with PT, BUF_BEGV, etc.

Actually, indirect buffers keep their point and narrowing in real
markers.  So when they get "active" the BUF_PT, BUF_ZV, etc... get
updated, but until that time, BUF_PT and friends may hold invalid data.
I.e. any place where we use BUF_PT on something else than
current_buffer, we have a bug waiting to happen unless we know for sure
that that buffer is not indirect.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#8219: Effect of deletions on indirect buffers (Bug#8219)
Date: Sat, 12 Mar 2011 10:15:05 +0200

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Cc: 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
> Date: Fri, 11 Mar 2011 15:58:57 -0500
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Hence, in the aftermath of a deletion, buffer B's values of PT (and
> >> BUF_BEGV and BUF_ZV) can be larger than BUF_ZV.
> >
> > Isn't that a bug, right there?  Why doesn't del_range_2 update the
> > indirect buffer (B) as well, when deletion removes text so that its PT
> > becomes invalid?
> 
> This is not currently easy.  We don't keep track of indirect buffers
> (looping over the buffer list each time we do a deletion would be rather
> inefficient), so this would need some new members of the buffer struct.

We could do that lazily, whenever something (including redisplay) is
done on a buffer that happens to be an indirect buffer.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: cyd <at> stupidchicken.com, 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: Effect of deletions on indirect buffers (Bug#8219)
Date: Sat, 12 Mar 2011 11:01:45 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Chong Yidong <cyd <at> stupidchicken.com>,  8219 <at> debbugs.gnu.org,  emacs-devel <at> gnu.org
> Date: Fri, 11 Mar 2011 18:19:25 -0500
> 
> I.e. any place where we use BUF_PT on something else than
> current_buffer, we have a bug waiting to happen unless we know for sure
> that that buffer is not indirect.

It follows that BUF_PT, when used on other than the current buffer
should update PT if necessary, if that buffer is an indirect buffer,
before returning the value.  And the same with BUF_BEGV, BUF_ZV, etc.

Right?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: Effect of deletions on indirect buffers (Bug#8219)
Date: Sat, 12 Mar 2011 15:47:05 -0500

> It follows that BUF_PT, when used on other than the current buffer
> should update PT if necessary, if that buffer is an indirect buffer,
> before returning the value.  And the same with BUF_BEGV, BUF_ZV, etc.

> Right?

Yes.  At least that was my conclusion last time we bumped into such
a bug.  I even added a comment in buffer.h about it:

/* !!!FIXME:  all the BUF_BEGV/BUF_ZV/BUF_PT macros are flawed:
   on indirect (or base) buffers, that value is only correct if that buffer
   is the current_buffer, or if the buffer's text hasn't been modified (via
   an indirect buffer) since it was last current.  */


        Stefan

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#8219: Effect of deletions on indirect buffers (Bug#8219)
Date: Sun, 13 Mar 2011 12:30:59 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Yes.  At least that was my conclusion last time we bumped into such
> a bug.  I even added a comment in buffer.h about it:
>
> /* !!!FIXME:  all the BUF_BEGV/BUF_ZV/BUF_PT macros are flawed:
>    on indirect (or base) buffers, that value is only correct if that buffer
>    is the current_buffer, or if the buffer's text hasn't been modified (via
>    an indirect buffer) since it was last current.  */

I think we should do away with the BUF_BEGV and related macros.  Let the
code in buffer.c manipulate the buffer->begv members directly; and the
usage in other parts of Emacs can be replaced with buf_begv() functions
that will update begv if necessary, and return the corrected result.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: bug#8219: Effect of deletions on indirect buffers (Bug#8219)
Date: Sun, 13 Mar 2011 13:09:45 -0400

Chong Yidong <cyd <at> stupidchicken.com> writes:

> I think we should do away with the BUF_BEGV and related macros.  Let the
> code in buffer.c manipulate the buffer->begv members directly; and the
> usage in other parts of Emacs can be replaced with buf_begv() functions
> that will update begv if necessary, and return the corrected result.

Or rather, these functions should consult the pt_marker, begv_marker and
zv_marker markers instead of accessing begv etc directly.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 8219 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: Effect of deletions on indirect buffers (Bug#8219)
Date: Sun, 13 Mar 2011 18:29:01 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> /* !!!FIXME:  all the BUF_BEGV/BUF_ZV/BUF_PT macros are flawed:
>    on indirect (or base) buffers, that value is only correct if that buffer
>    is the current_buffer, or if the buffer's text hasn't been modified (via
>    an indirect buffer) since it was last current.  */

OK, I've committed a fix to trunk.  Instead of doing away with the BUF_*
macros, I reworked them to handle the indirect buffer case properly.
This means they can no longer be used in `BUF_PT (foo) = bar' assignment
statements, so I've changed the callers that used them this way.

Not sure if the patch is appropriate for the emacs-23 branch, though.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8219 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	emacs-devel <at> gnu.org
Subject: Re: bug#8219: Effect of deletions on indirect buffers (Bug#8219)
Date: Mon, 14 Mar 2011 03:41:41 +0100

> OK, I've committed a fix to trunk.  Instead of doing away with the BUF_*
> macros, I reworked them to handle the indirect buffer case properly.
> This means they can no longer be used in `BUF_PT (foo) = bar' assignment
> statements, so I've changed the callers that used them this way.

emacs -Q --eval '(clone-indirect-buffer "clone" nil)'

buffer.c:614: Emacs fatal error: assertion failed: NILP (BVAR (b, begv_marker))

Breakpoint 1, w32_abort () at w32fns.c:7208
7208      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7208
#1  0x01047867 in die (msg=0x1590744 "assertion failed: NILP (BVAR (b,
begv_marker))", file=0x158f518 "buffer.c", line=614) at alloc.c:6101
#2  0x010caa80 in Fmake_indirect_buffer (base_buffer=52342789,
name=54741601, clone=52303922) at buffer.c:614
#3  0x0103beb5 in Ffuncall (nargs=4, args=0x88f0c0) at eval.c:2849
#4  0x01142a8c in Fbyte_code (bytestr=20838137, vector=20838245,
maxdepth=16) at bytecode.c:689
#5  0x0103cbea in funcall_lambda (fun=20838093, nargs=2,
arg_vector=0x88f260) at eval.c:3028
#6  0x0103c620 in apply_lambda (fun=20838093, args=57330886,
eval_flag=1) at eval.c:2954
#7  0x0103a2bc in Feval (form=57330894) at eval.c:2296
#8  0x0103bd75 in Ffuncall (nargs=2, args=0x88f4b0) at eval.c:2842
#9  0x01142a8c in Fbyte_code (bytestr=20645329, vector=20645821,
maxdepth=40) at bytecode.c:689
#10 0x0103cbea in funcall_lambda (fun=20645301, nargs=1,
arg_vector=0x88f704) at eval.c:3028
#11 0x0103c2fc in Ffuncall (nargs=2, args=0x88f700) at eval.c:2891
#12 0x01142a8c in Fbyte_code (bytestr=20627337, vector=20628333,
maxdepth=28) at bytecode.c:689
#13 0x0103cbea in funcall_lambda (fun=20627317, nargs=0,
arg_vector=0x88f944) at eval.c:3028
#14 0x0103c2fc in Ffuncall (nargs=1, args=0x88f940) at eval.c:2891
#15 0x01142a8c in Fbyte_code (bytestr=20623889, vector=20624101,
maxdepth=24) at bytecode.c:689
#16 0x0103cbea in funcall_lambda (fun=20623869, nargs=0,
arg_vector=0x88faf0) at eval.c:3028
#17 0x0103c620 in apply_lambda (fun=20623869, args=52303898,
eval_flag=1) at eval.c:2954
#18 0x0103a2bc in Feval (form=52791574) at eval.c:2296
#19 0x0100537b in top_level_2 () at keyboard.c:1138
#20 0x010378f4 in internal_condition_case (bfun=0x1005368
<top_level_2>, handlers=52357530, hfun=0x1004e81 <cmd_error>) at
eval.c:1408
#21 0x010053ad in top_level_1 (ignore=52303898) at keyboard.c:1146
#22 0x01037313 in internal_catch (tag=52355626, func=0x100537d
<top_level_1>, arg=52303898) at eval.c:1152
#23 0x010052f1 in command_loop () at keyboard.c:1101
#24 0x01004573 in recursive_edit_1 () at keyboard.c:731
#25 0x01004a97 in Frecursive_edit () at keyboard.c:793
#26 0x01002797 in main (argc=4, argv=0xca2da8) at emacs.c:1684

Lisp Backtrace:
"make-indirect-buffer" (0x88f0c4)
"clone-indirect-buffer" (0x88f260)
"eval" (0x88f4b4)
"command-line-1" (0x88f704)
"command-line" (0x88f944)
"normal-top-level" (0x88faf0)

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8219 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	emacs-devel <at> gnu.org
Subject: Re: bug#8219: Effect of deletions on indirect buffers (Bug#8219)
Date: Mon, 14 Mar 2011 12:18:43 -0400

Juanma Barranquero <lekktu <at> gmail.com> writes:

>> OK, I've committed a fix to trunk.  Instead of doing away with the BUF_*
>> macros, I reworked them to handle the indirect buffer case properly.
>> This means they can no longer be used in `BUF_PT (foo) = bar' assignment
>> statements, so I've changed the callers that used them this way.
>
> emacs -Q --eval '(clone-indirect-buffer "clone" nil)'
>
> buffer.c:614: Emacs fatal error: assertion failed: NILP (BVAR (b, begv_marker))

Thanks for the catch.  This should be fixed now.

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: 8219-done <at> debbugs.gnu.org
Subject: Re: bug#8219: Effect of deletions on indirect buffers (Bug#8219)
Date: Sat, 19 Mar 2011 12:44:14 -0400

I have backported the trunk fix to the emacs-23 brach (there seems to be
no safer complete solutions).  Closing Bug#8219 and Bug#1242.

Previous Next

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