This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have a java program that I'm trying to profile. Unfortunately there is a bit of JNI code that the java calls, and the JNI code actually changes the working directory of the process on the fly, so if you view the process with something like Process Explorer from Sysinternals, you will see the working directory change over time. If I dont get the profiler attached to the JVM within the extremely small window of between when the JVM is started and when its working directory gets changed, I am never able to establish my profiling connection. This is especially annoying when I really dont wish to have the overhead of profiling until the application has been up after several hours. Can the profilerinterface code that writes the temp file out to the "working directory" be enhanced to be able to be overriden by a command line parameter, so that it doesn't rely on the working directory of the java process to stay constant for the whole lifecycle of the java process?
Upon a more close inspection, I realize that I don't really understand this request. To make the things more clear, here is how the attachment mechanism currently works. The tool writes a file called introspect.hotspot into the directory specified by the user. That file contains information for the target JVM about, essentially, a native library to load, and parameters of the entrypoint function in that native library. When the user hits Ctrl+Break or sends a signal to the JVM, the latter goes to its current directory, that I believe it obtains using the OS function to get the current dir (getcwd() or something) and looks for the introspect.hotspot file in it. Interestingly, there may be an inconsistency between the System.getProperty("user.dir") and the actual working directory, since I think user.dir is set only once, at startup time. Now, why do you say you are never able to attach the tool to the JVM once the working dir has changed? I think it should be ok to just specify the value of the JVM's current working dir, that you say you can look up in the Process Explorer...
Correct, but one of my other eventual wants to to have an automated profiling mechanism where I do not have to do anything manually. If there was a way to feed in via command line the directory where the JVM will look for this file, then when I'm doing this interactively, I wouldn't have to take an extra step to figure out where the current directory is now (and possibly could change the few seconds between when I look and when I enter it into the dialog). Or if it could use System.getProperty("user.dir") instead of the process's current working directory, that would fix the problems this causes me as well. When I get a more automated profiling system working, if I could just always specify the directory where the JVM will read the file, then its at a fixed location and I can be assured it will work correctly. -Jon
So end result: if System.getProperty("user.dir") instead of the process's current working directory was used, this would solve all my problems... is this something easily done?
Yes, this can be done, though it will require a modification to our custom JVM. That, for one thing, makes fixing this issue a somewhat longer/more complex thing. On the other hand, there are one or two other minor modifications to the JVM that are desirable. So I'll look into this, though I can't 100% guarantee the fix at this moment.
Fixed as specified, i.e. the VM now uses the value of "user.dir" property to lookup the introspection information file, no matter what the current directory is. The code will become available in M4 release.
Verification of old issues.
Closing old issues.
Reverting to the original Target Milestone value changed by mistake. Sorry for inconvenience.