This is a serious issue. This (hang) happens mostly when debugging WebSphere 6.1. Hanging is almost certain if WebSphere is launched without -xnojit option. If you add -xnojit option to JVM, debugger hanging is less frequent.

It is very sad that Idea 7.0 is released with this serious bug.

This is most likely JDK problem. To be 100% sure about this, please provide console thread dump of the JVM that runs IDEA taken in the moment when debugger is in the state of "Waiting until...."

I agree, It could be IBM Java issue. But I can not change the Java. WebSphere works with only the Java that comes with it.

Idea should identify the JVM and avoid calling certain API which causes this kind of problem. In fact Eclipse 3.3 and
Idea 6.0.6 works perfectly well with the same JVM. After wasting one weekend on making Idea 7.0 workiing with WebSPhere 6.1, I revreted to Idea 6.0.6

Attached is the thread dump. I can give you core dump also if you want.

The Java version I am using is = J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20071007 (JIT enabled)
J9VM - 20071004_14218_lHdSMR
JIT - 20070820_1846ifx1_r8
GC - 200708_10, Java Compiler = j9jit23, Java VM name = IBM J9 VM

I changed the WebSphere 6.1 Java to Fix pack 14, hoping that it would solve problem. After this the JVM is crashing, but not hanging while debugging. I have given the Java version I am using above.

Please try these options:

1. add to idea.exe.vmoptions the following key

• Didea.debugger.keep.temp.objects=false
  
  

This is due to known bug of ibm jdk that "disableCollection()" API call may cause vm crash. If the key is specified, IDEA will avoid calling this method.

2. Try to switch off "toString()" and "Alternative Collection" views to avoid method invocation while rendering data in debugger's views. (see Debugger options)

Please let me know if any of this helped.

I tried both options before posting here. Both did not help. Idea 6.0.6 and Idea 6.0.5 works fine (debugging is fine) with the same JVM.

There is a serious bug introduced in Idea 7 without doubt.

I wish I have something like -Didea.debugger.level=idea6

Eugene Zhuravlev ,

Do you have any update on this issue. I am not seeing any progress on this issue. This bug is preventing me from using Idea 7 with WebSphere 6.1 (which is my primary application server).

Why this is working fine in Idea 6 and broken in Idea 7.

I tried with all combinations of WebSphere 6.1 and Idea 7 (point versions)

Please fix this as early as possible.

Ramaswamy Meka,
Please ensure that option "Disable JIT" in Debugger Settings is checked. It seems like it is vital vor IBM JDK that JIT is disabled in debug mode. Please let me know if this helped.

I already mentioned about this in my first post.

"Hanging is almost certain if WebSphere is launched without -xnojit option. If you add -xnojit option to JVM, debugger hanging is less frequent.".

If i disable JIT it is less frequent, but it happens. Again I am reiterating what I said before:
With Idea 6 same server without disabling JIT works fine.

I can not afford to disable JIT because my server take double the time to start. And moreover disabling JIT is not solving problem completely

But did you actually try setting the option "on"? Please do try it without specifying -Xnojit explicitly and let me know about results.



In IDEA 6 JIT was always disabled, this is the difference between version 6 and 7, where disabling JIT has become optional.



I'm afraid for correct debugging you will have to. IBM's startup script also does this without any options. (I mean that options "-Djava.compiler=NONE" and "-Xnoagent" are always added)



Have to reproduce this in order to comment. If you have any core dumps generated by the debugee with JIT disabled, please attach.

In IDEA 6 JIT was always disabled, this is the difference between version 6 and 7, where disabling JIT has become optional.




I'm afraid for correct debugging you will have to. IBM's startup script also does this without any options. (I mean that options "-Djava.compiler=NONE" and "-Xnoagent" are always added)



Have to reproduce this in order to comment. If you have any core dumps generated by the debugee with JIT disabled, please attach.

Ok, if you'd like to think like this, let it be so. I just want to point out that the option "Disable JIT" in IDEA's debugger settings effectively includes the following options to VM command line: "-Djava.compiler=NONE -Xnoagent". This checkbox is missing from IDEA 6 and both options were always added. It seems that for debugging WebSphere this checkbos must be on.

This checkbox is missing from IDEA 6 and both options were always added. It seems that for debugging WebSphere this checkbox must be on.



