I'm debugging a multi process java application. I start the first process with a breakpoint set after it starts the child process. The child process then goes into a loop waiting to be manually broken in the debugger so that I have time to attach to it.
I'd like to have the breakpoint in the parent process trigger the NetBeans debugger to go and attach to the child process (which is started with a debug listener port).
This would make debugging the child much easier.
The only current actions I see are Enable and Disable groups of other breakpoints....
I ended up writing a Netbeans module that interacts with supporting code in my application to catch child process creation and then automatically attaches to them on a debug port they're using.
It does this through an automatically created hidden breakpoint (on a method my application calls when a child is spawned). That breakpoint evaluates a static method in the support class in my application to get the debug port. It then tries to attach to that port and resumes the application from the breakpoint.
The end effect is that I get automatic attachment to a child process with no user intervention. Just Start-Debug on the main application and then breakpoints get hit seamlessly in the child processes. Like the gdb option (set follow-fork-mode child) to attach and follow children processes after a fork/exec.
It only works in my specific case as I control both the Netbeans plugin module and the application under development.
I can't post the whole source here, but the things I used to achieve this included:
DebuggerManager.getDebuggerManager().addDebuggerListener();
MethodBreakpoint.create();
RequestProcessor.getDefault().post();
DebuggerInfo.create ("netbeans-jpda-AttachingDICookie", new Object [] {AttachingDICookie.create ("localhost",port)} );
DebuggerManager.getDebuggerManager().startDebugging()
JPDADebugger d = DebuggerEngine.lookupFirst("", JPDADebugger.class);
JPDADebugger.waitRunning();
The magic string "netbeans-jpda-AttachingDICookie" was the hardest thing to figure out in this. It took debugging the netbeans debugger through a normal attach process call to find this value. I have not been able to find it documented anywhere.
Related
I've connected my Java based app engine app to Cloud Debugger via GitHub. I can see the source code and navigate the source files. But, when I place a breakpoint on a line in a source file, the debugger never captures local variables when I execute my app. How can I troubleshoot/fix this?
There might be few reasons why the snapshot will not hit.
Make sure that you are using the source code version that is deployed with your app. Many times the head revision is ahead of the deployed version.
If you use appcfg version 1.9.20 or above, it includes source hints for the debugger to display the correct version of the source.
more info here: https://cloud.google.com/tools/cloud-debugger/setting-up-on-app-engine
The 'Watch Target' selected in the UI is inactive.
If the application is deployed while using the Cloud Debugger UI. It does not give an indication that the selected 'minorversion' is inactive and the snapshot will never hit.
Refresh the UI after deploying to allow the UI to pick the latest minorversion of the application.
Make sure that your application is executing that file:line.
The file:line has to execute for the debugger to capture an execution snapshot. It may happen that the requests that the application is processing do not execute that specific file and line.
Make sure that the the specified condition actually evaluate to true.
First simple check is to simply remove the condition.
My project is basically a Communication client like lync which is developed in JAVA for front end (GUI) and uses platform specific native (C or C++) code for running services.
Now, on Linux, (Ubuntu 12.04), once the JAR application is invoked, it loads all the native code shared libraries and the UI thread starts executing. Any action done in the UI will throw an event to the native code which is in C. So currently i need to debug a crash in a C/C++ user library which is triggered when i do something in a UI drop down.
I am using GDB, to attach to the PID of the process , (sudo gdb -p ), all the symbols are loaded and i am able to set a breakpoint to a function say A() in the library.After continue command in GDB, i select the instance from UI Dropdown and breakpoint is hit at Function A(). At this moment, my ubuntu machine hangs and no keyboard interrupts are working. I am only able to move my mouse pointer but cannot click on anything.
However, to verify that kernel is not down, i can ping the machine and even SSH is possible. Once the same GDB is invoked by SSH the above problem is not encountered. May anyone please help me out here as to why UI or X11 process hangs during the above scenario.
PS: Yes there are lot of threads running, it might be a thread deadlock situation but it does not happen when GDB is invoked by SSH terminal.
Thanks and Regards,
Indra
why UI or X11 process hangs during the above scenario
As Mark Plotnick correctly pointed out, the X11 process does not hang. Rather, it grabs the keybard (all keyboard events are dispatched to it), and can not release that grab (it is stopped by GDB before it reaches the release point).
There are two common solutions:
ask the application to not do the keyboard grab (as Mark said), or
debug the application from a separate machine (this can even be done on single physical machine: just run the application inside a VM).
P.S. Why do application menues grab keyboard? Because hitting Esc usually dismisses the menu, and they want to see that Esc regardless of whether the application has input focus or not).
I'm currently writing a pretty large program that calls the same methods from different places.
Now I would really like to see how the program goes from one method to another as it is running. Like a live view that shows when what method is opened (and why?). Call Hierarchy doesn't suit my needs at this point. Is there a way?
One way to follow the logic of your application is by placing breakpoints at the line of code you want your application to stop at but, to do this you'll have to setup it up in debug mode.
Every major IDE will let you do this, including Eclipse.
Have a look at this tutorial:
Java Debugging with Eclipse
Once you setup your program in debug mode you can add a breakpoint in the gutter next to the line numbers.
I wish the run command (usually default to CTRL+F11 combination) of a Java project (and C++ if you know it too) to automatically close the previous process (or all processes, if it's easier) started by it before it runs a new instance.
In short, running a project should also close previous app instance. Is it possible?
Maybe it's possible to add code to the app itself, and disable it once I don't need it anymore? I want it since it's annoying to close the app each time. I don't need so many instances of the app.
In Eclipse Neon go to Window -> Preferences -> Run/Debug -> Launching and in the Launch Operation section check:
[X] Terminate and Relaunch while launching
Easier said than done. I suggest you terminate the process yourself by clicking on the little red stop icon in the console or by terminating the main thread from the threads view in the debugger perspective.
That's not possible with Eclipse built-in features. The easiest way to automate this seems to be
Install the launch group feature from CDT (you only need the mentioned feature) or the EclipseRunner plugin. They allow creation of "batch" launch configurations.
Create an external run configuration with a "kill" command (depending on your operating system), which can kill your application process based on the application name.
Create a batch launch group with one of the two plugins mentioned above, where the "kill" configuration comes first and your normal launch configuration comes second.
IntelliJ IDEA by default has the functionality to debug/run more than one instance of the same program.
For example; if I run debug on Project X and it's main threads is in waiting, sometimes I come back and run it again as the DEBUG button is not indicating a currently executing session. Nor does IntelliJ stop you from running another session of the same program (Project X)
Why is this functionality necessary, and how can I turn it off?
a) The functionality is very good when you want to rerun a configuration in a new instance.
For example a simple client that you want to start in several instances without any other effort.
b) You cannot really turn it off.
This will start a new Run or Debug session:
This will rerun the current Debug session:
This will show you your current Debug sessions:
You can enable the Single instance only option. To do this,
Go to Edit Configurations... in the dropdown to the left of the Run button.
Select the appropriate configuration.
Click the Single instance only checkbox.