pymoose gets SIGSEGV at reset
Created by: subhacom
This happens only when a Compartment instance has been created. The SIGSEGV occurs at Compartment::initReinitFunc(const Conn& c, ProcInfo p) - when c.data()->innerInitReinitFunc is called. c.targetElement()->name() gives the correct name of the compartment, but it is not clear why the call to innerInitReinitFunc is causing segmentation fault although c.data() is non-null. innerInitReinitFunc is an empty function.
Reported by: subhacom
Activity
Created by: subhacom
Logged In: YES user_id=1735678 Originator: YES
Commenting out the internals of Compartment::initReinitFunc(const Conn& c, ProcInfo p) - which was doing nothing in effect removes the problem with reset. Now we get Illegal instruction signal (SIGILL) at call to Compartment::processFunc() gdb back trace -
#0 0xb7f4a42d in vtable for __cxxabiv1::__si_class_type_info () from /usr/lib/libstdc++.so.6 #1 (closed) 0x08134dc0 in Compartment::processFunc (c=@0x8287dc0, p=0x8286950) at Compartment.cpp:470 #2 (closed) 0x0819fe21 in send1<ProcInfoBase*> (eIn=0x8286f48, src=6, val=0x8286950) at ../basecode/send.h:47 #3 (closed) 0x0819822e in Tick::innerProcessFunc (this=0x8286f18, e=0x8286f48, info=0x8286950) at Tick.cpp:479 #4 (closed) 0x081982f7 in Tick::innerStart (this=0x8286f18, e=0x8286f48, info=0x8286950, maxTime=0.049999999999950001) at Tick.cpp:451 #5 (closed) 0x08198551 in Tick::start (c=@0x8287d80, info=0x8286950, maxTime=0.050000000000000003) at Tick.cpp:426 #6 (closed) 0x0819ff3a in send2<ProcInfoBase*, double> (eIn=0x8286968, src=6, val1=0x8286950, val2=0.050000000000000003) at ../basecode/send.h:83 #7 (closed) 0x081966f8 in ClockJob::startFuncLocal (this=0x8286928, e=0x8286968, runTime=0.050000000000000003) at ClockJob.cpp:274 #8 (closed) 0x0819679e in ClockJob::startFunc (c=@0xbfaa72f4, runtime=0.050000000000000003) at ClockJob.cpp:266 #9 (closed) 0x080767af in Ftype1<double>::set (this=0x82713e0, e=0x8286968, f=0x82748c0, v=0.050000000000000003) at ../../basecode/DerivedFtype.h:334 #10 (closed) 0x08094094 in set<double> (e=0x8286968, f=0x82748c0, v=0.050000000000000003) at ../basecode/setget.h:32 #11 (closed) 0x080941fe in set<double> (e=0x8286968, f=@0xbfaa73d4, v=0.050000000000000003) at ../basecode/setget.h:50 #12 (closed) 0x0810321d in Shell::step (c=@0x8286ee0, time=0.050000000000000003) at Shell.cpp:1507 #13 (closed) 0x08078b23 in send1<double> (eIn=0x8287230, src=22, val=0.050000000000000003) at ../../basecode/send.h:47 #14 (closed) 0x0806ae79 in PyMooseContext::step (this=0x82871d8, runtime=0.050000000000000003) at PyMooseContext.cpp:778 #15 (closed) 0x081c03bb in main () at TestPyMoose.cpp:35
Original comment by: subhacom
Created by: subhacom
Logged In: YES user_id=1735678 Originator: YES
Resolved in revision 385. This bug was due to duplicate class names in MOOSE and pymoose. Till last working version of pymoose, the compiler was magically able to differentiate between the two classes with the same name. But later it happened that static_cast<Compartment*> was actually casting a pymoose object pointer. Moving everything of pymoose inside a new namespace "pymoose" resolved this problem. gcc did not complain at compile time about duplicate class names but it was silently failing at runtime without giving any clue.
Original comment by: subhacom
