Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.
Murf
John Murphy <murf@perftech.com> wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.
“attach” to them from gdb?
John Murphy <murf@perftech.com> wrote:
Thought of that one. You can “attach, kill, quit”, and gdb acts like it’s
happy to comply - but the STOPPED process is still there, and still STOPPED.
On the rare occasions I saw this (trying to do fiendish “on -h”
debugging to keep stdio on remote machine) an “attach”, “continue”
did the trick (or maybe it was just attach/detach that gave it a
kick), certainly never tried to kill it. Sorry that didn’t help …
Thought of that one. You can “attach, kill, quit”, and gdb acts like it’s
happy to comply - but the STOPPED process is still there, and still STOPPED.
Murf
John Garvey wrote:
John Murphy <> murf@perftech.com> > wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.“attach” to them from gdb?
Actually, I tried that first. It either had no effect or hung gdb.
Murf
John Garvey wrote:
John Murphy <> murf@perftech.com> > wrote:
Thought of that one. You can “attach, kill, quit”, and gdb acts like it’s
happy to comply - but the STOPPED process is still there, and still STOPPED.On the rare occasions I saw this (trying to do fiendish “on -h”
debugging to keep stdio on remote machine) an “attach”, “continue”
did the trick (or maybe it was just attach/detach that gave it a
kick), certainly never tried to kill it. Sorry that didn’t help …
John Murphy <murf@perftech.com> wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.Murf
If pdebug is involved, try slaying it.
-seanb
That sounds like one them GUI things; I don’t do GUI’s. But thanks for
the suggestion!
Murf
Sean Boudreau wrote:
John Murphy <> murf@perftech.com> > wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.Murf
If pdebug is involved, try slaying it.
-seanb
Oops, my mistake; apparently pdebug has nothing whatsoever to do with
GUI’s. But the fact that I hadn’t even heard of it pretty much rules it
out as part of the problem.
Murf
“John A. Murphy” wrote:
That sounds like one them GUI things; I don’t do GUI’s. But thanks for
the suggestion!Murf
Sean Boudreau wrote:
John Murphy <> murf@perftech.com> > wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.Murf
If pdebug is involved, try slaying it.
-seanb
John A. Murphy <murf@perftech.com> wrote:
Oops, my mistake; apparently pdebug has nothing whatsoever to do with
GUI’s. But the fact that I hadn’t even heard of it pretty much rules it
out as part of the problem.Murf
A simple pidin will confirm one way or the other. gdb can
start it for you depending on your usage.
-seanb
Not sure I follow all that, but pidin shows four programs, including
ntox86/2.95.3/ccp0, in STOPPED state, and no evidence of pdebug.
Murf
Sean Boudreau wrote:
John A. Murphy <> murf@perftech.com> > wrote:
Oops, my mistake; apparently pdebug has nothing whatsoever to do with
GUI’s. But the fact that I hadn’t even heard of it pretty much rules it
out as part of the problem.Murf
A simple pidin will confirm one way or the other. gdb can
start it for you depending on your usage.-seanb
In theory, a SIGCONT should do the trick. If the app has got itself
into a stopped state then it might just go back into stop afterwards
though. I’ve had luck with a SIGKILL, then a SIGCONT to get it going
long enough to notice the kill. YMMV though.
cheers,
Kris
John Murphy wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.Murf
It is hillarious to watch how so many smart people discuss how to get out of
the STOPPED stated that process should not have gotten into in the first
place. No energy being spent to find out why does it happen 
“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:c0imug$7ha$1@inn.qnx.com…
In theory, a SIGCONT should do the trick. If the app has got itself
into a stopped state then it might just go back into stop afterwards
though. I’ve had luck with a SIGKILL, then a SIGCONT to get it going
long enough to notice the kill. YMMV though.cheers,
Kris
John Murphy wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.Murf
I’ve tried that too; no cigar. But thanks for the suggestion!
Murf
Kris Warkentin wrote:
In theory, a SIGCONT should do the trick. If the app has got itself
into a stopped state then it might just go back into stop afterwards
though. I’ve had luck with a SIGKILL, then a SIGCONT to get it going
long enough to notice the kill. YMMV though.cheers,
Kris
John Murphy wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.Murf
Well, I was hoping that had changed since the last time this discussion was
held, but apparently not. Until someone who’s in a position to DO something
about it decides it’s of interest, about the most we victims can do is look for
a way out.
Murf
Igor Kovalenko wrote:
It is hillarious to watch how so many smart people discuss how to get out of
the STOPPED stated that process should not have gotten into in the first
place. No energy being spent to find out why does it happen >“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:c0imug$7ha$> 1@inn.qnx.com> …
In theory, a SIGCONT should do the trick. If the app has got itself
into a stopped state then it might just go back into stop afterwards
though. I’ve had luck with a SIGKILL, then a SIGCONT to get it going
long enough to notice the kill. YMMV though.cheers,
Kris
John Murphy wrote:
Has anyone ever come up with a way to get rid of all those programs that
get themselves into STOPPED state? I know this has been discussed
before, and that the generic answer is that “it can’t happen”, but it
does happen, and I hate to have to reboot the system just to get rid of
them.Murf
“John Murphy” <murf@perftech.com> wrote in message
news:402CF1C4.129D9023@perftech.com…
Well, I was hoping that had changed since the last time this discussion
was
held, but apparently not. Until someone who’s in a position to DO
something
about it decides it’s of interest, about the most we victims can do is
look for
a way out.
Do you already have an open ticket on this issue?
What release is this with? What does pidin, pidin sig, and pidin fam
report? Is it always with a common set of processes exhibiting this
behaviour? What type of x86 environment is this (pidin in)? Does this only
happen in the shell you’re using or have you seen it with other shells?
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
Adam Mallory wrote:
“John Murphy” <> murf@perftech.com> > wrote in message
news:> 402CF1C4.129D9023@perftech.com> …
Well, I was hoping that had changed since the last time this discussion
was
held, but apparently not. Until someone who’s in a position to DO
something
about it decides it’s of interest, about the most we victims can do is
look for
a way out.Do you already have an open ticket on this issue?
What release is this with? What does pidin, pidin sig, and pidin fam
report? Is it always with a common set of processes exhibiting this
behaviour? What type of x86 environment is this (pidin in)? Does this only
happen in the shell you’re using or have you seen it with other shells?–
Cheers,
AdamQNX Software Systems Ltd.
[ > amallory@qnx.com > ]With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
No, I don’t have an open ticket on it. It seems to pop up in the new groups
often enough that I hadn’t thought of that. Besides, it not (so far) a problem
in production, just an annoyance in development. I’m running 6.2.0. Here’s a
log of the requested pidin’s, all filtered on the four processes stopped at the
moment:
pidin | fgrep -e 328691760 -e 295043125 -e 343875649 -e 296992837
328691760 1 ./picinfo 10o STOPPED
295043125 1 ./monitor 10o STOPPED
343875649 1 ./katest 10o STOPPED
296992837 1 ntox86/2.95.3/cpp0 9o STOPPED
pidin sig | fgrep -e 328691760 -e 295043125 -e 343875649 -e 296992837
328691760 1 ./picinfo 0000000000000000 0000000000000000
295043125 1 ./monitor 0000000000000000 0000000000000000
343875649 1 ./katest 0000000000001000 0000000000000000
296992837 1 ntox86/2.95.3/cpp0 0000000000000000 0000000000000000
pidin fam | fgrep -e 328691760 -e 295043125 -e 343875649 -e 296992837
1 /sys/procnto-instr 1 1 343875649
296161315 ./statsd 148217918 296161315 1 296992837
328691760 ./picinfo 296521778 328691760 1 325886019
295043125 ./monitor 148217918 295043125 1 296161315
343875649 ./katest 297037871 343875649 1 340742215
296992837 ntox86/2.95.3/cpp0 1355824 296976428 1 258473994
325890118 bin/sh 180244 325886017 1 295043125 325890123
340742215 /director/bdclient 337399849 340734017 1 328691760
I always use the same shell (/bin/sh), so I don’t know if it happens with
others. The common feature, other than the case of cpp, seems to be programs
with really nasty bugs: the stopped picinfo was accidently moved to the machine
via an FTP that was in ASCII mode, and monitor and katest almost certainly had
stack overflows. Other than clearly broken code, cpp is the only thing I can
think of that gets into this mode, and it (cpp) has done it several times.
Thanks for your interest!
Murf
Aha!!! I discovered that dumper was REPLY blocked on
/sys/procnto-instr. Once I killed dumper all the stopped processes
disappeared.
Murf
Adam Mallory wrote:
“John Murphy” <> murf@perftech.com> > wrote in message
news:> 402CF1C4.129D9023@perftech.com> …
Well, I was hoping that had changed since the last time this discussion
was
held, but apparently not. Until someone who’s in a position to DO
something
about it decides it’s of interest, about the most we victims can do is
look for
a way out.Do you already have an open ticket on this issue?
What release is this with? What does pidin, pidin sig, and pidin fam
report? Is it always with a common set of processes exhibiting this
behaviour? What type of x86 environment is this (pidin in)? Does this only
happen in the shell you’re using or have you seen it with other shells?–
Cheers,
AdamQNX Software Systems Ltd.
[ > amallory@qnx.com > ]With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
Good catch! - I was going to ask for the full pidin, since pidin fam isn’t
much use filtered 
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
“John A. Murphy” <murf@perftech.com> wrote in message
news:402D1B1C.BF49D14@perftech.com…
Aha!!! I discovered that dumper was REPLY blocked on
/sys/procnto-instr. Once I killed dumper all the stopped processes
disappeared.Murf
Adam Mallory wrote:
“John Murphy” <> murf@perftech.com> > wrote in message
news:> 402CF1C4.129D9023@perftech.com> …
Well, I was hoping that had changed since the last time this
discussion
was
held, but apparently not. Until someone who’s in a position to DO
something
about it decides it’s of interest, about the most we victims can do is
look for
a way out.Do you already have an open ticket on this issue?
What release is this with? What does pidin, pidin sig, and pidin fam
report? Is it always with a common set of processes exhibiting this
behaviour? What type of x86 environment is this (pidin in)? Does this
only
happen in the shell you’re using or have you seen it with other shells?–
Cheers,
AdamQNX Software Systems Ltd.
[ > amallory@qnx.com > ]With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
I guess it should have hit me much sooner that all these processes
SHOULD have dumped. Now, I wonder what happened to dumper to cause IT
to get jammed up…
Murf
Adam Mallory wrote:
Good catch! - I was going to ask for the full pidin, since pidin fam isn’t
much use filtered >–
Cheers,
AdamQNX Software Systems Ltd.
[ > amallory@qnx.com > ]With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net“John A. Murphy” <> murf@perftech.com> > wrote in message
news:> 402D1B1C.BF49D14@perftech.com> …
Aha!!! I discovered that dumper was REPLY blocked on
/sys/procnto-instr. Once I killed dumper all the stopped processes
disappeared.Murf
Adam Mallory wrote:
“John Murphy” <> murf@perftech.com> > wrote in message
news:> 402CF1C4.129D9023@perftech.com> …
Well, I was hoping that had changed since the last time this
discussion
was
held, but apparently not. Until someone who’s in a position to DO
something
about it decides it’s of interest, about the most we victims can do is
look for
a way out.Do you already have an open ticket on this issue?
What release is this with? What does pidin, pidin sig, and pidin fam
report? Is it always with a common set of processes exhibiting this
behaviour? What type of x86 environment is this (pidin in)? Does this
only
happen in the shell you’re using or have you seen it with other shells?–
Cheers,
AdamQNX Software Systems Ltd.
[ > amallory@qnx.com > ]With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net