Re: C-g crash redux

[Kim F. Storm]

Chong Yidong <address@hidden> writes:

>>> Emacs can be made to crash simply by evaluating (sit-for 4) in the scratch
>>> buffer and typing C-g before four seconds elapse.
>>>
>>> It's due to this change:
>>>
>>> 2006-08-01  Kim F. Storm  <address@hidden>
>>>
>>>     * process.c (wait_reading_process_output_unwind): New function.
>>>     Restores waiting_for_user_input_p to saved value.
>>>     (wait_reading_process_output): Unwind protect waiting_for_user_input_p
>>>     instead of save/restore old value on stack.
>>>
>>> Presumably wait_reading_process_output is interrupted before it can do:
>>>
>>>   unbind_to (count, Qnil);
>>
>> Huh?  Is that really possible?
>>
>> What kind of interrupt can cause unwind_protect forms NOT to be run?
>
> Typing C-g, which runs interrupt_signal, runs quit_throw_to_read_char
> instead of Fsignal during when waiting_for_input is set (as it is
> during wait_reading_process_output).  If I understand correctly, the
> purpose is to enable read-char to return a `C-g' character; and that's
> why it's both undesirable and unnecesssary to use a
> record_unwind_protect inside wait_reading_process_output.

Ok, I see.


>
> I'll go ahead and revert the 2006-08-01 change.

Thanks.

But how do we ensure that waiting_for_user_input_p is restored
correctly on C-g?

Or isn't that necessary?

-- 
Kim F. Storm <address@hidden> http://www.cua.dk