Virtual-Function-Table pointer is misplaced in object memory

[akiva pat]

I have found that when I dump a C++ object from memory to a file - it seems that there is a misplacement of the last Virtual-Function-Table pointer - in that appears at the beginning. The result is that the gdump information based on this object dump (using green hills) is incorrect. I copied the contents of the gdump information below. The executable is compiled in linux.

Basically MEIO::CameraStatus contains an item that relates to its parent class (line 188). Then it has 18 items that are all Diagnostics::EventsCounter items. Now for each Diagnostics::EventsCounter item there is a Virtual-Function-Table Info Pointer as its last item. All is fine and good except that the last item of MEIO::CameraStatus which is _selfReset is missing its last item of 4 bytes (which is the Virtual-Function-Table Info Pointer ). On the other hand - right before the first Diagnostics::EventsCounter item ("_vidErrors") - there is an extra 4 bytes which happens to be the Virtual-Function-Table Info Pointer. As I said the gdump information file does not see this.
Can anyone explain why the object memory "moves" the last Virtual-Function-Table Info Pointer to the beginning (right before _vidErrors) and is there a way to "fix" this?

///////////////////////////////////////////////////////////////////////////

"MEIO::CameraStatus" val:0x000002f0 ind208,-1) Struct-Begin Info
188: "" offset 0, Parent-Class Private Info C++ Struct ref = 114
189: "_vidErrors" offset 160, Member Info C++ Struct ref = 128
190: "_vdiErrors" offset 480, Member Info C++ Struct ref = 128
191: "_vidLogicalErrors" offset 800, Member Info C++ Struct ref = 128
192: "_vidDrops" offset 1120, Member Info C++ Struct ref = 128
193: "_resyncAttempts" offset 1440, Member Info C++ Struct ref = 128
194: "_imageRegMismatchErrors" offset 1760, Member Info C++ Struct ref = 128
195: "_camInvalidHeaderErrors" offset 2080, Member Info C++ Struct ref = 128
196: "_regWriteHILErrors" offset 2400, Member Info C++ Struct ref = 128
197: "_externalErrorFlags" offset 2720, Member Info C++ Struct ref = 128
198: "_i2cErrors" offset 3040, Member Info C++ Struct ref = 128
199: "_i2cNotOnTime" offset 3360, Member Info C++ Struct ref = 128
200: "_temperature" offset 3680, Member Info C++ Struct ref = 108
201: "_readTemperatureErrors" offset 4096, Member Info C++ Struct ref = 128
202: "_readFrameCountErrors" offset 4416, Member Info C++ Struct ref = 128
203: "_histogramsMismatchErrors" offset 4736, Member Info C++ Struct ref = 128
204: "_ccftDecisionsMismatchErrors" offset 5056, Member Info C++ Struct ref = 128
205: "_ccftCRCErrors" offset 5376, Member Info C++ Struct ref = 128
206: "_selfReset" offset 5696, Member Info C++ Struct ref = 128
207: "" val:0xffffffff ind187,-1) Struct-End Info



128: "Diagnostics::EventsCounter" val:0x00000028 ind138,-1) Struct-Begin Info
129: "_handler" offset 0, Member Info Reference to C++ Struct ref = 138
130: "_name" offset 32, Member Info Pointer to C++ Char
131: "_total" offset 64, Member Info C++ UInt
132: "_inCurrentFrame" offset 96, Member Info C++ UInt
133: "_consecutiveFrames" offset 128, Member Info C++ UInt
134: "_severity" offset 160, Member Info C++ Struct ref = 123
135: "_eventAppData" offset 256, Member Info Pointer to C++ Struct ref = 121
136: "__vptr" offset 288, Virtual-Function-Table Info Pointer to C++ Struct ref = 490
137: "" val:0xffffffff ind128,-1) Struct-End Info

[razzle]

The result is that the gdump information based on this object dump (using green hills) is incorrect.

In that case why don't you ask the providers of gdump?

[OReubens]

"memory dumping" like you're doing here is not part of the c++ standard,
so the results will be dependant on the compiler used (even version could matter) and which settings you used.
a vtable isn't even the only way for a compiler to achieve a solution for virtual functions.

looking at the above.
CameraStatus only has a reference to new virtuals
and it contains a reference to the parent object, for which you can find it's vtable there.

[akiva pat]

Well, from what you're saying - there is nothing that I can do about this issue as it is non standard and somewhat arbitrary. Am I correct?

What is your point from stating:

"looking at the above.
CameraStatus only has a reference to new virtuals
and it contains a reference to the parent object, for which you can find it's vtable there. "

[OReubens]

I meant to say that how the compiler solves the 'virtual' issue is entirely proprietary to the compiler. Many compilers solve it with a vtable, but that isn't the only approach.


Part2:
it's how I made sense of it...
somewhat hard to make much sense without also seeing the class definition.