The problem is in Idea 7. I could not use Idea 7 just because of this bug. I can not afford to disable JIT as my server startup time almost doubles. And even disabling JIT is not helping.

We are currently investigating what call or sequence of calls might have caused this behaviour

7.0.3 release candidate is released without this fix. It is sad that Jetbrains is releasing idea without fixing critical issues. I could not get even a workaround for this issue.

We cannot fix the JDK for IBM. All we could do is to try to implement a workaround for their bug. If we could reliably say what particular call or sequence of calls leads to such a behaviour, we would be able to implement it. Until now it is not clear what brings the debuggee VM to such state - it simply stops responding.
For example In my environment "-Xjit:disableinlining" did help, but VM kept hanging on another machine.

Sorry for not following this issue closely, I've been very busy.

Eugene, my environment does not have the IBM JDK installed, we don't use WebSphere at all. Both IDEA and the app run on Sun's JDK 1.5. I still experience this issue, although its frequency varies greatly. When I originally filed it, I was seeing it at least daily. I haven't seen it for weeks, but suddenly it happened again last night. I don't do anything differently as far as I can tell.

I am having the same issue debugging WebLogic Server with Java HotSpot(TM) Server VM Version 1.4.2_13-b06

I am attaching the tread dump from IDEA. Is there anything else you need to research this?

Eugene Zhuravlev ,

This is a bug introduced in IDEA 7.0 ; Intellij IDEA 6.0.5 works perfectly fine with the same Java Virtual Machine, which otherwise would crash with IDEA 7.0 debugging.

For me this is a regression in IDEA.

Can we get a fix for this in near future? I am really surprised that you are introducing bugs like this in new releases and not fixing them.

Open source tools like Eclipse is working properly and commercial products like Intellij is not working properly! Releasing new versions like this can be called a progress?

I lost all the hopes on Intellij IDEA. Basic things like debugging is completely broken and you do not have even a work around.

I have tried with all possible versions of WebSphere 6.1 and all possible versions of Idea 7 in the hope that the debugging works.

I am completely helpless.

Ramaswamy Meka,

We were not able to reproduce VM crash (which seems to be your case). What is sometimes reproducible is that debuggee VM for some reason stops responding (like in the thread dump you attached). Also we have double-checked that all debugger calls are made in conformance with JDI/JDWP specification. I believe you would agree that in order to provide a workaround, one has to find the reason for such behaviour? We currently only have an IBM jdk version 1.5 as a black box and have to try lots of hypotheses. So let's keep this discussion constructive and focused on solving the problem.

As for now please try to set breakpoint's "suspend policy" to "thread" instead of "all". Does it make any difference?

Anton,
for version 1.4.2 of IBM jdk the "-Didea.debugger.keep.temp.objects=false" should be used. Do you have it in IDEA's VM options?
Also please try my suggestion about breakpoint's suspend policy from my comment above.

Any information about particular debugging scenarios you use, is welcome.

Eugene,
As I mentioned, I am using Sun Hotspot JVM not an IBM JVM.
I will gladly try your suggestion anyway and let you know if it happens again.

I get the problem when I step over (F8). I do not know if your workaround will not help me. If you fix the hanging problem, the crash problem would get fixed I guess. I used get only hang when I use WAS 6.1.0.0.
I am getting JVM crashes after I upgrade to WAS 6.1.0.7 and more.

I know that it could be a bug in IBM java. But you should be able to handle that. How Idea 6.0.6 and Eclipse works Idea 7.0 also should work.

Ramaswamy Meka,



So, you created the only line breakpoint with suspend policy = "Thread" and when you step over after the breakpoint was hit, VM still hangs?

I have removed -Xverify:none from my JVM args and it stopped crashing of JVM.

IMPORTANT :Hanging of JVM while debugging still happens and I observed that it happens when I am idle for some time during stepping to next line.

If I continuously debug, I am not seeing server hang. Does this give any clue for you? Or you have any suggestion for me to try out?

You still have not mentioned whether your breakpoint used "Suspend Thread" policy or not

I tried with Suspend thread policy and it seems not hanging. Can you tell how to make break points as "Suspend thread" by default.

There is no way to set this by default now. We are going to add possibility to configure defaults in 7.0.4.

