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

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

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.

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.

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

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

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.

"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

>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.

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

> I can not afford to disable JIT because my server take double the time to start

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)

> And moreover disabling JIT is not solving problem completely

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

>>> >>This statement is not true. Enabling JIT or disabling JIT is in my control. This is done in WebSphere startup scripts. (server.xml). I know whether I am enabling or disabling JIT for WebSPhere. My argument is that even after I enable JIT, Idea 6 works with that server fine. Debugging with Idea 7 crashes the server.

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)

>>>>>>>I tried all these options. Idea 7 has issues with debugging WebSphere 6.1 and the Java that is shipped with it (exact version of Java I have given above)

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

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.

>> Without disabling JIT as well I can debug same WebSphere server with Idea 6 and Eclipse 3.3 without any issue. Only Idea 7 is causing JVM to crash.

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 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.

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 attaching the tread dump from IDEA. Is there anything else you need to research this?

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.

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 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.

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?

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

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.

> I get the problem when I step over (F8). I do not know if your workaround will not help me.

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

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?

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

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

Thank You.

I am attaching the threaddump.

> 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

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.

> 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.

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.

1.
> 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.

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.

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?

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.

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

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

• 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.

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.

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

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?!?
            System.out.println("Thread [" + name + "] : " + i);
            try
            {
                sleep((long)(Math.random() * 1000));
            }
            catch (InterruptedException e)
            {
                e.printStackTrace();
            }
        }
    }

    public static void main(String[] args)
    {
        //breakpoint at the line bellow
        for (char c = 'A'; c < 'D'; c++)
        {
            new ThreadDemo(String.valueOf(c)).start();
        }
    }

}

I start debugging, the first breakpoint is hit - for cycle, then I'm stepping over with F8, several times, the new threads are started and they print in the console, but the execution never stops on the second breakpoint in the run method?!

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)

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

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.