This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | display of variables is often stale | ||
---|---|---|---|
Product: | cnd | Reporter: | tbrunhoff <tbrunhoff> |
Component: | Debugger | Assignee: | Maria Tishkova <mromashova> |
Status: | VERIFIED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | Dev | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
shot of stale data
exception at breakpoint gdb log error from gdb 7.10 view of stale and current 'this' value. gdb log snapshot |
Created attachment 156881 [details]
exception at breakpoint
It is possible that the attached 'debugger error' is related. Perhaps the stale variables would have been sampled after the non-existent variable cited in the error message, but update of variable values stops at the point of the error.
Created attachment 156882 [details]
gdb log
The gdb log does not show anything obvious (to me).
The debugger error seems to match this: https://sourceware.org/bugzilla/show_bug.cgi?id=11912 and was eventually resolved here: https://sourceware.org/bugzilla/show_bug.cgi?id=8888 However, the notes say that it was targeted for gdb version 7.6 which is what I am running. Created attachment 156887 [details]
error from gdb 7.10
Still regarding the breakpoint shown in the first attachment, after building and running gdb version 7.10, the message changes to a complaint about the release() method. See the screenshot.
The hierarchy of this class is:
class IBase {
virtual int release() = 0;
...
class MediaObj : public IBase {
virtual int release();
...
class MxfMediaObj : public MediaObj {
// no release() method
It appears that gdb is confused about whether MxfMediaObj has the release() method. So adding a declaration and implementation that just calls the parent class:
class MxfMediaObj : public MediaObj {
virtual int release()
{ return MediaObj::release(); }
...
That makes the error go away when I hit the breakpoint.
The question is, why is it checking release(). The base class, IBase, has only 3 virtual methods: class IBase { protected: virtual ~IBase() {} public: virtual int preserve() = 0; virtual int release() = 0; }; ... and release() is the first one if it traversed the methods in reverse order. (In reply to tbrunhoff from comment (In reply to tbrunhoff from comment #2) > Created attachment 156882 [details] > gdb log > > The gdb log does not show anything obvious (to me). It says that checking for updates failed due to an incorrect variable object. For some reason GDB failed to lookup the field specified. It may have been confused by the lookup error from the issues above but I can't guarantee. Also I'd like to look at the gdb log from gdb 7.10 This is still an issue. In an effort to simplify, I've attached a screenshot of the Variables window where the 'Variables' view of 'this' is different from the 'Watches' view of 'this'. The watch is the correct value, the the Variables view is from the previous breakpoint which happens to be the stack frame above this. This happens frequently, generally when the name of the variable is the same between breakpoints. Created attachment 162760 [details]
view of stale and current 'this' value.
Product Version: NetBeans IDE Dev (Build 201609190002) Updates: Updates available Java: 1.8.0_45; Java HotSpot(TM) 64-Bit Server VM 25.45-b02 Runtime: Java(TM) SE Runtime Environment 1.8.0_45-b14 System: Linux version 4.1.13-100.fc21.x86_64 running on amd64; UTF-8; en_US (nb) User directory: /home/toddb/.netbeans/dev Cache directory: /home/toddb/.cache/netbeans/dev I can see Variables screenshot attached but cannot find Watches (with the correct values). Is there any small project I can reproduce the problem with? > cannot find Watches
Maria, there are two 'this' values in the attached screenshot. The blue one is a watch value and the green one is the 'variables' version of 'this' that is out of date. This is how the variables pane works.
I don't have a simple project (I have several very complex, proprietary projects :-). I suspect it has to do with some level of complexity. For example the code below has the structure of what shows this issue, but 'this' is always up to date.
#include <cstdlib>
using namespace std;
class A {
public:
int a;
char* b;
double c;
void chew() {
a += c;
}
};
class B {
public:
A x;
int y;
char* z;
float apple;
void masticate()
{
x.chew();
}
};
/*
*
*/
int main(int argc, char** argv)
{
B bInstance;
bInstance.masticate();
return 0;
}
Can you send me a gdb log when you have watch "this" (which is correct, right?) displayed in Variables view Hello! Can I get the GDB log of the latest case? ==Maria Yes, Maria, sorry. I'll try to do that today. I think it is not a P1. Bug exists for 11 months. Waiting for GDB log as I cannot re-produce the problem Created attachment 163059 [details]
gdb log
The attached log is a simple repro of the issue.
- start debug session with a breakpoint
- hit the breakpoint, and double click two levels down in the stack
- the this pointer has the right numeric value, but is interpreted as the this pointer from the top-of-stack this pointer.
Created attachment 163060 [details]
snapshot
The attached snapshot shows the variables and stack. Note that the current stack frame is two levels down, and 'this' should be a MediaClipDesc. But instead, it is being interpreted as a MxfVbeLookup instance which was the context before double clicking on the stack frame two levels down. Even the 'watch' variable 'this' pointer is interpreted incorrectly.
Also note that if I added the watch variable for 'this' after double clicking on the stack frame two levels down, both 'this' instances get reinterpreted correctly, alhtough that does not always work.
Looks like I finally re-produced the problem The problem was locals were not updated when frame was changed. fixed in local cnd release82 repository (on enum), will be transplanted to releases/release82 and trunk later this week changeset: 313525:df2d0ac2b013 branch: release82 tag: tip user: Maria Dalmatova <mromashova@netbeans.org> date: Thu Dec 01 17:17:24 2016 +0300 summary: fixed bz#256082 - display of variables is often stale Integrated into 'main-silver', will be available in build *201612030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/4782adf0ff11 User: Maria Dalmatova <mromashova@netbeans.org> Log: fixed bz#256082 - display of variables is often stale need to re-request locals after current stack frame is changed (transplanted from df2d0ac2b0132c9542621e5e29c17ee34c9519b6) Verified in internal NetBeans 8,2 patch 1 build. Code: int foo(int x) { int y = x; if (y == 0) { // line breakpoint return 0; } y = y + foo(y - 1); } int main(int argc, char** argv) { foo(10); return 0; } Scenario: - set line breakpoint - press Continue 3 times - change current frame in Call Stack tab ==> Before NetBeans 8.2 patch 1: IDE doesn't update 'y' variable Now: ok NetBeans IDE 8.2 (Build 201612122312) |
Created attachment 156880 [details] shot of stale data Frequently (as in: every debug session), some of the variables displayed when stopped at a breakpoint are stale. Most frequently, the value of 'this' is from an earlier breakpoint. It also seems to coincide with stopping at the same breakpoint without other breakpoints being hit in between. Sometimes I can get the display to update by putting in a watch for the same variable. The attached screenshot shows how even that did not work. The variable 'desc' is a reference to a structure whose contents changes with every call. The breakpoint can be seen on the left. And on the right is a display of 'desc' as both a variable and a watch. Note the difference in the values of the members. The watch values are correct. The 'variable display' version shows values from 6 breakpoints earlier. I was finally able to get the display to update by switching stack frames and then switching back. GNU gdb (GDB) Fedora 7.6.1-46.fc19 Product Version: NetBeans IDE Dev (Build 201510120002) Updates: Updates available Java: 1.8.0_45; Java HotSpot(TM) 64-Bit Server VM 25.45-b02 Runtime: Java(TM) SE Runtime Environment 1.8.0_45-b14 System: Linux version 3.14.27-100.fc19.x86_64 running on amd64; UTF-8; en_US (nb) User directory: /home/toddb/.netbeans/dev Cache directory: /home/toddb/.cache/netbeans/dev