What is the way out for me. Today whole day I tried figuring out setting default Suspend Policy. Whenever I click on the line breakpoint gets added and I have to right click and change properties?

It is a painful. Practically speaking your solution is not at all helping me .

Can I write a plugin to do this? What are the various other ways for setting break point 's default suspend policy?

If it were possible to achive the goal by writing a plugin, I would write it for you :-)
We are going to make defaults editable ASAP and the functionality will be made into the first 7.0.4 RC build. This will be also available in IDEA 8.0 (Diana) EAP builds, which are planned to be published soon.

Thank You. It is really painful for me. This bug wasted so much of my time. Hopefully you fix the issue of hanging as well as setting default suspend policy in Idea 7.0.4.

Thank You.

Provided the way to set default suspend plicy for a breakpoint

The problem occurred again even though i am using "-Didea.debugger.keep.temp.objects=false"

I am attaching the threaddump.

Anton, please try using "suspend policy= Thread" for all your breakpoints.

I've encountered this issue as well. Setting suspend policy works for me as well, but I can't help thinking that it's a workaround, and not a solution, even if we can set the default to "thread" in 7.0.4. When debugging a multithreaded application (like, say, a webapp), I'd say that you usually want all threads to be suspended when hitting a breakpoint, and not just the active one. And in any case, at least I want to have that option. Shouldn't a solution to this problem include fixing the root of the problem so that we don't even have to care about breakpoint suspend policy in the first place? Or am I missing something here?

Mats,



You might want this behaviour for desktop applications, but for the application server that runs lots of threads suspending only the thread that serves your request is ok. There is no point in suspending other threads that are doing other "auxiliary" job.



No matter whether you call this a workaround or not, why it's not a suoution? Java debugger consists of two parts: a client (IDEA or Eclipse or a standalone debugger) and a server (the debuggee JVM). We may influence and change behaviour only of a client and only that part of a client that calls standard JDI API. After the investigation it turned out that with suspend policy "ALL THREADS" the server part of debugger may hang. We can't "fix" that because we do not develop the JVM. And this is the point that I mentioned many times not only in this discussion but also in other threads in our newsgroups. In this case using "ACTIVE THREAD" suspend policy looks like a good solution especially for application servers for which this mode seems to suit better. So is it important how the solution is called if it works and works well? I want to point out that we cannot change JVM behaviour, all we can do is to use it with appropriate settings.

Eugene,

1.


This is not true. Applications (web/non-web) often split off work into threads that execute the same code (on different datasets) to get the work done. When one of those threads gets to my breakpoint, i want the other threads to be suspended until i am done stepping through the first one. Otherwise, the frame that I am seeing will be replaced by the frame of one of the other threads as soon as it gets to the break point.

2. "No matter whether you call this a workaround or not, why it's not a solution". You have answered this question when you said "You might want this behaviour for desktop applications...". Since your proposed "solution" does not work for all cases, it becomes a "problem that can be mitigated by a workaround".

3. (And the most important) You have mentioned multiple times that "all threads" causes the problem on the JVM side. Please do explain how come the same JVM did not have this problem when debugged using IDEA 6.x or 5.x.

The behaviour cannot be reproduced on my machine with IDEA 7, but it is reproducible (not reliably) on another machine even for IDEA 6. (same project, same application server, same versions of VM). I may say for sure that the only difference between IDEA 6 and IDEA 7 in this area is the way the application started (adding "-Djava.compiler=NONE -Xnoagent" by default or not). In other aspects both IDEA 7 and IDEA 6 handle stepping in the same way. By using suspend policy "thread" we did not manage to reproduce it anywhere.

The fact that you able to reproduce the issue on Idea 6 while multiple people on this thread said that they did not experience this problem on idea 6 indicates that perhaps the issue that you are encountering is not the same.

I am not sure what the nature of your test application is, perhaps it's not complex enough to expose this particular problem.

For me, this problem usually occurs when I step through a complex flow with 10+ breakpoints, which get hit multiple times. My application contains 50+ libraries, some with source code attached and some without.
Could you try recreating it under similar conditions?

Eugene,

