17 Apr
2003
17 Apr
'03
6:27 p.m.
Hi I know it's not a C++ specific list, but maybe someone can shed some
light on this. I have encountered this problem with all C++ compilers
and I don't know exactly what it is.
Sometimes I might make a class, and inherit it from another. Or, the
class just has virtual functions in it ( I am planning to derive others
from it). In any case, I am trying to access a virtual function in an
instantiated instance at runtime, and when I do, the program crashes. I
try to see if it is reaching the function (printf("Hi!") from inside or
something), but it doesn't. It is like the vtable is being destroyed
somehow.
So, is it possible to smash the vtable of a class? I can't imagine all
compilers have the same quirk, because I have seen this problem on half
a dozen compilers. Usually it is in classes where I am doing heavy
memory management. My guess is that the vtable can be corrupted somehow
by a smash.
17 Apr
17 Apr
8:26 p.m.
<quote who="Nick Tsocanos">
Sometimes I might make a class, and inherit it from
another. Or, the
class just has virtual functions in it ( I am planning to derive others
from it). In any case, I am trying to access a virtual function in an
instantiated instance at runtime, and when I do, the program crashes.
...
You don't give much detail, but here my guess:
Methods of parent classes (other than the constructor) are not available
from within the constructor of derived classes. The object is not
'completed' until after the constructor exits.
See B. Stroustrup's "The C++ Programming Language" for the gritty details.
Dynamic runtime languages (e.g. Python) do not have this problem... so it
might be a bit suprising depending on your background.
--aws
mailto:andy*a2hd,com
http://www.a2hd.com/
10:12 p.m.
Nick Tsocanos wrote:
So, is it possible to smash the vtable of a class? I
can't imagine all
compilers have the same quirk, because I have seen this problem on half
a dozen compilers. Usually it is in classes where I am doing heavy
memory management. My guess is that the vtable can be corrupted somehow
by a smash.
I think this possible, as it is possible to overwrite the stack data of
a running function, including its return adress, etc. without cousing a
segfault.
Can you provide a minimal code fragment that demonstrates your problem?
This should make it possible to see what exactly goes wrong.
Regards,
Lukas
18 Apr
18 Apr
1:36 a.m.
You don't give much detail, but here my guess:
The problem is I have not fully understand why it happens.
One, at runtime, it seems to get smashed, and when I execute a virtual
function it goes off somewhere else and crashes. When I fix my program
some more, and make them virtual again, it compiles and runs fine. My
only guess is that I smashed the class somehow, but the smash is
baffling, because the program works fine, it just the when I execute a
virtually defined function in the class when it fails.
class BadFoo()
{
virtual void ThisFooWillDie() { printf("Fooey!"); }
void naughtyFunctionThatIsBeingWorkedOn() {
printf("I will do something heinous and sinister to foo but
only to Foo but it will not be obvious what it is.");
}
};
BadFoo fooWillBlowUp;
fooWillBlowUp.naughtyFunctionThatIsbEingWorkedOn();
fooWillBlowUp.ThisFooWillDie();
CORE DUMP
GAME OVER
Another, is when I am linking, it complains about the vtable and won't
compile. This error leaves me baffled because usually the class compiled
and ran before without any problems, and I didn't change it at all.
class thisFooWillNotCompile
{
public:
virtual void thisFooMakesMeAngry() = 0;
};
class thisFooIsNoGood : public thisFooWillNotCompile
{
public:
void thisFooMakesMeAngry() { printf("I will not link I will say
vtable blah blah blah and die..\n"); }
};
Sorry I am vague but, if I knew why this was happening, I would be an
advanced C++ programmer.One of them appears to be an error in my code,
but the way it manifests itself is weird. The other is a compiler
problem that I just do not know why it happens and honestly it shouldn't
because the code worked fine before and is correct syntax, but it won't
link. It says something about the vtable but I can't remember now what
it said. It happened a week ago.
9:26 a.m.
Hi,
Another, is when I am linking, it complains about the
vtable and won't
compile. This error leaves me baffled because usually the class compiled
and ran before without any problems, and I didn't change it at all.
class thisFooWillNotCompile
{
public:
virtual void thisFooMakesMeAngry() = 0;
};
class thisFooIsNoGood : public thisFooWillNotCompile
{
public:
void thisFooMakesMeAngry() { printf("I will not link I will say
vtable blah blah blah and die..\n"); }
};
Sorry I am vague but, if I knew why this was happening, I would be an
advanced C++ programmer.One of them appears to be an error in my code,
but the way it manifests itself is weird.
You always need a virtual destructor in the class if you do inhertance.
Otherwise upon destruction of the derived class, the baseclass destructor
will not be called.
Cheers,
Niels.
so:
class thisFooWillNotCompile
{
public:
virtual ~thisFooWillNotCompile(); // ADD THIS!
virtual void thisFooMakesMeAngry() = 0;
};
class thisFooIsNoGood : public thisFooWillNotCompile
{
public:
virtual ~thisFooIsNoGood(); // ADD THIS!
void thisFooMakesMeAngry() { printf("I will not link I will say vtable
blah blah blah and die..\n"); }
};
9:28 a.m.
New subject: [linux-audio-dev] OFF-TOPIC - C++ questions -> read C++ FAQ
Hi all,
For thos having trouble with C++, check out:
http://www.parashift.com/c++-faq-lite/
This is a _very_ good FAQ!
Cheers,
Niels.
9:58 a.m.
[...]
You always need a virtual destructor in the class if
you do inhertance.
Otherwise upon destruction of the derived class, the baseclass destructor
will not be called.
I doubt that is the problem. You should use virtual destructors when
deleting using a pointer so the correct destructor is called but when
you know the pointer is of the correct type or you allocate the instance
on the stack then the correct destructor will be called and I think the
baseclass destructor(s) will be called also even if they are not
virtual.
--ms
3:49 p.m.
You always need a virtual destructor in the class if
you do inhertance.
Otherwise upon destruction of the derived class, the baseclass destructor
will not be called.
Oops, yep, I forgot that, those were just quickies to demonstrate what I
was meaning.
GCC will warn you that the class doesn't have a virtual destructor.
Hrmm, it seems these problems are not C++ problems but something to do
with KDevelop studio. Today, it just went berzerk, and kept saying ld
could not load anymore files. I closed the program, opened it again, and
it ran and compiled fine.
I think KDevelop studio has a few bugs in it still.
Anyways thanks for the help but I think I discovred it's not a C++
problem but something to do with my IDE.
11:47 p.m.
On Fri, 2003-04-18 at 08:48, Martijn Sipkema wrote:
[...]
Well whatever the problem was, it is not happening anymore..
I really don't know what the problem is and to be honest, I don't think
anyone else on the list could tell me unless they were here to see the
problem happen and analyze it when it happens.
It may have been something I did in my code. I was building a somewhat
complicated memory management system for LADSPA plugins and the problem
started happening.
Once I fixed the code where it worked properly the problem went away.
I just did not manage to find out what exactly was causing the problem
or why.
I have no idea but I am pretty sure I did something with unitialized
memory, and than later fixed it without realizing it . I am pretty sure
I it was a pointer problem.
I can not run gdb on my program, it won't work. The code is too hard to
debug by just looking at it. The only way I can debug is to put hundreds
of printf() into the code. That was how I found log( blah ) was making
NAN as well. I have learned to live without a debugger, but it sucks,
because I really need it.
You always need a virtual destructor in the class
if you do inhertance.
Otherwise upon destruction of the derived class, the baseclass destructor
will not be called.
I doubt that is the problem. You should use virtual destructors when
deleting using a pointer so the correct destructor is called but when
you know the pointer is of the correct type or you allocate the instance
on the stack then the correct destructor will be called and I think the
baseclass destructor(s) will be called also even if they are not
virtual.
--ms
22 Apr
22 Apr
8:07 a.m.
>>>> "Nick" == Nick Tsocanos
<nicktsocanos(a)charter.net> writes:
Nick> I can not run gdb on my
program, it won't work. The code is
Nick> too hard to debug by just looking at it. The only way I can
Nick> debug is to put hundreds of printf() into the code. That was
Nick> how I found log( blah ) was making NAN as well. I have
Nick> learned to live without a debugger, but it sucks, because I
Nick> really need it.
What is your problem with gdb? I have no problem debugging complex
programs with it. I use the setting -ggdb3 and compile with
optimization off.
Immanuel
--
It is a profoundly erroneous truism, repeated by all copy-books and
by eminent people when they are making speeches, that we should cultivate
the habit of thinking about what we are doing. The precise opposite is the
case. Civilization advances by extending the numbers of important operations
which we can perform without thinking about them. Operations of thought are
like cavalry charges in battle -- they are strictly limited in number, they
require fresh horses, and must only be made at decisive moments.
-- A.N. Whitehead
--
Immanuel Litzroth
Software Development Engineer
Enfocus Software
Kleindokkaai 3-5
B-9000 Gent
Belgium
Voice: +32 9 269 23 90
Fax : +32 9 269 16 91
Email: Immanuell(a)enfocus.be
web : www.enfocus.be
***************************************************************************
7694
days inactive
7699
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
6 participants
participants (6)
-
Andy Schmeder -
Immanuel Litzroth -
Lukas Degener -
Martijn Sipkema -
Nick Tsocanos -
Niels A. Moseley