Chris Wright wrote:
>>/proc/N/status will tell you that a process has
>>a signal pending, but it won't tell you how many are pending).
>>
>>
>
>Suggestion for good place to display that info?
>
>
I guess another line in /proc/N/status:
SigQue: 0 0 0 0 0 0 0 123 0 0 1238 0 0 0 0 0 ... 0
Erm, this updated patch.
J
If we're sending a signal relating to a faulting instruction, then
always generate siginfo for that signal.
If the user has some unrelated process which has managed to consume
the user's entire allocation of siginfo, then signals will start being
delivered without
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
>
> >It's not quite inexplicable. It means that task has hit its limit for
> >pending signals ;-) But I agree, this should be fixed. I think I had
> >tested this with broken test cases, thanks for catching.
> >
> It's partic
Chris Wright wrote:
>It's not quite inexplicable. It means that task has hit its limit for
>pending signals ;-) But I agree, this should be fixed. I think I had
>tested this with broken test cases, thanks for catching.
>
>
It's particularly confusing for users, because it's a per-user limit
r
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Valgrind is critically dependent on getting siginfo with its synchronous
> (caused by an instruction fault) signals; if it gets, say, a SIGSEGV
> which doesn't have siginfo, it must terminate ASAP because it really
> can't make any more progress wi
Valgrind is critically dependent on getting siginfo with its synchronous
(caused by an instruction fault) signals; if it gets, say, a SIGSEGV
which doesn't have siginfo, it must terminate ASAP because it really
can't make any more progress without knowing what caused the SIGSEGV.
The trouble is th
6 matches
Mail list logo
