| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| StackOverflowError when debugging JCN in Toolkit |
« View previous topic :: View next topic » |
| Author |
Message
|
| Willtodd |
 Posted: Fri Apr 17, 2009 1:36 pm Post subject: StackOverflowError when debugging JCN in Toolkit |
 |
|
Newbie
Joined: 11 Apr 2009
Posts: 6
|
Hello. I am encountering an issue with the WMB Toolkit debugger. Whenever I try to step into a Java Compute Node, the toolkit throws the following exception:
An internal error occurred during: "JDI thread evaluations".
java.lang.StackOverflowError...
I am using Version: 6.0.2 Build id: 20061201_1308 (Fix 017) of the .
I am fairly certain that the cause of the problem is not my Java code within the JCN, whereas the stack trace only references WMB classes. The issue occurs on any of my JCNs regardless of what code is inside, and if I step over them, the error does not occur. |
|
| Back to top |
|
 |
| Willtodd |
| Posted: Fri Apr 17, 2009 1:37 pm Post subject: |
|
|
Newbie
Joined: 11 Apr 2009
Posts: 6
|
Here is the complete stack trace...
An internal error occurred during: "JDI thread evaluations".
java.lang.StackOverflowError
at org.eclipse.core.internal.dtree.AbstractDataTreeNode.indexOfChild(Unknown Source)
at org.eclipse.core.internal.dtree.AbstractDataTreeNode.childAtOrNull(Unknown Source)
at org.eclipse.core.internal.dtree.DeltaDataTree.lookup(Unknown Source)
at org.eclipse.core.internal.watson.ElementTree.includes(Unknown Source)
at org.eclipse.core.internal.resources.Workspace.getResourceInfo(Unknown Source)
at org.eclipse.core.internal.resources.Resource.getResourceInfo(Unknown Source)
at org.eclipse.core.internal.resources.Resource.exists(Unknown Source)
at org.eclipse.debug.internal.core.sourcelookup.containers.ContainerSourceContainer.findSourceElements(Unknown Source)
...repeats about 2000 times...
at org.eclipse.debug.internal.core.sourcelookup.containers.ContainerSourceContainer.findSourceElements(Unknown Source)
at org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.findSourceElements(Unknown Source)
at com.ibm.etools.vfd.launching.sourcelookup.FlowProjectSourceContainer.findSourceElements(Unknown Source)
at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupParticipant.findSourceElements(Unknown Source)
at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector$SourceLookupQuery.run(Unknown Source)
at org.eclipse.core.internal.runtime.InternalPlatform.run(Unknown Source)
at org.eclipse.core.runtime.Platform.run(Unknown Source)
at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.doSourceLookup(Unknown Source)
at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.getSourceElement(Unknown Source)
at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.getSourceElement(Unknown Source)
at org.eclipse.jdt.internal.debug.ui.JavaWatchExpressionDelegate.getProject(Unknown Source)
at org.eclipse.jdt.internal.debug.ui.JavaWatchExpressionDelegate.access$0(Unknown Source)
at org.eclipse.jdt.internal.debug.ui.JavaWatchExpressionDelegate$EvaluationRunnable.run(Unknown Source)
at org.eclipse.jdt.internal.debug.core.model.JDIThread$ThreadJob.run(Unknown Source)
at org.eclipse.core.internal.jobs.Worker.run(Unknown Source) |
|
| Back to top |
|
|
| Willtodd |
| Posted: Tue Apr 21, 2009 11:10 am Post subject: |
|
|
Newbie
Joined: 11 Apr 2009
Posts: 6
|
I have an update on this problem. I have a rather large Message Flow Project (over 100 flows), and they use a rather large Java code base (about 500 classes) for their JCNs. Even though the JCN I am trying to debug is very simple, the debugger seems to act on Projects, not specific flows; so I think the problem is that the debugger's JVM cannot load the entire code set (flows and Java) associated with this project space.
To test this theory, I created a simple flow (MQInput->Simple JVN->MQOutput) inside the large project and then created the same flow in its own separate project. I ran each through the debugger, attempting to step into the JCN. Although in both cases, the simple JVN does not reference any of the other flows or Java code, it worked fine in the small project, but I got the Stack Overflow in the large project.
So, my question is...is there any way to increase the MaximumStackSize for the Debugger's JVM? I tried increasing it for the Broker (Execution Group), but that had no effect. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Tue Apr 21, 2009 1:47 pm Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
I dont use the visual debugger but to increase the maximum size of a JVM you pass it the -Xmx parameter.
I'm not sure if the debugger runs in a separate JVM (having not used it!) but i'm sure someone will tell us.
Maybe try adding this parameter to the command line that starts the toolkit to see if that helps, else try and find somewhere to add it on the debugger?
Hope that gives you something to try anyway! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Apr 21, 2009 1:57 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The question is, which JVM is it that's running out of heap?
Is it the Runtime's JVM? Or is it the Toolkit's JVM? |
|
| Back to top |
|
|
| Willtodd |
| Posted: Thu Apr 23, 2009 1:45 pm Post subject: |
|
|
Newbie
Joined: 11 Apr 2009
Posts: 6
|
Thanks for the feedback, guys!
Well, I tried the -Xmx option. Cranked it up as high as 1500M (Eclipse wouldn't let me set it much higher), but the results were the same. I also tried -Xms with some very low settings, thinking that maybe decreasing the initial Heap size would allow more space for the Stack, but this had no effect as well.
Some examples tried...
wmbt -vmargs -Xmx512M
wmbt -vmargs -Xmx1500M
wmbt -vmargs -Xmx1500M -Xms2M
wmbt -vmargs -Xms2M
Jeff, yours is a good question. I'm leaning towards the Toolkit's JVM, since the stack trace shows the exception occurring within the org.eclipse package, however, I'm suprised the above did not help. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Fri Apr 24, 2009 12:22 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
Whoops, looks like I gave you the wrong parameter to tune as I was tweaking the heap, not the stack size (although you may need to do both).
Try the -Xss option to tweak the stack size. |
|
| Back to top |
|
|
| Willtodd |
| Posted: Fri Apr 24, 2009 7:59 am Post subject: |
|
|
Newbie
Joined: 11 Apr 2009
Posts: 6
|
Thanks, WMBDev1. After increasing the minimum stacksize, I found that the StackOverlow did not occur, however I watched as the toolkit ran and ran, and its memory usage continued to grow seemingly with no end. It eventually climbed to nearly a Gig of memory usage before I finally killed it.
What this told me was that there really must be an infinite loop. I reviewed each of my Project dependencies one more time and found that I did in fact have a circular reference. Once I eliminated the circular project dependency, the debugger now works fine! In fact, I don't even need to increase my stack size.
For other newbies like myself, here's a tip: If you encounter this same issue, go to Run->Debug and review the settings of your Debug configuration. Under the Source tab, expand out all the tree elements under Source Path Lookup until you have reached the leaf node of every branch in the tree. If you never reach a leaf node, then you have a circular project reference, which must be resolved for successful debugging. I found it helpful to go through my project dependencies and map them out in a diagram to make sure they were set up properly.
Thanks again, WMBDev1 and MQJeff, for your help! |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
