[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Jul 2016 02:37:18 -0700
From: Jorge Almeida <jjalmeida@...il.com>
To: musl@...ts.openwall.com
Subject: Re: abort() PID 1
On Mon, Jul 4, 2016 at 1:28 AM, Igmar Palsenberg <igmar@...senberg.com> wrote:
>
>
>>
>> -if process 1 calls abort() (regardless of what purpose that would fill), then:
>>
>> - if a handler was setup, it should be done whatever the handler does
>>
>> - if a handler was not setup, nothing should happen (as in:
>> process didn't receive any signal at all)
>
> Pid 1 can ignore sigkill / sigstop. "Normal" processes can't. "Normal"
> processes have defaults handling signals, pid 1 ignores all by default,
> unless it instructs the kernel it wants to receive it.
>
Yes, just what I said.
>>
>> What the standards say:
>>
>> (http://pubs.opengroup.org/onlinepubs/9699919799/)
>>
>> "The SIGABRT signal shall be sent to the calling process as if by
>> means of raise() with the argument SIGABRT."
>>
>> "The effect of the raise() function shall be equivalent to calling:
>>
>> pthread_kill(pthread_self(), sig);"
>>
>> man raise(3):
>> The raise() function sends a signal to the caling process or
>> thread. In a single-threaded program it is equivalent to
>> kill(getpid(), sig);
>>
>> So, what should " kill(1, SIGABRT)" do? It doesn't seem ambiguous to
>> me. IOW, there's nothing special about SIGABRT regarding PID 1.
>
> The "problem" in this case is that the "normal" abort() sends a SIGABRT,
> if that doesn't work, unblocks signals and retries.
> While that works with "normal" processes, it doesn't work with pid 1,
> because the default action on that process for SIGABRT isn't terminate.
As I see it: the process that issues abort() is really saying to the
kernel: "pretty please, send SIGABRT to this process--hey, that would
be me!" and the kernel replies "nope, you're process 1, I won't send
you anything" or else "sure, you have a signal handler, knock yourself
out". If the handler has something like _exit, this will cause a
kernel panic. Whoever writes the code may have a use for a panic on
demand, who knows? If the handler doesn't return, that's it, abort()
has done its job, per the man page. If the handler returns, abort()
must "restore the default disposition for SIGABRT and then raise the
signal a 2nd time"
--restoring the default disposition means removing the handler, and so
the 2nd time the kernel won't send a signal, and end of story.
I just can't see why there should be any remaining issue. Why shoul
there be any loop at all?
Thanks,
Jorge
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
