Travis Risner wrote:
>The application is the NetBeans IDE (6.0 M10). When it installs, it
>puts an icon in the dock, and that is what I use to start it. The
>NetBeans.app file actually starts running a Bash shell script, which
>collects a bunch of information, then starts the JVM (1.6 in this case)
>with a meter-long string of parameters. At that point it becomes a
>fully GUI application.
I suggest looking at the NetBeans manual, or asking on the NetBeans forum,
to learn where it sends its output streams like thread-dumps.
By the way, it may be that NetBeans runs with the -Xrs option, which
eliminates signal-handlers, so it won't do a thread-dump. See 'man javac'
and search for '-Xrs'.
There may be other things that NetBeans does with signal handlers. There's
no reason it couldn't do this, since a JNI lib can certainly change a
process's signal disposition.
>Thanks for explaining that QUIT only generates a thread dump. That was
>not mentioned in the man page. My experiences on prior Unix systems was
>that a kill of any kind would stop the program, unless trapped.
The QUIT signal *is* trapped (i.e. a signal handler is installed for it by
the JVM). That's how the JVM can generate a thread-dump instead of simply
terminating (the default behavior for an uncaught QUIT signal).
This is precisely explained in terms of Unix signals and handlers in the
explanation of the -Xrs option in 'man java'.
>You bring up the second aspect of my problem - where to find the dump.
>I found a binary file at /private/tmp/hsperfdata_travis/10626. (10626
>was the pid at the time.) It is about 32 KB in size. Obviously, I need
>something to translate it into text.
If it's binary, then I suspect these are not the droids, er thread-dumps,
you seek.
A thread-dump is plain text. It looks like a series of augmented exception
stack-traces (assuming you've never seen one before). It will not be in
binary, nor would it appear in a binary-seeming file unless your System.out
is getting a lot of non-Latin characters written to it.
Googling for:
/tmp/hsperfdata
leads me to suspect the file you've found is long-term HotSpot performance
optimization data:
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6563308>
It may or may not have a bearing on what you're ultimately trying to
accomplish, but I strongly doubt it's a thread-dump.
>Since I have apparently found the output of the trace, I don't think I
>need to download the massive amount of source code and start sticking
>printlns in it.
I don't think you've found the thread-dump output. I think you really need
to check the NetBeans reference docs, or ask a person with experience of
NetBeans output-streams (e.g. ask a question on a NetBeans forum), in order
to find out exactly where it redirects its System.out and System.err
streams. Guessing does not appear to be an effective strategy.
If the answer is "NetBeans doesn't redirect its output", then you should
look in console.log of the Console.app utility program, as Mike Hall
suggested earlier. You might want to do that before asking on a NetBeans
forum, just in case the prior thread-dumps are there, or can be induced to
appear by sending a QUIT signal to NetBeans while you watch the console.log.
You can write to the console.log manually in Terminal:
echo Hello to the log. >/dev/console
You can also get thread-dumps using 'jconsole', if NetBeans is run with JMX
active.
java -Dcom.sun.management.jmxremote ...
You could patch that into the meter-long command-line, or there's probably
a way to predefine system props in NetBeans. If there is, the manual
should tell you how. Or maybe there's even a GUI switch for it in NetBeans
itself.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
