Bug 256082 - display of variables is often stale
display of variables is often stale
Status: VERIFIED FIXED
Product: cnd
Classification: Unclassified
Component: Debugger
Dev
PC Linux
: P2 (vote)
: 8.2
Assigned To: Maria Tishkova
issues@cnd
82patch1-verified
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-21 15:40 UTC by tbrunhoff
Modified: 2016-12-13 08:51 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
shot of stale data (434.82 KB, image/jpeg)
2015-10-21 15:40 UTC, tbrunhoff
Details
exception at breakpoint (21.94 KB, image/jpeg)
2015-10-21 15:46 UTC, tbrunhoff
Details
gdb log (485.80 KB, text/x-log)
2015-10-21 15:47 UTC, tbrunhoff
Details
error from gdb 7.10 (23.39 KB, image/jpeg)
2015-10-21 17:30 UTC, tbrunhoff
Details
view of stale and current 'this' value. (238.79 KB, image/jpeg)
2016-11-03 20:59 UTC, tbrunhoff
Details
gdb log (59.88 KB, text/x-log)
2016-11-28 19:53 UTC, tbrunhoff
Details
snapshot (223.62 KB, image/jpeg)
2016-11-28 19:58 UTC, tbrunhoff
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tbrunhoff 2015-10-21 15:40:42 UTC
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
Comment 1 tbrunhoff 2015-10-21 15:46:00 UTC
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.
Comment 2 tbrunhoff 2015-10-21 15:47:28 UTC
Created attachment 156882 [details]
gdb log

The gdb log does not show anything obvious (to me).
Comment 3 tbrunhoff 2015-10-21 16:15:26 UTC
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.
Comment 4 tbrunhoff 2015-10-21 17:30:42 UTC
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.
Comment 5 tbrunhoff 2015-10-21 17:34:39 UTC
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.
Comment 6 henk89 2015-12-14 10:41:19 UTC
(In reply to tbrunhoff from comment
Comment 7 henk89 2015-12-14 10:42:07 UTC
(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.
Comment 8 henk89 2015-12-14 10:42:49 UTC
Also I'd like to look at the gdb log from gdb 7.10
Comment 9 tbrunhoff 2016-11-03 20:58:22 UTC
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.
Comment 10 tbrunhoff 2016-11-03 20:59:26 UTC
Created attachment 162760 [details]
view of stale and current 'this' value.
Comment 11 tbrunhoff 2016-11-03 21:08:29 UTC
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
Comment 12 Maria Tishkova 2016-11-09 14:25:04 UTC
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?
Comment 13 tbrunhoff 2016-11-09 14:48:02 UTC
> 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;
}
Comment 14 Maria Tishkova 2016-11-09 15:51:56 UTC
Can you send me a gdb log when you have watch "this" (which is correct, right?)  displayed in Variables view
Comment 15 Maria Tishkova 2016-11-14 15:26:53 UTC
Hello!

Can I get the GDB log of the latest case?

==Maria
Comment 16 tbrunhoff 2016-11-14 16:28:53 UTC
Yes, Maria, sorry.  I'll try to do that today.
Comment 17 soldatov 2016-11-21 09:40:39 UTC
I think it is not a P1. Bug exists for 11 months.
Comment 18 Maria Tishkova 2016-11-23 13:49:37 UTC
Waiting for GDB log as I cannot re-produce the problem
Comment 19 tbrunhoff 2016-11-28 19:53:40 UTC
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.
Comment 20 tbrunhoff 2016-11-28 19:58:53 UTC
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.
Comment 21 Maria Tishkova 2016-11-29 14:10:10 UTC
Looks like I finally re-produced the problem
Comment 22 Maria Tishkova 2016-12-01 14:23:58 UTC
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
Comment 23 Quality Engineering 2016-12-03 03:02:14 UTC
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)
Comment 24 soldatov 2016-12-13 08:49:40 UTC
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
Comment 25 soldatov 2016-12-13 08:51:07 UTC
NetBeans IDE 8.2 (Build 201612122312)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo