J9 locked up tight on me..

System: Dual P3 933Mhz with 383M of ram running latest 6.2.1
(with PE supplement added)

I have a fairly simple project in the ide. I had been compiling and
running external tools (flexelint) and finally got it to the point I
wanted to update the cvs repo. I did a syncronise with repo command and
it caused J9 to hang. pidin output follows:

1097776 1 eclipse/jre/bin/j9 10r STOPPED
1097776 2 eclipse/jre/bin/j9 10r CONDVAR b8282850
1097776 3 eclipse/jre/bin/j9 10r CONDVAR b8282850
1097776 4 eclipse/jre/bin/j9 10r CONDVAR b8282850
1097776 5 eclipse/jre/bin/j9 10r STOPPED
1097776 6 eclipse/jre/bin/j9 9r CONDVAR b8282850
1097776 7 eclipse/jre/bin/j9 10r CONDVAR b8282850
1097776 8 eclipse/jre/bin/j9 6r STOPPED
1097776 9 eclipse/jre/bin/j9 10r CONDVAR b8282850
1097776 10 eclipse/jre/bin/j9 6r STOPPED
1097776 11 eclipse/jre/bin/j9 10r CONDVAR b8282850
1097776 12 eclipse/jre/bin/j9 10r STOPPED
1097776 13 eclipse/jre/bin/j9 10r STOPPED
1097776 14 eclipse/jre/bin/j9 10r MUTEX 1097776-13 #1

Note that thread #14 is blocked on a mutex owned by thread #13 which is
stopped.

Not only is this a pain, but I am unable to even kill the J9 instance
since it seems to ignore signals (including SIGCONT). This has happend
twice in as many days now. I suspect it has something to do with the
fact I am using an SMP machine and there is some deadlock that hasn’t
been noticed in J9. I am open to suggestions (and no I don’t want to
switch back to a non-SMP machine or use Windows to run the IDE. :frowning:)

Rick…

Rick Duff Internet: rick@astranetwork.com
Astra Network URL: http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

Rick Duff wrote:

System: Dual P3 933Mhz with 383M of ram running latest 6.2.1
(with PE supplement added)

I have a fairly simple project in the ide. I had been compiling and
running external tools (flexelint) and finally got it to the point I
wanted to update the cvs repo. I did a syncronise with repo command
and it caused J9 to hang. pidin output follows:

