I ran into a problem a while back where the python and C++
versions
of a
simobject I was working with weren't meshing with each other, and
M5 was
segfaulting out and crashing. I worked around the problem and
intended
to mention this to the list, but I haven't gotten around to it
until now.
Basically, the python version of the simobject had just one base,
I
believe, which wasn't very interesting. I think it may have
simply
been
SimObject. On the C++ side, however, the object inherited from
whatever
SimObject was appropriate, but then also another class that had
an
interface and some functionality I wanted to have in my
SimObject.
When
some infrastructure code tried to call init() on a new simobject
of
this
type, what actually happened was that a destructor was called for
one of
the base classes. M5 then burst into flames died.
I think the issue is that the python wrapper stuff builds up a
parallel
object hierarchy that mirrors the python stuff which is supposed
to
mirror the C++ stuff. When manipulating pointers to the classes
defined
in regular C++, swig thinks it's manipulating pointers to it's
parallel
version of C++. That works fine when only single inheritance is
used and
pointers are always equal to each other (I think they are, at
least),
but that breaks down when multiple inheritance is being used. I
think
what happened was that the vtable pointer for the SimObject
subobject
was not at the lowest addresses of the inheriting subclass. When
swig
used a reinterpret_cast on the pointer it got back from the
create
function (that's what I remember it did, at least) it ended up
referring
to whatever vtable pointer actually was there, which I suppose
was for
either the other class or for the subclass itself. This meant
that
when
it tried to call virtual function X which it expected to be init,
it
actually called function X in the wrong type of table which was
really a
destructor.
I spent a few minutes on a couple of occasions thinking about a
way to
handle all this that avoids this problem, but I didn't really
think of
anything. Things are generally they way they are because they
need
to be
for one reason or another, and it's not apparent how to change
things in
a way that's not extremely obnoxious or destructive that covers
this
case as well. In any case, I thought it was important to mention
I hit
this issue even if I didn't have a way to fix it. I don't have
the
code
around any more that was breaking, but I expect it wouldn't be
that
hard
to reproduce.
Gabe
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
