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
