Pointer problem: compiles but crashes

[Rui Maciel]

I've been fooling around with a test class and meanwhile I stumbled on a
pointer problem.

I have two classes, one being nested in the other. I've wrote a method in
the nested class that would set a nested class's member pointer as a
pointer to an instance of the other class. Here is the code:

<code>
template <class tData>
class Foo
{
* * * * // snip
public:
class Bar
{
protected:
Foo<tData> *m_cursor;
public:
//snip
void point_to(Foo<tData> &);
}; * *
};

// snip

template <class tData>
void Foo<tData>::Bar::point_to(Foo<tData> &pointed_to)
{
this->m_cursor = &pointed_to;
}
</code>
This code compiles under GCC without a single error or warning, even with
the -pedantic and -Wall flags.

The problem lies when I run the following test cod:

<code>
int main(int argc, char *argv[])
{
Foo<int> a;
Foo<int>::Bar b;
* * * *
b.point_to( a);
return EXIT_SUCCESS;
}
</code>
That code also compiles withou a single problem. Yet, when I run the test
application, it crashes and the following message pops up:

<shell>
*** glibc detected *** free(): invalid pointer: 0xbfb01a10 ***
/bin/sh: line 1: *9703 Aborted * * * * * * * *./mytree
Press Enter to continue!
</shell>
I can't see where the problem lies. Not only does the code compile but I
also the class points it's member pointer to an already declared variable.
I can't see what's going wrong in here.

So, can anyone shed some light on this problem?
Thanks in advance
Rui Maciel
--
Running Kubuntu 5.10 with KDE 3.5.1 and proud of it.
jabber:ru********@jabber.org

[Victor Bazarov]

Rui Maciel wrote:

I've been fooling around with a test class and meanwhile I stumbled on a
pointer problem.

I have two classes, one being nested in the other. I've wrote a method in
the nested class that would set a nested class's member pointer as a
pointer to an instance of the other class. Here is the code:

<code>
template <class tData>
class Foo
{
// snip
public:
class Bar
{
protected:
Foo<tData> *m_cursor;
public:
//snip
void point_to(Foo<tData> &);
};
Is this really all there is?
};

// snip

template <class tData>
void Foo<tData>::Bar::point_to(Foo<tData> &pointed_to)
{
this->m_cursor = &pointed_to;
}
</code>
This code compiles under GCC without a single error or warning, even with
the -pedantic and -Wall flags.
There is nothing to compile. It's a template definition. Unless you
actually try to instantiate it, all the compiler does is checking the
syntax.

The problem lies when I run the following test cod:

<code>
int main(int argc, char *argv[])
What's the point of having 'argc' and 'argv' if you're not using them?
{
Foo<int> a;
'Foo' is undefined.
Foo<int>::Bar b;
'Bar' is undefined.

b.point_to( a);
return EXIT_SUCCESS;
'EXIT_SUCCESS' is undefined.
}
This does not seem to be a complete program. Perhaps if you posted the
right code, we could actually be on the same page...
</code>
That code also compiles withou a single problem. Yet, when I run the test
application, it crashes and the following message pops up:

<shell>
*** glibc detected *** free(): invalid pointer: 0xbfb01a10 ***
/bin/sh: line 1: 9703 Aborted ./mytree
Press Enter to continue!
</shell>
'free'? I didn't see any call to 'free' in your code. Neither did I see
any call to 'new' or anything like that. You're not showing the whole
code.
I can't see where the problem lies.
Neither can I. Most likely because you didn't post the code that actually
has the problem.
Not only does the code compile but I
also the class points it's member pointer to an already declared variable.
I can't see what's going wrong in here.

So, can anyone shed some light on this problem?

Post the _complete_, _compilable_, minimal code that demonstrates the
problem as you describe it. Then we can talk.

V
--
Please remove capital As from my address when replying by mail

[rui.maciel]

I've followed your advice and I started chopping up my source code to
post a working example. While doing it, I've stumbled into what I
believe was the cause of the problem: a forgotten delete statement in
the Bar class' destructor...

Better look more closely next time
Once again thanks for the help, Victor
Rui Maciel