Re: [Bug-readline] documentation of signal handling

[Chet Ramey]

On 4/29/16 10:53 PM, address@hidden wrote:
> Hi Chet,
> 
> Thank you for the advice. I think it would just be good to update the
> callback interface example in Readline to have this code, so that we
> can see how it is done in context. I think it would be good to have
> some short example programs for both the basic 'readline()' interface
> and for the callback interface, which
> 
> 1. handle SIGWINCH correctly
> 2. handle SIGINT in the same way as Bash, by clearing the line
> 
> Do you have any idea when you'll have time to finalize these?

I will get to them when it bubbles to the top of the priority list.

> 
> I still have a lot of confusion, for instance I noticed a recent
> message on this list where you say:
> 
>> This is probably the result of the same signal handling issues as with
>> SIGWINCH that we discussed a little more than a year ago.  Readline
>> catches the signal, sets a flag, and, when it's safe, resends it to the
>> calling application.  It expects that if the calling application catches
>> SIGINT, it will take care of cleaning up the readline state.  Sometimes
>> applications don't want to kill the current line on SIGINT.
> 
> As I understand it, if the application ignores SIGINT with SIG_IGN,
> then Readline will ignore it too. But if the application traps SIGINT,
> then Readline will catch it and pass it on to the application. When
> Readline next gets control it will call rl_free_line_state(), which
> deletes the undo list, clears the message area, and cancels any
> keyboard macros. You said "Sometimes applications don't want to kill
> the current line on SIGINT" but (1) do you know of any examples? 

Sure.  An interactive bash with line editing active that traps SIGINT.



(2)
> Why would such an application want Readline to delete the undo list,
> clear the message area, and cancel any keyboard macros, if it is not
> going to clear the line? I think application writers expect the line
> to be cleared, for example see:

Deleting the undo list might be iffy, but the others seem reasonable.

> 
> http://stackoverflow.com/questions/16828378/readline-get-a-new-prompt-on-sigint
> 
> Now, in the above Stackoverflow discussion, the poster is using the
> basic 'readline()' interfac. He solves the problem by using a
> 'siglongjmp' to get out of the SIGINT handler. Apparently user
> "jancheta" thinks that by using 'siglongjmp' instead of 'longjmp', the
> code will be safe from race conditions: "But because the longjmp would
> be in a signal handler, you need to use sigsetjmp/siglongjmp". I don't
> understand how this could be - if the signal arrives in the middle of
> a malloc(), then won't we still be corrupting some global state?

Neither longjmp nor siglongjmp is on the list of signal-safe functions.

> 
> (Please let me know if I'm mistaken about this. Does glibc block
> SIGINT around functions like malloc()?)

No.  glibc blocks SIGINT very rarely, but uses locks pervasively.

> 
> So apparently in addition to the isearch-SIGINT bug which affects the
> callback interface (creating a dangerous situation which causes
> undesired lines to be entered at the prompt!) there is also a problem
> in that users of the basic readline() interface don't even know how to
> safely achieve the familiar behavior of clearing a line on ^C.

Take a breath.  In this case, siglongjmp is probably ok, since you know
you're not interrupting any unsafe calls in the readline library code.
All the code I posted is safe to execute from a signal handler.  You can
clear the line by either running rl_done = 1 or

rl_line_buffer[rl_point = rl_end = rl_mark = 0] = 0;

It's the clearing readline state that's the bug.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/