Bug 14030 - No children returned for unitialized pointer to class
Summary: No children returned for unitialized pointer to class
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: varobj (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-28 07:35 UTC by Jens Elmenthaler
Modified: 2023-08-31 17:18 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Elmenthaler 2012-04-28 07:35:42 UTC
I have the following set of source/header files:

// ClassUnderTest.hpp
class ClassUnderTest  {

public:
	ClassUnderTest();
	virtual ~ClassUnderTest();

	bool mTrue;
	int mFifteen;
};

// ClassUnderTest.cpp
#include "ClassUnderTest.hpp"

ClassUnderTest::ClassUnderTest()
: mTrue(true),
  mFifteen(15)
{
}

ClassUnderTest::~ClassUnderTest()
{
}

// client.cpp
void client()
{
  ClassUnderTest *pCUT= new ClassUnderTest;  // breakpoint here -> 0 children, stepping to next line does not help
  delete pCUT;                               // breakpoint here -> OK
  pCUT = 0;
}

If I set a breakpoint at the first line in client(), pCUT has no children, and also stepping over this line will not yield the children.

If I set the breakpoint to the second line, i.e. pCUT is initialized already, I get the expected children.

It seems to be relevant that client() and the implementation of ClassUnderTest's methods are in separate source files. If I implement the methods in ClassUnderTest.hpp, or move client() into ClassUnderTest.cpp, everything works properly again.

I use a gcc 4.1.2.

This seems to be related to the changes for bug 376901, which now rely on the type information of the value instead of target type information calculated on the fly (get_target_type()).
Comment 1 Anton 2012-04-28 08:10:56 UTC
Probably you meant gdb bug 13393, cause the 376901 one is for Eclipse CDT.

And I have one more question: is the problem reproducible with "set print object" on or off?
Comment 2 Jens Elmenthaler 2012-04-28 10:14:27 UTC
(In reply to comment #1)
> Probably you meant gdb bug 13393, cause the 376901 one is for Eclipse CDT.
> And I have one more question: is the problem reproducible with "set print
> object" on or off?
Oh, yes I meant 13393.

The problem occurs only with "set print object on". The call tree of interest is:

mi_cmd_var_create
-> print_varobj
  -> varobj_get_num_children
    -> cplus_number_of_children
      -> adjust_value_for_child_access
         if on: it uses the target type in value, which has not set nfields yet
         if off: it uses get_target_type() from the type parameter, which then also resolves the nfields parameter.
Comment 3 Anton 2012-05-12 16:50:59 UTC
Unfortunately I cannot reproduce the problem with gdb HEAD and gcc-4.6.3. I see the children even if I set the breakpoint on pCUT declaration (certainly they have random values before initialization).  I still have children after pCUT is initialized and even after "0" assignment.

I am not sure, but it could be a gcc-specific behavior. Could you try a newer gcc?

Otherwise we could try to reproduce the problem without relying on uninitialized variable (which could give us random effect). E.g. is the problem is reproducible in your environment if client() will looks like this:

void client()
{
  ClassUnderTest *pCUT = 0;   // Initialize variable to avoid random effect
  pCUT = new ClassUnderTest;  // breakpoint here -> 0 children,
stepping to next line does not help
  delete pCUT;                               // breakpoint here -> OK
  pCUT = 0;
}