QtCreator debugger whats happened?

Simon Platten

I am using QtCreator

Qt Creator 4.2.1
Based on Qt 5.8.0 (GCC 5.3.1 20160406 (Red Hat 5.3.1-6), 64 bit)
Built on Jan 20 2017 01:20:15
From revision 7071b61e02

At some point the debugger watch window has stopped working properly, I know that previously I have been able to expand pointers and drill down into the class to reveal the state of members. In a lot of cases now I get the pointer displayed and then <not accessible> where the address would normally be displayed, if I attempt to expand the pointer it shows just [0] and nothing else.

Parameters do not always appear in the "Locals and Expressions" window either. I've also noticed that 'this' no longer appears when debugging an object.

This is making development very difficult. The question is, is this an option hiding somewhere or is it a bug?

Simon Platten

Anything? Its so frustrating, the debugger is really quite useless without this basic functionality.

jsulm

@Simon-Platten On what OS are you?
Do you see anything in the "Debugger Console" in QtCreator?

Simon Platten

Unfortunately no, the debugger console is completely empty. O/S is RedHat 7.2

Simon Platten

Am I the only one experiencing this problem?

If I start the application, 'this' is visible in the debugger window, then at some point it disappears, my main application class which is derived from QMainWindow works and if I insert a breakpoint in the PaintEvent method I can see 'this' is still visible.

I have a static member in the application class, and its this member that contains all the interesting stuff that I want to debug. The static member has a collection of widgets, 'this' is not visible from the PaintEvent of any of these widgets.

A static has a scope which is global to all instances of that class, so stopping in any one of the methods associated with the static member should give a 'this' and address of the static member, shouldn't it ?

The really interesting thing is that if I create a local variable and assign it to 'this', for example:

    clsGraphic* pobjThis = this;

Compiles fine with no warnings or errors, I then stop in the method and step over the above line, it doesn't appear in the Locals and Expressions window either.

jsulm

@Simon-Platten You should not use any static variables if their classes are derived from QObject/QWidget!
QObject/QWidget instances should not be initialized before QApplication instance is created - static variables are.
I would first fix this.

Simon Platten

@jsulm, please explain why this is an issue?

I have a linked list with a static member that points to the head of the list, the linked list is derived from QObject as it uses signals and slots.

If this is the real issue then it's a serious limitation.

jsulm

@Simon-Platten Why do you have a STATIC member which points to the head of the list? What happens if you create more than one instance on that list? To which head of the list will that static member point?
Example:

MyList list1;
list1.append(...);
...
MyList list2;
list2.appen(...);
...
list1.head <- To which lists head does it point if "head" is static?

If this static member is a pointer then there is no issue with QApplication instance. But I don't get why this member is static.

Simon Platten

@jsulm, there will only ever be one list of this type in the application. The head of the list is a static pointer, simply because all instances of that class will get the same head pointer, if it isn't static, how else would they get it? The alternative is for every node to traverse the list everytime to find the head. There are over a hundred nodes in the list...

jsulm

@Simon-Platten said in QtCreator debugger whats happened?:

there will only ever be one list of this type in the application. The head of the list is a static pointer, simply because all instances of that class will get the same head poi

I don't get it: you say you will have only one instance ("there will only ever be one list of this type in the application") and then you say: "simply because all instances of that class". So, how many instances are you going to have? And even if there will be only one instance there is no reason to have head as static.
Each instance can simply have its own head pointer (not static):

template<typename T> class MyList
{
private:
    struct Node
    {
        T data;
        Node* next;
    };
    Node* first; // This is actually the pointer to the head
};

Simon Platten

@jsulm, in your example this means that every node has its own 'first' pointer, where as a static 'first' would be common to all nodes of that type without having to maintain it for every instance, just the static 'first' would be modified. This is not a very elegant solution. This is exactly the sort of thing that static members are intended for.

To clarify, I have a single class that is used for the nodes and the linked list, there is only one instance of this linked list in the application. There are well over 100 nodes in the linked list.

Can you explain why using statics would cause the debugger to behave this way?

jsulm

@Simon-Platten Not every node but every list has its own pointer to the first element in the list.
Maybe we are talking about different things? What do you mean if you say "node"? Don't you mean "list"? Node is actually one entry in a list/tree.
MyList - a class representing a list.
Node - an entry in the list (contains a data field and pointer to next node).
head - points to the first node in the list.
Maybe I just don't understand your use case and you really want all MyList instances to handle exactly same data (in this case a static head pointer is the way to go).
I don't know whether this static is the problem with the debugger - that was just an assumption.

Simon Platten

@jsulm, In my code the list and the node are one in the same, thats why I have a static pointer to head. Every node has access to the head of the list, I don't need another structure or class to define the list, because the list and the nodes share the same class.

Simply example:

    class clsNode {
    private:
       static clsNode* mpobjHead;
       clsNode* mpobjNext;
  /* other members... for the node instance */
    public:
        clsNode();

        static clsNode* pobjGetHead() { return mpobjHead; }
        clsNode* pobjGetNext() { return mpobjNext; }
    };

SGaist

Hi,

Since you are using Qt and you are implementing a linked list, why not use QLinkedList ?

Simon Platten

@SGaist , Thank you, I'm pretty sure that the implementation of my linked list is ok, as this application is working fine without problems and the linked list has been established for over a year now....its just the debugger which is not behaving well...pointers and 'this' not showing correctly, in every other aspect the application and debugger is ok....so frustrating.

Simon Platten

I'm still no further forward in finding a reason why the debugger has stopped working properly, its very annoying and seems to be something in my code that has broken the debugger, but how can anything in the code being debugged break the debugger?

OlivierDuguay

I don't think this is a problem in your code... I have almost the same problem since I upgraded to Qt Creator 4.2.1 with Desktop Qt 5.7.1 MSVC2015_64bit.

I can't access "this" pointer whichever the class, and one time out of two (and even more) I also can't access member object/variable...

So annoying when it come to debug the code... I have to "qDebug" everything...

Hope someone will find what's wrong...

(PS. I don't have any static variable/object, so IT AIN'T THE PROBLEM)

Simon Platten

@OlivierDuguay, thank you for posting, nice to know I'm not the only one experiencing this, now how do we escalate this issue so someone at Qt investigates the problem?

jsulm

@Simon-Platten You can file a bug report if there isn't one already (https://bugreports.qt.io/secure/Dashboard.jspa)

Simon Platten

@jsulm, thank you, I'll do it now.