Archive for the ‘Debugging’ Category
I’ll continue my instructions regarding how to set up JSDT development infrastructure.
- I set up the build target
- I checked out the code
- I updated to the latest debug plugins to resolve compilation issues.
- I launched the unit tests
Now run the product
When I work on Eclipse products, we typically provide a default launch config per product. Although the nightly build is the ultimate authority of what encompasses the product, these version-controlled launch files provide a good point of comparison developer to developer.
I could not find a public JSDT .launch file under CVS control.
So I looked at the installed JSDT product to create my own. It’s here if you would like to download it.
Just drop it into an active project in your Eclipse workspace, refresh the project, open ‘Run Configurations” and you should see a “jsdt” run config.
You may want to tweak it a bit and verify that the set of selected plugins is correct.
Then hit Run to see the JSDT.
Disclaimer: I’m not on the JSDT team, so this may not be exactly how they do it. But it’s what I’ve done to get it working.
Lately, when starting Eclipse, the JVM has failed to start. A reboot of the system usually fixed the problem. Until yesterday. So I had to dig in and solve this problem.
I wanted to share my experiences with debugging this issue.
Added Note: This is not the bug by which Eclipse running under java 1.6u21 fails to pass the permgen size on to the JVM. If you are running java 1.6u21 with Eclipse, don’t.
Determine why eclipse.exe is crashing with “-debug”
I edited my eclipse.ini and added the -debug option:
Then I ran eclipse.exe from the command-line, hoping to get a bit more information:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Now that’s a clear error message!
I need lots of memory
You may have noticed some pretty large memory numbers in the eclipse.ini. When Eclipse starts the JVM, it will allocate a little more than 1.2Gb (752M heap + 512M permgen).
I have many large C++ and JDT projects in my workspace. I run classic Eclipse + CDT + svn plugins. At one point I was having some memory issues and I blindly bumped up max heap and permgen. This worked but I may have over-compensated by making them a bit too big.
So it’s memory. Why did it used to work? And how to debug it?
StackOverflow and vmmap
I found some useful information from Roland Illig on StackOverflow. The JVM allocates a contiguous block of memory for its heap. And a DLL with an improper base address could chop up memory such that I can no longer get that nice large chunk of memory. Roland mentioned using the Microsoft SysInternals tool vmmap.exe to debug.
First I tweaked eclipse.ini, setting the highest possible max memory setting under which Eclipse would successfully start. It turns out that this was 660Mb in my case.
Then I fired up vmmap.exe from SysInternals. I selected eclipse.exe, and a memory map appeared.
I looked for a large segment of (yellow) Private Data. I found one that was 1.2Gb, as expected.
Under Options, I turned on “Show Free Regions” so I could see any free regions.
Then I looked shortly after my Private Data for any Purple “Image” entries. These are DLLs. I noticed that there were 3 DLLs between my large allocation and about 200Mb of memory. The DLLs had base addresses of 5ad70000, 5b860000, and 5d090000.
Now I just need to map the base addresses back to the DLLs.
By running listdlls.exe from SysInternals, I got a dump of all the DLLs currently running on my system, including their base addresses. A quick search of this file dump revealed that the errant DLLs are uxtheme.dll, netapi32.dll, and comctl32.dll.
Solution: Rebase or Tune eclipse.ini
It turns out that on XP, these DLLs were rebased too low in XP SP2. One solution is to rebase these files to a more suitable address space. Beware: this requires great care and knowledge. I don’t really care to mess around with these unless I have to.
A safer approach is to tune my eclipse.ini settings to a more appropriate max heap size and permgen space. I used jdk/bin/jconsole to attach to my eclipse process. I determine I was using about 90M of permgen space. So I have pared back my permgen space to 128Mb in eclipse.ini and things are working great again. I will fire up jconsole again after Eclipse has been running for a couple days to determine if these values are OK.
I always seem to spend too much time dinking around with UI layouts. In fact, today I’ve been fighting an odd problem where I had a bunch of extra space in a dialog between two other elements. I had spent excessive time trying things, over and over again, with no success. That’s usually a sign to take a step back from the keyboard.
I vaguely remembered there was a tool that painted each composite in the UI a different color. I Googled and found Simon Archer and Chris Aniszczyk’s Picasso tool. Picasso is found in the PDE incubator source code (unfortunately it doesn’t get full billing on the PDE incubator page).
I ran my app with Picasso enabled, and clearly saw that something was amiss between my text and my table. I hovered over the lime green box and was able to get a large screen of useful information (not shown): what the element is, its parentage, layout, etc. I was able to quickly fix my mistake.
How to use:
- Import the project into your workspace from the PDE incubator repository.
- In your run config:
- Plug-ins: add org.eclipse.pde.picasso.
- Tracing: enable tracing and turn on org.eclipse.pde.picasso.
- Start your app.
My Eclipse-based product dead-locked this morning.
If I had launched from my Eclipse dev environment, I could use the debugger to show me the threads and locks that are giving me trouble. Darin Swanson has the best explanation of this.
If I had started the product with “-debug -consoleLog‘ or with java.exe instead of javaw.exe, I could have hit ctrl-Break (Windows) to get a thread dump.
But I had started the product from the install bundle, so didn’t have these options. I also didn’t think the deadlock would necessarily reproduce if I re-ran the product. A little research showed I had more tools at my disposal than I originally realized.
If I had started the product with the Java 6 (or with Java 1.5 using the -Dcom.sun.management.jmxremote VM option), I could use jconsole to attach to my process. Besides the stack trace, this allows all kinds of interesting monitoring.
To use the tool, you’ll need the process ID. You can use the task manager on Windows or the JDK tool jps to get the list of Java process IDs.
The JDK tool jstack works great to just get a quick stack dump from the command-line. Again, you’ll need the process ID.
I need to spend some time exploring the JMX tools. Some cool and useful stuff in here.
Another option is Send Signal, a nice program that send the Ctrl-Break signal to your Java process.
Much of the information new to me came from these 2 excellent resources. Both pages have other ways to get stack traces, including on *nix, and other useful debugging tips.