Hrvoje Niksic <hniksic(a)iskon.hr&gt; writes: 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