Yea, double inheritance from SimObjects seems like an obviously bad idea to me.
I think part of the problem is that we don't always expose the entire C++ hierarchy to swig just for simplicity, and if some of those "hidden" classes have multiple base classes then swig could get confused. If this really is the problem, then exposing more of the C++ to swig should in theory fix it. I just noticed recently that I've been getting these warnings: build/ALPHA_SE/sim/eventq.hh:64: Warning(401): Base class 'Serializable' ignored - unknown module name for base. Either import the appropriate module interface file or specify the name of the module in the %import directive. build/ALPHA_SE/sim/eventq.hh:64: Warning(401): Base class 'FastAlloc' ignored - unknown module name for base. Either import the appropriate module interface file or specify the name of the module in the %import directive. build/ALPHA_SE/sim/eventq.hh:365: Warning(401): Base class 'Serializable' ignored - unknown module name for base. Either import the appropriate module interface file or specify the name of the module in the %import directive. I don't know if that's related or not. Nate has the most experience with swig, so I'd wait and see what he knows about this before spending a lot of time on it. Steve On Mon, Feb 28, 2011 at 12:51 PM, Ali Saidi <sa...@umich.edu> wrote: > > One was a SimObject and one was a random other class. I'm 99.9% certain to > SimObjects will behave very badly. > > Ali > > > On Mon, 28 Feb 2011 12:44:03 -0800, Gabe Black <gbl...@eecs.umich.edu> > wrote: > >> Were the two base classes both SimObjects and present in python? That >> might help things work. Only one was a SimObject in my case. Having two >> SimObjects seems relatively dangerous too since they might not be >> handled in the same order. Even if they are, are they guaranteed to be >> compatible? I'm not sure. >> >> Gabe >> >> On 02/28/11 12:30, Ali Saidi wrote: >> >>> >>> 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 >>> >> >> _______________________________________________ >> 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
