3156 - Debugger - Stalled in "Collecting ..."

Everytime I hit a break point and the "Frame" window shows "Collecting ...." the debugger just seems to lock-up. I am not getting any feedback that it is actually doing anything.

When I resume the icons start to spin but the console does not change and the Unit Test does not complete. Is anyone else experiencing this?

Thanks,

Justin

0
26 comments
Avatar
Permanently deleted user

Please try build 3273 (just published).

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Justin Hopper" <jusbiz@oz.net> wrote in message news:24523657.1111778819072.JavaMail.itn@is.intellij.net...

Everytime I hit a break point and the "Frame" window shows "Collecting ...." the debugger just seems to lock-up. I am not
getting any feedback that it is actually doing anything.

>

When I resume the icons start to spin but the console does not change and the Unit Test does not complete. Is anyone else
experiencing this?

>

Thanks,

>

Justin



0
Avatar
Permanently deleted user

The same problem with build 3272 when I try to debug remote weblogic server. :(
Everytime when I stop on breakpoint the message "Collecting data..." shown.
If I resume, I got "Waiting until last debugger command completes" and I need to wait about 5 min!
After that, if I walk step by step - it working fine, but on
next breakpoint repeats all.

0

I was seeing the same thing for a while today with 3273. The first breakpoint would get tied up for many minutes collecting debug data, then subsequent steps and

Before seeing this problem, I did a bunch of rebuilds and hot swaps. Idea gave an error during one of the hot swaps, complaining that the VM doesn't support schema changes. This happened after I changed a method signature. So maybe Idea got confused after a hot swap failure.

I just did a full rebuild, and Idea seems to be behaving better. It still does the "collecting.." thing for a minute or so when it first hits a breakpoint, but stepping around with F8 seems to be back to normal speed.

Willis Morse

0
Avatar
Permanently deleted user

It does return however it takes about 5 mins to finishing "Collecting data..." I tried both socket and shared mem debugging and it doesn't make a diff.

Once the information is collected the debugging speed appears normal. It is just the first hit that takes so long.

I am not sure if 3272 improved this because I never waited this long for it to complete in the previous build.

Thanks,

Justin

0
Avatar
Permanently deleted user

Spoke too soon. This performance hit occurs when the stack changes. I was in the same stack frame before and that is why subsequent evaluations where quick. Now I changed to a different stack and it pauses again.

Thanks,

justin

0
Avatar
Permanently deleted user

Looks like we have found the reason.
How long have you been having this problem? (I mean since what build)

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


"Igor Kulikov" <no_mail@jetbrains.com> wrote in message news:33417665.1112020245364.JavaMail.itn@is.intellij.net...

The same problem with build 3272 when I try to debug remote weblogic server. :(
Everytime when I stop on breakpoint the message "Collecting data..." shown.
If I resume, I got "Waiting until last debugger command completes" and I need to wait about 5 min!
After that, if I walk step by step - it working fine, but on
next breakpoint repeats all.



0
Avatar
Permanently deleted user

Looks like this is related:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6176614
In every thread dump I have examined, debugger gets stuck at the call to ThreadReference.frameCount().
Looks like all 1.4.x JDKs have this problem, not only 5.0 or 6.0.
What is interesting, the problem is reproduced (for me at least) only when debugging weblogic remotely....

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Justin Hopper" <jusbiz@oz.net> wrote in message news:29099453.1112028156855.JavaMail.itn@is.intellij.net...

It does return however it takes about 5 mins to finishing "Collecting data..." I tried both socket and shared mem debugging and
it doesn't make a diff.

>

Once the information is collected the debugging speed appears normal. It is just the first hit that takes so long.

>

I am not sure if 3272 improved this because I never waited this long for it to complete in the previous build.

>

Thanks,

>

Justin



0
Avatar
Permanently deleted user

I can confirm it with build 3260.

Tom

0
Avatar
Permanently deleted user

To be exact: it does not take 5 minutes here to collect the data, but 15
or 20 seconds it might take for the first breakpoint hit.

Tom

0
Avatar
Permanently deleted user

Same here..tomcat 5.028, when remotely debugging it is collecting data forewer. This happens in latest 2 builds (at least that I know of). It is quite a show stopper for me, so, I would be glad if there's a fix..

0
Avatar
Permanently deleted user

It happens in the lastest build #3273 also. The last build which seems to work fine is #3245.

0
Avatar
Permanently deleted user

Found the problem finally,
It was a side-effect of the attempt to workaround this bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4783403

Now everything should work ok. Thanks to all for helping with this issue.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


"Justin Hopper" <jusbiz@oz.net> wrote in message news:24523657.1111778819072.JavaMail.itn@is.intellij.net...

Everytime I hit a break point and the "Frame" window shows "Collecting ...." the debugger just seems to lock-up. I am not
getting any feedback that it is actually doing anything.

>

When I resume the icons start to spin but the console does not change and the Unit Test does not complete. Is anyone else
experiencing this?

>

Thanks,

>

Justin



0
Avatar
Permanently deleted user

I wonder how many nasty Sun bugs the JetBrains folks have stumbled upon, and if there's any chance for an OnBoard article about them :)

0
Avatar
Permanently deleted user

But what should this article discuss?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Marcus Brito" <mbrito@gmail.com> wrote in message news:7576078.1112102945419.JavaMail.itn@is.intellij.net...
>I wonder how many nasty Sun bugs the JetBrains folks have stumbled upon, and if there's any chance for an OnBoard article about
>them :)


0
Avatar
Permanently deleted user

that's cool, thanks.
I also submitted a bug about slow debugger detaching from tomcat server. Sometimes it even freezes Idea. Are those two bugs somehow related ?

0
Avatar
Permanently deleted user

But what should this article discuss?


Hmm... maybe an Article wouldn't be the best format for this. It would be something like a "tech talk", where you would pick a few of the nastier bugs, tell us how they affected IDEA, and how you worked around them.

The above mentioned bug isn't a good choice for this -- there aren't many people implementing JPDA agents out there. But I'm sure you've come across swing bugs that would amuse many of us desktop programmers out there.

0
Avatar
Permanently deleted user

I also submitted a bug about slow debugger detaching from tomcat server. Sometimes it even freezes Idea. Are those two bugs
somehow related ?


Perhaps. Can you point on it?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"M. J. Milicevic" <me@machak.com> wrote in message news:17323394.1112103710801.JavaMail.itn@is.intellij.net...

that's cool, thanks.
I also submitted a bug about slow debugger detaching from tomcat server. Sometimes it even freezes Idea. Are those two bugs
somehow related ?



0
Avatar
Permanently deleted user

http://www.jetbrains.net/jira/browse/IDEA-1198

some funny things are going on if I select and than disselect text in debugger window...

0
Avatar
Permanently deleted user

Build 3245 does NOT exhibit this stalled behavior. I haven't tried any builds in between.

0
Avatar
Permanently deleted user

So next build will be ok?

0
Avatar
Permanently deleted user

Yes, it will

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Igor Kulikov" <no_mail@jetbrains.com> wrote in message news:24939402.1112166446112.JavaMail.itn@is.intellij.net...

So next build will be ok?



0
Avatar
Permanently deleted user

No, I think this one is a separate issue, will check.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


"M. J. Milicevic" <me@machak.com> wrote in message news:7065274.1112108149833.JavaMail.itn@is.intellij.net...

http://www.jetbrains.net/jira/browse/IDEA-1198

>

some funny things are going on if I select and than disselect text in debugger window...



0
Avatar
Permanently deleted user

Im still seeing this issue with build 3273.
Ive tried removing system/caches no join.
Still just hanges with "Collecting data.."

Idea reintroduced me to the value of a good debugger.. but now Ive lost it!

aargh..

0
Avatar
Permanently deleted user

How do I get build 3273?

I am having IntelliJ 4.5.3, build # 2250.

If I get the 4.5.4 build # 2253 online, does that include the above mentioned build 3273 based bug fix ???

I am having the same problem... when I debug, IDEA does not show instance information for some of the classes. It is frozen with "Collecting Data..." message, whereas for most of the classes it gives proper instance information.

How do I get this to work and show me the instance information for all the classes when debugging?

- Karthik

0
Avatar
Permanently deleted user

Karthik Bala wrote:

How do I get build 3273?

I am having IntelliJ 4.5.3, build # 2250.


3273 is an old EAP (Early Access Program) build of next release of IntelliJ IDEA. The
latest EAP build is available here: http://www.intellij.net/eap/products/idea/download.jsp

0

Please sign in to leave a comment.