Community
Participate
Working Groups
Build Identifier: Eclipse 3.6.0 (build Id: I20100312-1448) & CDT 5.1.0.201004271740 (Build id: 201004271740) Internal error occurred during: "Label job" and Internal error occurred during: has children update. Eclipse 3.6.0 (build Id: I20100312-1448) CDT Version 5.1.0.201004271740 (Build id: 201004271740) OS: Ubuntu Linix 9.10 CPU: Intel Core2duo Memory: 2GB Debugging linux 2.6.31 running under Qemu via GDBserver. Error occurs when attempting to drill down into the contents of a *global* variable 'contig_page_info' - upon expanding contig_page_info.node_zones[] I encounter the two Null Pointer exceptions. Note, this problem is also reproducible in the packaged 3.5.2 eclipse+CDT distro. When running eclipse CDT as self-hosted (using PDE), I traced the source as a null pointer returned from getStackFrame() Line 52 with a backtrace as follows (for the hasChildren exception): CGlobalVariable(AbstractCVariable).getStackFrame() line: 52 CGlobalVariable(AbstractCVariable).getStackFrame() line: 48 CLocalVariable(AbstractCVariable).getStackFrame() line: 48 ClocalVariable$InternalVariable.getCDIVariable() line: 101 ClocalVariable$InternalVariable.getValue() line: 201 ClocalVariable(CVariable).getValue() line: 251 VariableContentProvider.hasChildren(Object, IPresentationContext, IViewerUpdate) line: 62 VariableContentProvider(ElementContentProvider).updateHasChildren(IhasChildrenUpdate) Line: 223 ElementContentProvider$3.run(IProgressMonitor) line: 200 Worker.run() line:54 *Note: that getStackFrame() returns null because the parent is neither an instance of AbstractCValue nor CStack, but is in fact an instance of CDebugTarget. Subsequently there is an unqualified attempt to deference the returned null pointer in getCDIVariable() line 101 - causing the exception: fCDIVariable = ((CStackFrame)getStackFrame()).getCDIStackFrame().createLocalVariable( (ICDILocalVariableDescriptor)getCDIVariableObject() ); I am attaching the log file and screen captures of the design instance of eclipse where the run-time instance of eclipse is stopped at the point where the null pointer originates for both exceptions. Reproducible: Always Steps to Reproduce: 1. build linux 2.6.31 kernel using CDT 2. Start Debugging (F11) - kernel running under Qemu (GDB attached gdbserver to Qemu) 3. Suspend kernel execution 4. Add global 'contig_page_info' to 'variables tab' 5. Expand 'contig_page_info' 6. Expand 'contig_page_info.node_zones[]'
Created attachment 166589 [details] .Log File
Created attachment 166590 [details] Screen capture design instance for Label fault
Created attachment 166591 [details] Screen capture design instance for "has Children update" fault
Created attachment 166743 [details] smokingGun
I Believe I have root caused the source of this problem. The smoking gun seems to be indicated in an attached screen capture of my design instance stopped in getLabel() where the root elements of the TreePath are shown as CGlobalVariable's but the third element is a CLocalVariable. The referred to capture is unimaginatively titled smokingGun with the area of interest highlighted by a red box. Tracing the instantiation of this third element has led to CindexValue.loadPartion() which erroneously assumes the variable to be created as a localVariable when, in this case, it is a globalVariable. Submitting (for your approval) is a patch file which solves this issue by creating the appropriately typed TreePath element. With this patch applied locally I am no long having a problem. /Regards
Created attachment 166745 [details] patch
This bug is causing me real pain. Is there any reasonable workaround?
This bug makes the CDT unusable. Can we get this fixed? At the very least can we get a workaround? The same action on Linux shows no signs of this bug but on my OSX machine it prevents debugging.
OK, I figured out that this is actually a problem with not having the correct parser turned on in the project settings. Everything works as expected now. I happened upon this solution by chance, so perhaps a better error message is appropriate. The NPE should probably not happen either...
I can confirm Kate's suggested fix, that worked for me too. I'm on Windows.
This also happens with PDT 3.6.0. I have not identified on which line, but it appears that it will not necessarily happen for a given code path and set of variable values, even if that same context triggered the bug. The bug appears to be in the Variables view. This happened with PDT 3.5, possibly before. After such an exception, PHP stopped with a memory exhaustion fatal error. I can not confirm that this is always the case though. I also cannot say whether the fatal error is the result or the trigger of Eclipse's bug.
I have produced a simple test case which reproduces this reliably when stepping from line 3 to line 4 (which triggers notices since there are undefined variables): <? echo "foo"; $db = new mysqli($mysqlHost, $mysqlUser, $mysqlPasswd, $mysqlDb); echo "bar"; ?> The exception shows when the Variables view is showing. After that, the variable labels are broken (empty). The exception shows again when running the next statement.
=> https://bugs.eclipse.org/bugs/show_bug.cgi?id=311127 (bugzilla ...)
(In reply to Filipus Klutiero from comment #12) > I have produced a simple test case which reproduces this reliably when > stepping from line 3 to line 4 (which triggers notices since there are > undefined variables): > <? > echo "foo"; > $db = new mysqli($mysqlHost, $mysqlUser, $mysqlPasswd, $mysqlDb); > echo "bar"; > ?> > > The exception shows when the Variables view is showing. After that, the > variable labels are broken (empty). The exception shows again when running > the next statement. Hi Filipus, the issue that you noticed is XDebug & PDT specific (see bug #503034). Thanks for pointing it out and providing simple test case, it helped a lot to find the root cause.
Thank you very much one time more Bartlomiej. It is an honor if this could help you, and I will wait the next release with impatience.
This bug was originally opened for a CDI problem. CDI no longer exists, as it was replaced by DSF and the problem does not happen there, so I'm marking as RESOLVED. Note that the recent activity in this bug was actually about PDT and has been tracked and resolved in Bug 503034.
