I had this happen with multiple inheritance in the classes that support
being a VncMouse or VncKeyboard. It drove me nuts trying to figure out
what was going on but rebuilding from a clean copy solved the problem,
so I think there is some weird behavior going on. I couldn't figure out
it because it seemed like the code was all being recompiled.
Ali
On Mon, 28 Feb 2011 11:55:56 -0800, Gabe Black <gbl...@eecs.umich.edu>
wrote:
Yes, it's possible. I've run into those problems before as well, and
I
fought with this bug for long enough that I think I would have tried
building from scratch, but I don't remember for sure. Assuming I
don't
set it aside and forgot about it after sending this email, I'll see
if I
can get it the problem to happen again.
Gabe
On 02/28/11 06:22, Ali Saidi wrote:
I think that this actually works ok, but perhaps you changed the
hierarchy in python while you were doing this? I've run into a
similar problem with scons not rebuilding the params structs after
some changes which led to very odd behavior. Is it possible that this
is the cause?
Ali
Sent from my ARM powered device
On Feb 28, 2011, at 5:48 AM, Gabe Black <gbl...@eecs.umich.edu>
wrote:
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
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
