when V-pointer becomes NULL

[Jaydeep Chovatia]

Hi,

In my application object's v-pointer becomes NULL under load. I have Base class - Derive class type of hierarchy with pure virtual functions and my constructor/destructor are inline. I have checked Derive class member variables and they are fine (i.e. obj was not deleted anytime) only v-ptr is NULL.

Can somebody please point me in which all situations v-pointer become NULL?

I've already checked following links and none of them help:
http://stackoverflow.com/questions/3966039/why-does-my-c-object-loses-its-vptr
http://stackoverflow.com/questions/992786/vftptr-is-null


-jaydeep

 

[Jaydeep Chovatia]

Put a data breakpoint on the v-ptr in the debugger and you can easily catch

the moment when it turns NULL.



Cheers

Paavo

Hi Paavo,

Thanks for prompt response.
Problem with setting watchpoint is this problem occurs under load (not functionally), and under load v-ptr is keep changing so I cannot set specific watchpoint.

-jaydeep

 

[Jaydeep Chovatia]

Not sure what you mean by "under load" and "not functionally". Do you

want to say the problem appears only randomly? Sounds like some kind of

memory corruption, in this case the simplest remedy might be to run the

program under some memory checker like valgrind.



hth

Paavo

Hi Paavo,

Yes problem occurs randomly, i will run it under valgrind and then see how it goes.
Thanks for your help.

-jaydeep

 

[Victor Bazarov]

[...]

Yes problem occurs randomly, i will run it under valgrind and then see how it goes.

The most common IME reason for this was writing beyond array bounds. If
valgrind can tell you when you cross boundaries of dynamically or
automatically allocated memory, great. If not, bisection method should
do it, which means you need to find a test case in which it happens *all
the time*, and then manual checking of that pointer (offset 0 from the
object address, I suppose) should tell you approximately when it
happens. Not an easy task in your case, AIUI. All memory errors are
tricky...

If your problem is due to mishandling of dynamic memory (like deleting a
previously deleted pointer, for instance), sometimes it helps to get a
dynamic memory management library (like SmartHeap, for instance). Not
sure if those still exist, though... :-/

V

 

[Jorgen Grahn]

Not sure what you mean by "under load" and "not functionally".

Where I work, those two terms comes from testing.

If the system was e.g. a web server, a functional testing test case
would send a specific GET request and check that the response is the
expected one, and that a specific log message is generated.

A load test could e.g. send a mix of different requests at 1000 Hz for
an hour.

Do you want to say the problem appears only randomly?

It could be that[1] but load tests tend also to be the only ones to
reveal concurrency problems, broken handling of overload and so on
(including the one you mentioned, memory corruption).

/Jorgen

[1] Whatever "randomly" means. We tend to use it for events we don't
understand yet: a crash which happens every Friday at noon will
look random until we see the pattern.