Find the place for crash due to overwrite of the vtable

Question

3.00/5 (1 vote)

See more:

Hello,

I have Class A, that has a virtual method. (and implements it)
Class B inherits from Class A, but does not implement the virtual method.

I have a map of objects of class B.

I have a very long program, and it adds a lot of times objects to the map.

I run the program randomly, and once in about 4-5 runs, it crashed with a message of:
"::`vftable' (NULL:0)".

It is an unhandeled exception and I can't go back to the place it happened.

My guess is that the virtual table has been overwritten somehow, but I can't find when it happens (and as I said, it happens just once in 4-5 runs).

Is there a way I can find, using the debugger, the point and moment the virtual table is overridden?

Thanks

Posted 2-Dec-14 3:54am

user_code

Updated 2-Dec-14 10:04am

v3

Add a Solution

Comments

Fredrik Bornander 2-Dec-14 9:59am

Are you doing anything silly with pointers and accidentally overwrite the vtable for some of your objects? Do you have any potential buffer-overruns?

Philippe Mori 2-Dec-14 19:18pm

Also using deleted or uninitialized pointers can cause problems...

ThunderWiring 14-Dec-16 4:41am

i am experiencing the same issue.
Have you found what might have caused the problem?

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CPallini · Accepted Answer · 2014-12-02T05:50:00

Solution 2

Quote:
Is there a way I can find, using the debugger, the point and moment the virtual table is overridden?

Most likely your code overwrites the vtable. If yoyu are using Visual Studio the Data Breakpoints[^] could interest you.

Posted 2-Dec-14 5:50am

CPallini

Comments

Maciej Los 2-Dec-14 13:23pm

+5

CPallini 2-Dec-14 13:58pm

Thank you Maciej!

Sergey Alexandrovich Kryukov · Accepted Answer · 2014-12-02T04:30:00

Solution 1

First of all, it makes no sense to use a class with non-implemented virtual function. If this class is abstract, used only as a base class for some other classes, this is fine, but you should not instantiate it.

Now, there is no such concept as overriding of a virtual table. You override a function. Each class using virtual function, generally is associated with its individual virtual table, that's all. So, you cannot find "the point and moment the virtual table is overridden" because such point does not exist. Virtual table is formed during the compilation, linking and, ultimately, loading of the project (essentially, loading — because the virtual table is the object residing in your RAM). It always exists when your application is started to execute. A virtual table itself is a static object, even though it is used to achieve dynamic dispatching of the calls.

Instead, you need to run the application under the debugger, find out in what line the exception is throwing, then put a break point on that line and inspect the context before executing this line to find what's wrong. Not being able to reproduce the same problem in 100% of cases can be nasty, but this debugging problem should be solvable.

—SA

Posted 2-Dec-14 4:30am

Sergey Alexandrovich Kryukov

Updated 2-Dec-14 5:16am

v2

Comments

Maciej Los 2-Dec-14 11:09am

5ed!

Sergey Alexandrovich Kryukov 2-Dec-14 11:15am

Thank you, Maciej.
—SA

Richard MacCutchan 2-Dec-14 12:41pm

He means overwite not override

Maciej Los 2-Dec-14 13:24pm

A small detail... ;)

Richard MacCutchan 2-Dec-14 13:32pm

Actually quite a large one.

Sergey Alexandrovich Kryukov 2-Dec-14 13:39pm

Oh yes, this would be quite a big detail. Again, OP talked about overriding, but this is based on misconception. I my answer, I merely tried to dismiss this misconception. We don't really know what actually happened, it needs some investigation; this is exactly what I suggested.
—SA

Sergey Alexandrovich Kryukov 2-Dec-14 13:31pm

At this moment, OP uses the word "overridden"; please see.
It would not change anything, because both "override" and "overwrite" concepts are not applicable to the virtual table. This is the point.
—SA

Richard MacCutchan 2-Dec-14 13:32pm

Why? If something overwrites the vtable then all sorts of crazy things will happen.

Sergey Alexandrovich Kryukov 2-Dec-14 13:34pm

(I edited the comment above.) Yes, but I am sure this is not what really happened. In worst case, though, it could be garbage in memory.
—SA

user_code 2-Dec-14 16:06pm

thanks for answer. my mistake, i meant "overwritten".
My suspect is the somehow the vtable is being overwritten, as I get the error of "::`vftable' (NULL"

Sergey Alexandrovich Kryukov 2-Dec-14 19:46pm

All right. You really need to locate at least the place where the exception is thrown.
—SA

user_code 3-Dec-14 1:27am

it is really hard or even impossible. I know which line leads to the crash as the code saved the methods stack when it crashes, but this line is called hundreds of times and works fine.
Just once in 4-5 runs, and after the line is called a lot of times before in the specific run, it suddenly crash.

Sergey Alexandrovich Kryukov 3-Dec-14 1:43am

Hundreds times certainly makes the problem more difficult. Initially, I responded to your "about 4-5 runs". Nevertheless, you need some research. Use logging System.Diagnostic.EventLog and collect some information on the context (states of the relevant class instances, values of some variables, use RTTI, etc) and analyze the makes the difference just at the crash.

Besides, analyze the problem theoretically. See if you can potentially put some memory garbage; in C++, this is too easy to do. Pay special attention if you use multiple threads; race condition can make the problem appearance random.

—SA