in reply to application crash during WINCH Signal

kill

SIGNAL may be either a signal name (a string) or a signal number. A signal name may start with a SIG prefix, thus FOO and SIGFOO refer to the same signal. The string form of SIGNAL is recommended for portability because the same signal may have different numbers in different operating systems.

Is it worth using the name of the signal (as a string) throughout your code?

p.s. there was a question here some months ago about how resizing a terminal would crash some perl application. But I can't seem to find it.

EDIT: the link is this: Re: need help golfing down/making a backtrace for panic: free from wrong pool, … during global destruction. , and refers to a perl application crashing when terminal hosting it resizes.

  • Comment on Re: application crash during WINCH Signal

Replies are listed 'Best First'.
Re^2: application crash during WINCH Signal
by hanspr (Sexton) on Nov 28, 2019 at 15:24 UTC

    Hi bliako

    Sorry if I could not follow you comment, but the quote on the signal reference you did says that it is recommended to use the STRING, and not the numbers.

    We are recovering this application that it was unfortunately abandoned, so we are still getting familiar with the code.

    I did read the kill reference some time ago and I did not see any reason why change it.


    I changed the kill line to 
    kill 'WINCH' => $EXP -> pid if $EXP -> pid;

    [download]

    It made not difference

[reply]
[d/l]

      I was merely saying that using a signal name, e.g. kill "WINCH" => $pid is the most straight-forward way to specify a signal. I am not sure if using constant WINCH (like your code is doing) is as safe. That's why I mentioned it. At least you don't use numbers e.g. kill 10 => $pid which is obviously wrong non-portable.

      Your handler propagates the WINCH signal further down all the way to the shell. In your handler you can at least monitor the pids sent the WINCH and see which one crashes. Is it perl? Is it bash? Is it ssh?

      I have put the link about a WINCH-related crash in the post above.

[reply]
[d/l]
[select]

        I have monitored the pid with strace, or think I did, as in the first post. It is a bash shell, but I it happens with : bash, ssh, zsh.

        But essentialy is bash because the ssh connections are lunched using bash too.


        If I comment the complete WINCH routine, like this 
        #$SIG{'WINCH'} = sub {
#    if (!$CONNECTED) {
#        return 1;
#    }
#    while (!$EXP->slave) {
#        #select(undef, undef, undef, 0.1);
#    };
#    $EXP->slave->clone_winsize_from(\*STDIN);
#    kill 'WINCH' => $EXP -> pid if $EXP -> pid;
#    return 1;
#};

        [download]

        It will not get disconnected, but the terminal will not be aware of the window size change


        So, is in did something related to the propagation of the winch signal.
[reply]
[d/l]
Re^2: application crash during WINCH Signal
by hanspr (Sexton) on Nov 28, 2019 at 18:39 UTC

    Hi bliako

    Read the post, did not understood it, I know that resizing causes the problem.

[reply]

In Section Seekers of Perl Wisdom