My point was not to argue semantics. My point was that your proposed solution doesn't seem to fix the root of the problem, it only provides a way to get around it, and if I need to suspend all threads at a breakpoint, I'm basically screwed. To me that's a workaround and not a solution. But what you call it isn't important - the point is that IDEA doesn't support all the ways that we, your customers, want (need) to work. As for this being a JVM problem, I haven't read the other threads you refer to (but please provide a link - I'd like to read them) but in this thread, all I see is you referring to problems with the IBM JVM. I'm using the Sun JDK (1.5.0_15), and I have the same problem. Of course it's not unreasonable that the same problem exists in both JVM's, but it may also indicate that the problem is in IDEA.

As for not wanting to suspend all threads in a web application, I'll argue that there are indeed situations where you want this. One simple example is if you're debugging a web service, and you don't have complete control over the client side, so you may be getting multiple calls in parallell. If you don't suspend all threads, then you may hit the same breakpoint again while stepping through the first invocation. Or even worse, without stepping at all - since calls are outside your control, as soon as a new call comes, you get a new breakpoint hit.

Mats, Anton,
Could you please specify VM settings for your application servers and particular versions of the servers. Do you start servers from IDEA or via the startup script (and then attach with IDEA using "Remote" configuration). If you are connecting remotely, are you using generic remote configuration (named "Remote"), or a configuration proviedd by the corresponding IDEA plugin? What plugins are loaded into your IDEA instances?

VM settings are just -Xms192m -Xmx512m. I'm using Tomcat 5.5.26, started from IDEA. I haven't installed any plugins after installation (I think), so just the default ones for 7.0.2. It's too long a list to copy by hand. If you have a way to extract the list from IDEA, tell me and I'll send it up to this thread.

Thanks Mats,
While I'm checking similar configuration, could you please try EAP build of IDEA 8? Can the issue be reproduced there? (use "all threads" suspend policy)

One more thing Mats. Until you mentioned you are using Tomcat, I thought you were using WebSphere as initial submitter. Could you please create a separate issue and describe in detail the exact problem that you see. I'm asking this because there might be differences in behaviour in your case, which I am not aware of.

1. I am using generic Remote Debugging configuration with port 5005/no compilation on debug. The classes are compiled by Ant scripts outside of IDEA, but the classfile path is configured correctly. I will provide VM params a bit later.
2. Fyi, I am also not using Websphere, I am using Weblogic.

Just to set the record straight, I am the original filer of this issue. As I mentioned somewhere in the comments, we don't use WebSphere. WebSphere was used by another guy who commented a lot on this bug in the beginning.

We use OC4J (Oracle's app server), with Sun's JDK 1.5.

Eugene,
I'll create a new issue if you want, but reading the initial description, I wouldn't add anything. The only difference is that I'm starting the app server from within IDEA instead of attaching to it. So stop/close debugger terminates the app server instead of resuming, but otherwise the symptoms are exactly the same as described by Alex. But if you still want, I'll create a new issue. Should I?

I've downloaded IDEA 8 EAP and will give it a try.

If the description is like the one in the original post, and the scenario is the same then no need to create. I would ask only to specify your app server and its configuration (not only you but other commenters as well). Otherwise there we may talk about different things and I may spend time in attemts to recreate the problem in completely different configuration. With WebShere there were known issues with some JDI calls implemented with bugs and this was pretty often the reason for suddend hangs and crashes. As fo the Sun's VM - under some circumstances this may happen if you do lots of method evaluations (for some unknown reason - the documentation does not manion about any restrictions or preconditios that must be met before invoking a method). If the problem is reliably reproducible in your environment, we can perform a test. In debugger settings please disable features that imply method evaluation: these are "toString() object view" and "Alternative view for collections". As a result the objects will be rendered according their structure, just as in other debuggers. If the problem goes away, then with high probability we may say that the reason is in method invocations.
I must say that here we have at least two rather big projects that run on Tomcat (TeamCity as an example). The TeamCity server is debugged quite often with all debugger features used and developers did not complain about the problem described here (I did ask them :-).

I already did specify my app server, but to be clear:

• Tomcat 5.5.26, unzipped to disk, configured as an app server in IDEA, started from within IDEA. Nothing special whatsoever.
  
• JDK 1.5.0_15
  
  

I've been running IDEA 8 EAP today and haven't had the problem yet, but since it's always intermittent it's too early to tell if it's gone.

Update: I just encountered this in IDEA 8 EAP. But now the status bar contains the message "Evaluating java.lang.String java.lang.Object.toString ()". So it seems likely the problem is related to variable display in the debugger.

Did you try to disable the "toString() object view" and "Alternative view for collections" as I suggested?

Not until now, no. Since the problem isn't "reliably reproducible", I wanted to see if I could reproduce it at all first. I've disabled them now, but since the problem is intermittent (albeit frequent) not encountering it is not conclusive proof that it's solved. Also, the toString view is very convenient, so I don't really want to do without it. But one thing at a time.

Ok, waiting for your feedback about how things work with toString() disabled.
One more thing - please pay attention what object are about to be rendered when the hang happens. What is interesting is their implementation of toString() method.
Are there any objects in the context which have "non-trivial" toString() implementation which, for example, makes a call to another object or calls a synchronized method (directly or indirectly)?

Another update: IDEA 8 EAP is too unstable to use - just now I couldn't even compile - so I'm abandoning it and going back to 7. I'm disabling toString(). We do have non-trivial toString implementations, but I can't think of anything that's really complicated and/or synchronized. But I'll keep it in mind.

I'm experiencing the same problems with suspending threads and even more - the thread's breakpoints are ignored? I want the other threads to be suspended, and when one of them is activated to stop at its breakpoint, and all the other threads to be suspended - that's not happening.

Idea version is 7.0.4, I have disabled JIT in debugger configuration, toString() is unchecked, alternate view for collection classes is unchecked, my app is standalone, JDK is Sun's 1.5.0.14, Windows XP SP2,
Never comes in such issue with Idea versions 5 and 6 - there's something changed in the debugging in the v7 except 'disable JIT' command parameter.

Ivan, while you step (use either stepInto or StepOver commands), there is an implicit thread filter added for the current thread and breakpoints in other threads are ignored. When you do "Resume" (F9), the thread filter is removed and any thread can hit any breakpoint.

OK, I'll try it.
That explains why the other threads' breakpoints are ignored, but not why the other threads are not suspended...

In 5.x and 6.x, there was a button called "Suspend all (or other) threads while stepping". What happened to it and why? Thanks.

this was introduced as a workaround for performance problems with threads suspension/resumption in early builds of JDK 1.4. Currently for stepping IDEA uses the same suspend policy as the one of event that caused suspension.

I am having the same exasperating problem with 7.0.4 and 8.0M1. The problem goes away if I turn off the "toString() object view" and "Alternative view for collections". But that is a work-around, not a solution. Very frustrating. What is the cause?

"toString() object view" and "Alternative view for collections" do not help at least for me they are not checked and the problem persists.
I played with Disable JIT, Force classic VM for 1.3, socket and shared memory transport without any success.
Anton is right about the button, I do not know if it was only workaround for other problems, but now the other threads are not suspended :(

It seems, that there is no progress on that.
At least try to fix it in the new 8 version - this is serious and important drawback

I'm trying to help, here is a simple example (attached also)

{code:title=ThreadDemo.java|borderStyle=solid}
public class ThreadDemo extends Thread
{

private final String name;

public ThreadDemo(String name)
{
super();
this.name = name;
}

public void run()
{
for (int i = 0; i < 10; i++)
{
//breakpoint at the line bellow - we never stop here?

Breakpoint suspend policy is 'All', toString() and Disable JIT are turned off, Alternate view for Collections too. I'm attaching screen shot of the settings too.

I tested it with Sun's JDK version 1.4.2_17, 1.5.0_14 and 1.6.0_10
Idea version 7.0.4 #7941

It was OK with my previous versions 5.0.x and 6.0.5 (just tested it again with 6.0.5)

I've created a new issue : IDEA-20497, may be it'll have more chance to be examined and fixed in a new issue rather than commenting a resolved one...

Please if you suffer from this bug too you can comment there : IDEA-20497

I am the original reporter of this bug, and no, it is NOT fixed for me. I am using 7.0.4.

It's amusing that the only action available to me as the reporter is to close this issue. I cannot reopen or do anything else with it. Seems like the process is flawed.

Alex, please try IDEA 7.0.5 RC:
http://www.jetbrains.net/confluence/display/IDEADEV/Selena+EAP