Just frozen, with no other messages, eh? I’ve not run the IDE on QNX yet,
but standard course of operations for J9 woes is to muck with the memory
settings (try “j9 -verbose:sizes X” to get the defaults. Not sure which
version of j9 you might be running either. Typically to pass additional
options to j9 from a eclipse-based ‘executable’, put a -vmargs line AT THE
END of your executable’s command line with the additional options you want
to use.

Ones you should try are -Xmso (native stack size) -Xmx (memory
maximum), -Xmr (remembered set size, although we haven’t seen problems
relating to this one in quite some time).

You should also try wince running without the JIT. Use “j9 -X” to tell
you how to do it. Older vms only use -Xnojit, newer ones should use -Xint
(actually, looks like even the newer ones respect -Xnojit). Typically this
is not helpful, as the IDE will run so much more slowly, but if it is the
JIT, there are some JIT options you can tweak.

Oh, and is it repeatable? It would be useful to know the j9 version (just
run “j9” and tell us the Target: date) and version of QNX. It’s interesting
to note that it occurred during a network operation, although to get it to
the point to sync to your repo, you’ve obviously connected to the repo
before, which was also a network operation.


Patrick Mueller
pmuellr@yahoo.com

Rick Duff <rick@astranetwork.com> wrote:

System: Dual P3 933Mhz with 383M of ram running latest 6.2.1
(with PE supplement added)

I have a fairly simple project in the ide. I had been compiling and
running external tools (flexelint) and finally got it to the point I
wanted to update the cvs repo. I did a syncronise with repo command and
it caused J9 to hang. pidin output follows:

This is a known problem in j9 v1.5. Hopefully we will have synced up our
releases well enough to have a newer j9 to run Eclipse in the next release
of the IDE.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Chris McKillop wrote:

Rick Duff <> rick@astranetwork.com> > wrote:

System: Dual P3 933Mhz with 383M of ram running latest 6.2.1
(with PE supplement added)

I have a fairly simple project in the ide. I had been compiling and
running external tools (flexelint) and finally got it to the point I
wanted to update the cvs repo. I did a syncronise with repo command and
it caused J9 to hang. pidin output follows:



This is a known problem in j9 v1.5. Hopefully we will have synced up our
releases well enough to have a newer j9 to run Eclipse in the next release
of the IDE.

Great… Is there anyway to kill j9 once it gets into this state? It is
bad enough having it happen, but having to reboot to fix it is so
windows like it makes me sick feeling…

\

Rick Duff Internet: rick@astranetwork.com
Astra Network URL: http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

Patrick Mueller wrote:

Rick Duff wrote:

System: Dual P3 933Mhz with 383M of ram running latest 6.2.1
(with PE supplement added)

I have a fairly simple project in the ide. I had been compiling and
running external tools (flexelint) and finally got it to the point I
wanted to update the cvs repo. I did a syncronise with repo command
and it caused J9 to hang. pidin output follows:


Just frozen, with no other messages, eh? I’ve not run the IDE on QNX yet,
but standard course of operations for J9 woes is to muck with the memory
settings (try “j9 -verbose:sizes X” to get the defaults. Not sure which
version of j9 you might be running either. Typically to pass additional
options to j9 from a eclipse-based ‘executable’, put a -vmargs line AT THE
END of your executable’s command line with the additional options you want
to use.

It has the modal dialog up saying the operation is in progress. And of

course it doesn’t repond to photon events at this point, so it is not
refreshed if obscured.

Ones you should try are -Xmso (native stack size) -Xmx (memory
maximum), -Xmr (remembered set size, although we haven’t seen problems
relating to this one in quite some time).

You should also try wince running without the JIT. Use “j9 -X” to tell
you how to do it. Older vms only use -Xnojit, newer ones should use -Xint
(actually, looks like even the newer ones respect -Xnojit). Typically this
is not helpful, as the IDE will run so much more slowly, but if it is the
JIT, there are some JIT options you can tweak.

Oh, and is it repeatable? It would be useful to know the j9 version (just
run “j9” and tell us the Target: date) and version of QNX. It’s interesting
to note that it occurred during a network operation, although to get it to
the point to sync to your repo, you’ve obviously connected to the repo
before, which was also a network operation.

J9 - VM for the Java™ platform, Version 1.5
(c) Copyright IBM Corp. 1991, 2002 All Rights Reserved
Target: 20020206 (QNX 6.2.1 x86)

It has repeated, but I am not sure exactly what steps it takes to repeat
it - and having to reboot to clean it up makes experimenting a tad
difficult.

Rick…

\

Rick Duff Internet: rick@astranetwork.com
Astra Network URL: http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

This is a known problem in j9 v1.5. Hopefully we will have synced up our
releases well enough to have a newer j9 to run Eclipse in the next release
of the IDE.

Great… Is there anyway to kill j9 once it gets into this state? It is
bad enough having it happen, but having to reboot to fix it is so
windows like it makes me sick feeling…

Not easily. They are using a ThreadCtl() to get those threads into that
STOPPED state. I’m not sure you can undo it from outside of the current
process. Attaching to it with gdb and restarting the threads might work,
but I don’t think it will.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

sigh
This reminds of an old discussion where it was pointed out that there HAS to
be a way in a system to kill a process unconditionally. In all Unixes that
would be kill -9, but somehow QNX can’t manage that much. This seems to be
such a basic thing … what the hell is the problem? Or what’s the excuse,
should I ask…

– igor

“Chris McKillop” <cdm@qnx.com> wrote in message
news:bf9dtc$72f$1@nntp.qnx.com

This is a known problem in j9 v1.5. Hopefully we will have synced up
our
releases well enough to have a newer j9 to run Eclipse in the next
release
of the IDE.

Great… Is there anyway to kill j9 once it gets into this state? It is
bad enough having it happen, but having to reboot to fix it is so
windows like it makes me sick feeling…


Not easily. They are using a ThreadCtl() to get those threads into that
STOPPED state. I’m not sure you can undo it from outside of the current
process. Attaching to it with gdb and restarting the threads might
work,
but I don’t think it will.

chris


Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Igor Kovalenko <kovalenko@attbi.com> wrote:

sigh
This reminds of an old discussion where it was pointed out that there HAS to
be a way in a system to kill a process unconditionally. In all Unixes that
would be kill -9, but somehow QNX can’t manage that much. This seems to be
such a basic thing … what the hell is the problem? Or what’s the excuse,
should I ask…

Here is why it is happening. There is a ThreadCtl() that lets you STOP all
the other threads in a process besides the calling one. Basically allowing
you to do self-debugging. So, just as when gdb is debugging a process you
cannot kill that process off without gdb letting it go through. This
particular ThreadCtl() was added specifically for jvm’s. Which is why I was
thinking you might be able to use gdb to go in, restart the threads and
kill the process off.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Chris McKillop wrote:

Here is why it is happening. There is a ThreadCtl() that lets you STOP all
the other threads in a process besides the calling one. Basically allowing
you to do self-debugging. So, just as when gdb is debugging a process you
cannot kill that process off without gdb letting it go through. This
particular ThreadCtl() was added specifically for jvm’s. Which is why I was
thinking you might be able to use gdb to go in, restart the threads and
kill the process off.

I’m with Igor here-it’s most annoying not being able to kill -9
something. This has happened to me with other drivers, but of course
I can’t remember now why/where/who…
Possibly for QNX supplied binaries this ThreadCtl must be removed?
I can understand having this feature for development, but once
released it’s useless without source code, no?

I’m with Igor here-it’s most annoying not being able to kill -9
something. This has happened to me with other drivers, but of course
I can’t remember now why/where/who…
Possibly for QNX supplied binaries this ThreadCtl must be removed?
I can understand having this feature for development, but once
released it’s useless without source code, no?

The JVM actually has to be able to make that call. I don’t belive that
any of the code QSS provides actually uses it.

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Patrick Mueller wrote:

You should also try wince running without the JIT.

This begs the question: Once you take the JIT out of wince, is there anything
left ? :wink:

Rennie

Chris McKillop wrote:

This is a known problem in j9 v1.5. Hopefully we will have synced up our
releases well enough to have a newer j9 to run Eclipse in the next release
of the IDE.

Great… Is there anyway to kill j9 once it gets into this state? It is
bad enough having it happen, but having to reboot to fix it is so
windows like it makes me sick feeling…



Not easily. They are using a ThreadCtl() to get those threads into that
STOPPED state. I’m not sure you can undo it from outside of the current
process. Attaching to it with gdb and restarting the threads might work,
but I don’t think it will.

So can we get slay modified to take a thread argument as well? It would
default to the first or only thread in an app, but would allow us to
place signals on a particular thread.

I think that would be a useful and backwards compatible fix - for this
and anyone other case where a thread other than #1 gets into a weird state.

Rick…


Rick Duff Internet: rick@astranetwork.com
Astra Network URL: http://www.astranetwork.com
QNX Consulting and Custom Programming Phone: +1 (204) 997-NETW (6389)

Rick Duff <rick@astranetwork.com> wrote:

Chris McKillop wrote:

This is a known problem in j9 v1.5. Hopefully we will have synced up our
releases well enough to have a newer j9 to run Eclipse in the next release
of the IDE.

Great… Is there anyway to kill j9 once it gets into this state? It is
bad enough having it happen, but having to reboot to fix it is so
windows like it makes me sick feeling…



Not easily. They are using a ThreadCtl() to get those threads into that
STOPPED state. I’m not sure you can undo it from outside of the current
process. Attaching to it with gdb and restarting the threads might work,
but I don’t think it will.


So can we get slay modified to take a thread argument as well? It would
default to the first or only thread in an app, but would allow us to
place signals on a particular thread.

'tis already in our head branch. No comment on when that will be available…
:v)


cburgess@qnx.com