Re: Minor before/after-change cleanup
Hrvoje Niksic <hniksic(a)iskon.hr> writes:
This patch cleans up some code in insdel.c and extents.c related to
reporting before and after change functions. It does not fix the
infamous modified-buffer-in-change-functions bug mentioned before.
The fix for that should come in later, if things are right. I've
separated this patch because it should be independent of the other,
and to make review easier.
Hi Hrvoje!
If this (too) is meant to fix the bug reported by me (wrt w3) then
sorry not yet. I've seen the page, but only while the core has been
dumped to the disk ;-(
Do we have sort of a "off by one error"?
norbert.
The backtracre reads:
(gdb) bt
#0 0x28467c78 in kill () from /usr/lib/libc.so.3
#1 0x8084519 in fatal_error_signal (sig=6) at emacs.c:278
#2 0xbfbfdfdc in ?? ()
#3 0x808447b in assert_failed (file=0x81dd9a2 "insdel.c", line=1117,
expr=0x81dd45d "BUFFER_LIVE_P (buf)") at emacs.c:2828
Here, the ASSERT fails, because the Bufpos are set to zero, therefore
- im running without Mule - IIRC also Bytind. The test against buffer
start, which expands to (Byteind) 1, thus fails.
#4 0x810c6af in bufpos_to_bytind (buf=0x82f8400, x=0) at insdel.c:1117
#5 0x80c9433 in report_extent_modification (buffer=137331712, start=0, end=0,
afterp=1) at extents.c:2272
signal_after_change changes start and end to 0, since all buffer
variables have this value (haven't been changed, yet?).
#6 0x8109b83 in signal_after_change (buf=0x82f8400, start=0, orig_end=2909,
new_end=0) at insdel.c:2320
#7 0x810a9f9 in buffer_insert_string_1 (buf=0x82f8400, pos=2909,
nonreloc=0xbfbfd0f4 ">\n", reloc=136603652, offset=0, length=2, flags=0)
at insdel.c:2594
What strikes me odd is, that the variable pos changed its value from
-1 to 2909 between these two calls (an optimisation issue?).
#8 0x810cee3 in buffer_insert_raw_string_1 (buf=0x82f8400, pos=-1,
nonreloc=0xbfbfd0f4 ">\n", length=2, flags=0) at insdel.c:2614
#9 0x812a951 in read_process_output (proc=145660416) at process.c:915