Is there a condition that could cause Photon or the library to
put a Photon process in SIGSTOP state. The Photon
process has threads, code is suppose to be protected
by PtEnter/PtLeave, just in case it could be related…
- Mario
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
Is there a condition that could cause Photon or the library to
put a Photon process in SIGSTOP state. The Photon
process has threads, code is suppose to be protected
by PtEnter/PtLeave, just in case it could be related…
I don’t think so.
Do you know it’s a SIGSTOP that’s stopping you? It could be a SIGTTIN or
something…
When you run the app from the shell (in the foreground) and it stops,
does the shell say something like "[1] + Stopped (signal) "?
You can run your app under GDB and set breakpoints on raise() and kill()
– this will at least tell you whether it’s a library or another
process…
\
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.
“Wojtek Lerch” <wojtek@qnx.com> wrote in message
news:9ds3uk$378$1@nntp.qnx.com…
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
Is there a condition that could cause Photon or the library to
put a Photon process in SIGSTOP state. The Photon
process has threads, code is suppose to be protected
by PtEnter/PtLeave, just in case it could be related…I don’t think so.
Do you know it’s a SIGSTOP that’s stopping you? It could be a SIGTTIN or
something…
Well pidin and spin says it’s in STOPPED state, we could set a trap
for SIGTTIN to figure it out I guess.
When you run the app from the shell (in the foreground) and it stops,
does the shell say something like "[1] + Stopped (signal) "?
We can’t , start it from the shell. It’s spawn by another program.
You can run your app under GDB and set breakpoints on raise() and kill()
– this will at least tell you whether it’s a library or another
process…
Good idea.
The funny thing is if we manually send SIGCONT the process dies (no
dump file)
I made the following observation: start vi then send it a SIGSTOP signal,
the shell will show the “Stopped…” messaged. But curiously pidin reports
vi is REPLY blocked on devc-pty??? I’ve tried other program such
as phcalc and they show being in STOPPED state. I don’t get it.
–
Wojtek Lerch (> wojtek@qnx.com> ) QNX Software Systems Ltd.
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
“Wojtek Lerch” <> wojtek@qnx.com> > wrote in message
news:9ds3uk$378$> 1@nntp.qnx.com> …
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
…
When you run the app from the shell (in the foreground) and it stops,
does the shell say something like "[1] + Stopped (signal) "?
We can’t , start it from the shell. It’s spawn by another program.
Then that other program could call waitpid() to find out what signal
stopped the child.
You can run your app under GDB and set breakpoints on raise() and kill()
– this will at least tell you whether it’s a library or another
process…Good idea.
The funny thing is if we manually send SIGCONT the process dies (no
dump file)
This sound like a library detecting that a crash is imminent, and trying
to give you a last chance to attach a debugger… Setting a breakpoint
on raise() should tell you whether that’s the case.
I made the following observation: start vi then send it a SIGSTOP signal,
the shell will show the “Stopped…” messaged. But curiously pidin reports
vi is REPLY blocked on devc-pty??? I’ve tried other program such
as phcalc and they show being in STOPPED state. I don’t get it.
I think if you send the SIGSTOP to a process that’s REPLY-blocked
already, it remains REPLY-blocked until it gets a reply – and then it
goes straight to STOPPED. You can see it even with phcalc, but you have
to make sure you’re not sending it any Photon events (I just tried and
succeeded). Of course, it’s easier with something simple like cat.
–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.
A co-worker figured it out! The system has dumper running. System
has compact flash, which averages 150K/sec write speed. The program
is around 5 meg in size. There is a sigsegv then dumper STOPs the
program while it’s being written to disk, it takes some much time writting
the 5Meg dump file that we had time to notice the STOP state what
nobody though of relating to dumper…
That will go in my bug of the month list 
“Wojtek Lerch” <wojtek@qnx.com> wrote in message
news:9du2qh$9ro$1@nntp.qnx.com…
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
“Wojtek Lerch” <> wojtek@qnx.com> > wrote in message
news:9ds3uk$378$> 1@nntp.qnx.com> …
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
…
When you run the app from the shell (in the foreground) and it stops,
does the shell say something like "[1] + Stopped (signal) "?
We can’t , start it from the shell. It’s spawn by another program.Then that other program could call waitpid() to find out what signal
stopped the child.You can run your app under GDB and set breakpoints on raise() and
kill()
– this will at least tell you whether it’s a library or another
process…Good idea.
The funny thing is if we manually send SIGCONT the process dies (no
dump file)This sound like a library detecting that a crash is imminent, and trying
to give you a last chance to attach a debugger… Setting a breakpoint
on raise() should tell you whether that’s the case.I made the following observation: start vi then send it a SIGSTOP
signal,
the shell will show the “Stopped…” messaged. But curiously pidin
reports
vi is REPLY blocked on devc-pty??? I’ve tried other program such
as phcalc and they show being in STOPPED state. I don’t get it.I think if you send the SIGSTOP to a process that’s REPLY-blocked
already, it remains REPLY-blocked until it gets a reply – and then it
goes straight to STOPPED. You can see it even with phcalc, but you have
to make sure you’re not sending it any Photon events (I just tried and
succeeded). Of course, it’s easier with something simple like cat.–
Wojtek Lerch (> wojtek@qnx.com> ) QNX Software Systems Ltd.
Mario Charest <mcharest@antispam_zinformatic.com> wrote:
A co-worker figured it out! The system has dumper running. System
has compact flash, which averages 150K/sec write speed. The program
is around 5 meg in size. There is a sigsegv then dumper STOPs the
program while it’s being written to disk, it takes some much time writting
the 5Meg dump file that we had time to notice the STOP state what
nobody though of relating to dumper…That will go in my bug of the month list >
Yeah, it is a good one…
–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.