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
