In amongst all this dialog, was it ever explained what the STOPPED state
actually is and how to recover from it? If so, I’ve missed it.
Geoff.
Miguel Simon wrote:
Hi Chris…
For eclipse running rtp6.2.0-PE, could I update the j9 to v2.0? If so,
how? Thanks.
Regards…
Miguel.
Chris McKillop wrote:
Sounds like you know something (btw: I’m back at work so I can’t try
this until Friday). If you could enlighten me as to what effect
disabling the jit would have on the vm (besides slowing it down > > ,
that might prevent threads getting into an unslayable STOPPED state, I’d
be mighty appreciative.
Actually, oddly enough, disabling the jit makes it faster. > > There
are some places where it will get slower (like compiling java code), but
there are pretty high latencies and startup costs with the jit in j9 v1.5.
These make the UI performance worse and startup time longer and we have
disabled it for 6.2.1.
There are also bugs where the jvm can get itself into a bad state with the
jit enabled. Been narrowed down by QSS and fixed by OTI already (for j9
v2.0) but still exist with j9 v1.5. Happens most often with network
API calls, but has also exhibited itself in other odd behavior.
chris
–
Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA
This state is like the game when people yell ‘freeze’ and others are
supposed to freeze immediately in whatever position they were. Normal way of
getting into is SIGSTOP. Normal way of getting out is SIGCONT. It will
continue from the point where it stopped.
In amongst all this dialog, was it ever explained what the STOPPED state
actually is and how to recover from it? If so, I’ve missed it.
Geoff.
Miguel Simon wrote:
Hi Chris…
For eclipse running rtp6.2.0-PE, could I update the j9 to v2.0? If so,
how? Thanks.
Regards…
Miguel.
Chris McKillop wrote:
Sounds like you know something (btw: I’m back at work so I can’t try
this until Friday). If you could enlighten me as to what effect
disabling the jit would have on the vm (besides slowing it down > > ,
that might prevent threads getting into an unslayable STOPPED state,
I’d
be mighty appreciative.
Actually, oddly enough, disabling the jit makes it faster. > > There
are some places where it will get slower (like compiling java code),
but
there are pretty high latencies and startup costs with the jit in j9
v1.5.
These make the UI performance worse and startup time longer and we
have
disabled it for 6.2.1.
There are also bugs where the jvm can get itself into a bad state with
the
jit enabled. Been narrowed down by QSS and fixed by OTI already (for
j9
v2.0) but still exist with j9 v1.5. Happens most often with network
API calls, but has also exhibited itself in other odd behavior.
chris
\
Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA
For eclipse running rtp6.2.0-PE, could I update the j9 to v2.0? If so,
how? Thanks.
Not without other side-effects I am afraid. Plus, the manner in which
j9 is now distributed by IBM for QNX does not include many of the bits
you might want for doing any java development.
Best to wait for a j9 v2.0 from QSS.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll – http://qnx.wox.org/
This state is like the game when people yell ‘freeze’ and others are
supposed to freeze immediately in whatever position they were. Normal way of
getting into is SIGSTOP. Normal way of getting out is SIGCONT. It will
continue from the point where it stopped.
However, there is nothing “normal” about the particular STOPPED state
we are discussing.
The process with threads in this STOPPED state cannot be killed (not
SIGKILL, not SIGCONT, not SIGSEGV… nothing can kill it).
Yes I know. This is a bit that QNX has screwed up indeed. The ‘unmaskable’
signals like SIGKILL should ALWAYS work, that is the reason why they exist.
But they don’t
Igor Kovalenko wrote:
This state is like the game when people yell ‘freeze’ and others are
supposed to freeze immediately in whatever position they were. Normal
way of
getting into is SIGSTOP. Normal way of getting out is SIGCONT. It will
continue from the point where it stopped.
However, there is nothing “normal” about the particular STOPPED state
we are discussing.
The process with threads in this STOPPED state cannot be killed (not
SIGKILL, not SIGCONT, not SIGSEGV… nothing can kill it).
There are occasions when it isn’t possible to kill off QNX4 processes
also. But rare I admit. The instance (in QNX6) that prompted me to
start this thread has not re-occured but was certainly bizarre.
Referencing a NULL pointer from within an ISR resulted not in the
process or OS crashing, but instead it made the process immortal!?!?
I’m moving on.
Geoff.
Igor Kovalenko wrote:
Yes I know. This is a bit that QNX has screwed up indeed. The ‘unmaskable’
signals like SIGKILL should ALWAYS work, that is the reason why they exist.
But they don’t >
“Rennie Allen” <> rgallen@attbi.com> > wrote in message
news:at0rbf$ri9$> 1@inn.qnx.com> …
Igor Kovalenko wrote:
This state is like the game when people yell ‘freeze’ and others are
supposed to freeze immediately in whatever position they were. Normal
way of
getting into is SIGSTOP. Normal way of getting out is SIGCONT. It will
continue from the point where it stopped.
However, there is nothing “normal” about the particular STOPPED state
we are discussing.
The process with threads in this STOPPED state cannot be killed (not
SIGKILL, not SIGCONT, not SIGSEGV… nothing can kill it).
Rennie
–
Realtime Technology Systems Pty Ltd
2 Hadleigh Circuit
Isabella Plains
ACT 2905
AUSTRALIA
Igor Kovalenko wrote:
This state is like the game when people yell ‘freeze’ and others are
supposed to freeze immediately in whatever position they were. Normal way of
getting into is SIGSTOP. Normal way of getting out is SIGCONT. It will
continue from the point where it stopped.
However, there is nothing “normal” about the particular STOPPED state
we are discussing.
The process with threads in this STOPPED state cannot be killed (not
SIGKILL, not SIGCONT, not SIGSEGV… nothing can kill it).
There are occasions when it isn’t possible to kill off QNX4 processes
also. But rare I admit. The instance (in QNX6) that prompted me to
start this thread has not re-occured but was certainly bizarre.
Referencing a NULL pointer from within an ISR resulted not in the
process or OS crashing, but instead it made the process immortal!?!?
Threads (processes under QNX4) have to run to receive a signal and
die (even the KILL signal).
If the thread (process) can’t run, either due to being STOPPED or due
to being pre-empted (something running READY at a higher priority) it
will not die.
There are occasions when it isn’t possible to kill off QNX4 processes
also. But rare I admit. The instance (in QNX6) that prompted me to
start this thread has not re-occured but was certainly bizarre.
Referencing a NULL pointer from within an ISR resulted not in the
process or OS crashing, but instead it made the process immortal!?!?
Threads (processes under QNX4) have to run to receive a signal and
die (even the KILL signal).
If the thread (process) can’t run, either due to being STOPPED or due
to being pre-empted (something running READY at a higher priority) it
will not die.
This is expected.
No. This is not expected. Threads should not enter a STOPPED
state by themselves, and not be able to be restarted when
nothing is RUNNING at a higher priority, and cannot be
restarted by issuing a SIGCONT. I have no problem with a
thread having to run to die, but I do have a problem with
threads going STOPPED, under otherwise normal circumstances,
and not being able to restart them, or kill them in any
way (other than to reboot the computer).
I realize, the point your making here, but I don’t want this
thread to look like its ending with a “this is expected”
conclusion. What I am seeing is definately not “expected”
behaviour.
Actually, this is perfectly normal for a STOPPED thread - it can’t run, so
how can a signal be delivered? The same happened under QNX4.
Normally a thread only get’s stopped by the debugger or the SIGSTOP signal.
Same goes as my response to dagibbs. No. No. No. This is not
expected. No debugger put the threads in a STOPPED state, no
thread is running at a high priority. The system is completely
normal except for the fact that one process has several
STOPPED threads (along with several threads -in the same
process - that are not stopped, and otherwise appear normal),
with no explanation for how they got in that state. As I said
elsewhere I have no problem with a thread needing to run to
process a signal, I do have a problem with threads randomly
entering the STOPPED state for no apparent reason. Isn’t
STOPPED the equivalent of HELD under QNX4 ? I can drop a
SIGCONT on a HELD process in QNX4, and it resumes (so there
must be some special exception for SIGCONT - that the thread
doesn’t need to run - seems it should be able to be done in
a proc thread, since it is surely nothing more than a flag in
the thread control structure ?).
j9 seems to be the process that is the lightning rod for this
behavior, but I have seen io-net also do this. j9 is much
better now (I can run for many hours) since I disable the jit
(thanks Chris), but I have seen the problem happen once since
disabling the jit.
Perhaps this is dumper doing this, whatever it is, it shouldn’t
be doing it, and I see no reason why dropping a SIGCONT on the
process, shouldn’t UNSTOP all STOPPED threads in that process.
What I was saying was expected was that a STOPPED thread would not
die.
And, that a preempted thread, even if hit with SIGKILL would not die.
QNX4 didn’t even have threads.
I’m guessing it had at least one per process
Threads should not enter a STOPPED
state by themselves, and not be able to be restarted when
nothing is RUNNING at a higher priority, and cannot be
restarted by issuing a SIGCONT. I have no problem with a
thread having to run to die, but I do have a problem with
threads going STOPPED, under otherwise normal circumstances,
and not being able to restart them, or kill them in any
way (other than to reboot the computer).
The threads going STOPPED for no apparent reason is not expected.
I was not trying to say that was, only that the unkillability
of STOPPED (or pre-empted) threads was.
Unkillability should not be expected either (assuming - as I am -
perhaps incorrectly) that STOPPED == HELD. Under QNX4 setting
a SIGCONT on a HELD process, resumed the process. There has to be
some way of getting a STOPPED thread running again; otherwise,
you might as well tie the STOPPED state to a handler that
executes a processor reset, for all the use it would be…
I assume that under QNX4 Proc “special cased” SIGCONT (and that
it was never actually delivered to the process).
There are occasions when it isn’t possible to kill off QNX4 processes
also. But rare I admit. The instance (in QNX6) that prompted me to
start this thread has not re-occured but was certainly bizarre.
Referencing a NULL pointer from within an ISR resulted not in the
process or OS crashing, but instead it made the process immortal!?!?
Threads (processes under QNX4) have to run to receive a signal and
die (even the KILL signal).
If the thread (process) can’t run, either due to being STOPPED or due
to being pre-empted (something running READY at a higher priority) it
will not die.
This is expected.
No. This is not expected.
What I was saying was expected was that a STOPPED thread would not
die.
And, that a preempted thread, even if hit with SIGKILL would not die.
QNX4 didn’t even have threads.
Threads should not enter a STOPPED
state by themselves, and not be able to be restarted when
nothing is RUNNING at a higher priority, and cannot be
restarted by issuing a SIGCONT. I have no problem with a
thread having to run to die, but I do have a problem with
threads going STOPPED, under otherwise normal circumstances,
and not being able to restart them, or kill them in any
way (other than to reboot the computer).
The threads going STOPPED for no apparent reason is not expected.
I was not trying to say that was, only that the unkillability
of STOPPED (or pre-empted) threads was.
> ,
> There
