#### Archived

This topic is now archived and is closed to further replies.

# gdb weirdness

This topic is 5749 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I''m trying to debug with gdb and it''s telling me stuff that doesn''t make any sense to me. I have a data structure that some part of my program is corrupting. I had the program assign a pointer to it while it is still known to be in an uncorrupted state. I set a breakpoint after the assignment so I could then set a watchpoint on the data structure (I''ve never done this before and I''m not sure if that''s viable, but that isn''t the point of this post, so for now that doesn''t matter). After I reached the breakpoint, I examined the data structure (which is of a type named Ambition). This is where I''m getting confused. I know that part of the Ambition structure that gets corrupted is a pointer it contains named site, which is inherited from the class Concern. I had a hard time figuring out how to access inherited data members in gdb, but I finally discovered that you could do it by casting to the base class in which the data member is declared. So, I asked gdb to print out badBoy (which is the name of the pointer I set the breakpoint on) derefernced both as the base class Concern and as the type of object it really is (Ambition), and this is what I get
(gdb) p *(Concern*)badBoy
$6 = { Subject = { original = 0x17ef64, notable = 1 ''\001'', secrecy = 1, refCount = 9999, snapshot = 0x0,$vf = 0xd980
},
mac = 0x15c22c,
target = 0x16f764,
nextTarget = 0x348d1c,
agent = 0x0,
phase = 1425964,
defender = 0x1,
startDate = 1428636,
phaseBeginDate = 0,
site = 0x2068f,
brief = 0x15a9d4,
tool = 0x0,
value = 61
}
$7 = { VirtualAmbition = { Concern = { Subject = { original = 0x17ef64, notable = 1 ''\001'', secrecy = 1, refCount = 9999, snapshot = 0x0,$vf = 0xd980
},
mac = 0x15c22c,
target = 0x16f764,
tool = 0x348d1c,
nextTarget = 0x0,
agent = 0x15c22c,
phase = PREP,
defender = 0x15cc9c,
startDate = 0,
phaseBeginDate = 0,
site = 0x15a9d4,
brief = 0x0,
hunger = 61,
desperation = 2,
value = 1580
},
nextGoal = 0x0,
mother = 0x0,
desperation2 = 1499906909
},
belief = 0x23e8336,
bestNicheBet = 0x0,
defendAgainst = 0x0,
righteous = 137 ''\211'',
wildCard = 187397321,
next = 0x17ee54,
bumscoop1 = 0xc78366ee
}
(gdb)

What I don''t get is how some of the data members inherited from the Concern class have different values depending on if you are looking at this structure as a Cocncern (base class) or Ambition (actual type of object). The values of tool, nextTarget, phase, agent, site, and others are different. From the values I checked, it looks like the ones in the second listing are all correct. I do not have subclasses duplicating variable names from base classes. I know next to nothing about how compilers work, but my (bad) guess is that for some reason the compiler decided that the Concern portion of an Ambition object does not have the same blueprint as a regular Concern object. This is also inferred from the fact that the data members are listed in a different order in the casted and not-casted print commands (assuming the order in which gdb displays data members is meaningful). If this is true, is it common compiler practice, and then how does casting to a base class work (not generate tons of errors when dereferencing)if the base-class portion of the sub-classed object is allowed to look different from an object which is only of type base-class? Or is this just some quirk of gdb? I have another question. As I mentioned earlier, the only way I''ve found to access inherited data members in gdb is by casting to the base class which declared the member. For example, to access badBoy''s site member (inherited from class Concern), I use "p ((Concern*)badBoy)->site". Does anybody know if there is an easier way of doing this? I''ve found all those parantheses to be necessary. The less typing I have to do the happier I am. Thanks in advance, Sean

• ### Forum Statistics

• Total Topics
628711
• Total Posts
2984342

• 23
• 11
• 10
• 13
• 14