"Manfred Bartz" <MBartz(a)xix.com&gt; writes: Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; writes: This might be a different bug from the one I fixed. This crash comes from signal_after_change() being called with START==0, which triggers the assert in bufpos_to_bytind. Also, the backtrace seems weird -- I wonder if it comes from an optimized build? buffer_insert_raw_string_1() gets pos==-1, but buffer_insert_string_1 gets pos==32100. I don't see code in buffer_insert_raw_string_1() that handles that, but I suppose the optimizer could have done that. Now, the really strange thing is the call to signal_after_change(). In my copy of the code, it looks like this: signal_after_change (buf, pos, pos, pos + cclen); UNGCPRO; return cclen; } Notice that the first and the second argument are the same. In the backtrace, they're not. The only sense I can make out of it is that the crash doesn't come from that call to signal_after_change(). What could happen is that buffer_insert_string_1() calls prepare_to_modify_buffer(), which calls signal_before_change(), which can call cancel_multiple_change(), which calls signal_after_change(). The funcalls could be invisible due to optimizer having inlined them in the code -- this is possible because all of the functions involved are static. I'm not sure whether this theory holds water, because nothing in the backtrace seems to point to any code that calls begin_multiple_change. read_process_output() does play weird games with narrowing, though.