Possible bug in xfns.c

Possible bug in xfns.c

[David Kastrup]

Throwing a signal restores interrupt_input_blocked to the state of the
recording of the stack frame.  In xfns.c, line 5207, we have a
BLOCK_INPUT.  In line 5283 we have

record_unwind_protect (clean_up_file_dialog, make_save_value (dialog, 0));

That means that clean_up_file_dialog will get called in case of an
abort, and x_file_dialog will return with the value of
interrupt_input_blocked increased by one as opposed to the time of the
call.

Shouldn't record_unwind_protect be enclosed with
UNBLOCK_INPUT/BLOCK_INPUT?

Note: I don't have much of a clue about the code, I am just trying to
dig for an abort.  The above certainly is not involved in the abort,
but while I am at it...

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Possible bug in xfns.c

[Jan D.]

2005-02-26 kl. 15.47 skrev David Kastrup:

>
> Throwing a signal restores interrupt_input_blocked to the state of the
> recording of the stack frame.

How does it do that?  I can't find that in the code.  I assumed 
record_unwind_protect did just that, recorded one unwind action to 
take.


>   In xfns.c, line 5207, we have a
> BLOCK_INPUT.  In line 5283 we have
>
> record_unwind_protect (clean_up_file_dialog, make_save_value (dialog, 
> 0));
>
> That means that clean_up_file_dialog will get called in case of an
> abort, and x_file_dialog will return with the value of
> interrupt_input_blocked increased by one as opposed to the time of the
> call.

I'm not sure what you mean by an abort.  The only code that does 
something like that is the Fsignal and the unbind_to after the 
UNBLOCK_INPUT.  Are you saying that

   BLOCK_INPUT;
   ...
   record_unwind_protect()
   ...
   UNBLOCK_INPUT;

   unbind_to();

will make interrupt_input_blocked have a value of 1 after the unbind_to 
(assuming it was 0 before BLOCK_INPUT and no code in ... throws)?

>
> Shouldn't record_unwind_protect be enclosed with
> UNBLOCK_INPUT/BLOCK_INPUT?

That wouldn't be correct, but we could move it before the first 
BLOCK_INPUT.

	Jan D.

Re: Possible bug in xfns.c

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> 2005-02-26 kl. 15.47 skrev David Kastrup:
>
>>
>> Throwing a signal restores interrupt_input_blocked to the state of
>> the recording of the stack frame.
>
> How does it do that?  I can't find that in the code.

Neither can I.  I said that I don't have a clue about the code
involved.  The main suspect in that area would be callers of
unwind_to_catch.  Seems I am mistaken about what record_unwind_protect
does.

Sorry for the confusion.  I am just trying to find out what makes my
Emacs crash.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Possible bug in xfns.c

[Richard Stallman]

       BLOCK_INPUT;
       ...
       record_unwind_protect()
       ...
       UNBLOCK_INPUT;

       unbind_to();

I think that code is correct.

Neither record_unwind_protect nor unbind_to does anything to
interrupt_input_blocked.  If there is no abnormal control transfer,
unbind_to will run the function that record_unwind_protect recorded,
and UNBLOCK_INPUT will undo the BLOCK_INPUT.

If there is an abnormal control transfer, it will run that function.
It will also restore interrupt_input_blocked to the proper value
corresponding to the place the error is caught.  Which is not in this
function.