There is a jvm in a shared vm. Other developer may remote debugging by idea, and cause hang up at breakpoints.
In some reason, I need to continue the process.
I've programed an agent with jvmti, tried to receive breakpoint events for clearing them. But there are no events received.
What is the right way to receive setbreakpoint event? Or any other way to stop hangup from remote?
Thanks in advance.
In HotSpot JVM, can_generate_breakpoint_events is an exclusive capability - this means, only one JVM TI agent at a time may possess this capability.
The standard jdwp agent used for remote debugging is also a JVM TI agent. When it is loaded, no other JVM TI agent may acquire can_generate_breakpoint_events capability. As a result, your agent will not be able to set/clear breakpoints or receive breakpoint events.
What you may try to do is to modify the original libjdwp instead of trying to intercept breakpoint events in your separate agent. Or even simpler - forcibly close jdwp connections whenever you want to resume the suspended application.
Related
I am evaluating Jprofiler.
In this process, i tried to attach a profiling scheme to a java process on a remote machine.
it provided a profiling port number, using which could connect to remote process and proceed.
But, once a profiling port is attached, i did not find anyway to de-associate the profiling port from the java process.
I would like to know if there is anyway to remove the profiling port from the java process without killing the java process.
Would appreciate your response.
Thank you very much.
Dev
There is no way to do that because the JVM does not provide a way to unload an agent.
I am working on an (console) application, which should be executed on startup and keeps running all the time in the background (executing something every 30 minutes).
How can I, in another (device) application, check if my console application is running (and start it if its not)?I am using VB.NET CF 2.0 and everything is being deployed on a device running WM 6.5
All the code examples I found where only available on the "standard" .NET.
There are several ways your "monitoring" app could work (and certainly more than I list here).
Use a named mutex (you'll have to P/Invoke it). The monitored app would create and hold it, and the monitoring app would periodically check to make sure it's held. If it's not held, the monitored app is no longer running.
Use the Toolhelp APIs. Have the monitoring app use the Toolhelp APIs to periodically enumerate the running processes. If the monitored app is not in the process list, it is not running.
Use a named event. The monitored app would have a background thread that periodically sets a named (watchdog) event. The monitoring app would wait on that event and if it fails to get the event in a certain time bound, the other app is either not running or has locked up.
Use a socket. Have the monitored app open a socket and listen on it. The monitor app would send a "ping" periodically to the monitored app. The monitored app would respond to the ping with an ack. If the monitoring app doesn't get an ack, the monitored app is either not running or is locked up
Use a window handle. The monitor app periodically P/Invokes GetWindow of FindWindow to find an always-present window in the monitored app - often by Form text. If the monitoring app can't find the Window, the monitored app is not running.
I am writing a Windows device driver using WDF (KMDF) for a USB3 device that transfers data in large chunks at a time. I've written a user-level application that tests this functionality, and for the most part, things work.
The problem I encounter is this: I have found that when I force-close (CTRL+C from a cmd window) the application mid-transfer, the on-going data transfer at the time of cancel immediately stops and the host seems to simply stop communicating with that endpoint. I have observed this on a USB bus trace. The requests return in the function driver as "STATUS_CANCELLED"
I have looked at other similar third party devices and ran their test applications with their drivers on those devices and found that when I kill their test applications mid-data-transfer, the transfer completes before the application closes.
My question:
How/when does Windows decide to kill in-flight requests when applications are closed?
Is there any way to mark the request as "uncancelable"? I've scoured the documentation but found nothing that suggests I need to do something to keep requests from being cancelled behind the scenes mid-transfer.
Any insights appreciated, thanks.
It's not about the device driver; it's about the way the console application handles the Ctrl-C event. The console application must trap the Ctrl-C event, and wait for the transfer to finish before it exits.
I want to get a heap dump (suspected memory leak) of a certain Java process. However, when I start the jvisualvm tool, I cannot see any of the running Java processes.
I have Google'd around about this and have already found a couple of articles saying that you have to run the Java processes using the same JDK that you start the jvisualvm tool with in order for it to be able to see them. However, as far as I can see, this is already the case. I'm doing everything locally (I have remote access to the machine).
A couple of things to consider:
The processes are running on a firewalled Windows 2008 server
The processes are running using renamed versions of the JDK java.exe executable
As far as I can see the processes are running using the 1.6.0_18 JDK
One of the running processes starts an RMI registry
I'm waiting on a virtualized copy of the server so I can mess around with it (this is a production server). But in the meanwhile; any ideas as to why I cannot see any of the processes in jvisualvm (or jconsole for that matter)?
Well after I did a little research, it would appear that Peter's comment was correct. Because the JVM processes were launched by another user (the NETWORK SERVICE account because they were being started by a Windows service) they didn't show up in jvisualvm.
Workaround
Since I have access to the application configuration, I have found the following workaround, which involves explicitly enabling unsecured JMX for the target JVM:
Add the following JVM parameters:
-Dcom.sun.management.jmxremote.port=3333 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false
Add the remote process to jvisualvm using JMX by click File -> Add JMX Connection. You can connect to the process using port 3333. Obviously you can change the port if you want.
Link to article explaining this in a little more detail: http://download.oracle.com/javase/6/docs/technotes/guides/visualvm/jmx_connections.html
Notes
It's probably not a good idea to keep the JVM settings permanently, as they would allow anyone to connect to the JVM via JMX.
You can also add authentication to the JMX JVM parameters if you want to.
The simplest way is to execute jvisualvm as administrator (win: "run as administrator"). Which is not ideal but works. All java processes are visible then.
We have a program that uses QoS-sockets, our softphone application uses QoS for the RTP.
That application is normally left running, sometimes however it is restarted. (Stop, wait 300ms, start.)
We have found that when the softphone-application is stopped that the last one useing QoS on the server, so the RSVP QoS-service on windows is stopped as well.
When we restart our application the RSCP QoS-service normally starts really fast, however sometimes the service start takes a full 30 seconds, causing our application to start slowly as well.
Anyone know if I can configure the service not to stop each time?
The computer is Windows XP SP3, with Windows Firewall turned on. (Our application do have an exception in the firewall.)
Regards
Leif
In the end this was solved with a workaround.
In the main-application we now open a QoS-socket, which we keep open until the main-application ends. That way the RSVP service cannot be closed, since it's in use.
(I found that opening the socket without bind()-ing works, so we don't need any port.)