FYI: Here's the debug output from idl just prior to core dumping:
IIOPProxy::add_invoke: rec=0xd0e8328, id=0xf056878, msgid=38143) MICO::GIOPConn::output (CORBA::Buffer *b) b: 0xcdf8b50 Out Data 47 49 4f 50 01 00 01 00 44 00 00 00 00 00 00 00 GIOP....D....... ff 94 00 00 01 00 00 00 17 00 00 00 2f 31 36 30 ��........../160 37 35 2f 31 33 31 39 30 33 31 38 39 36 2f 30 2f 75/1319031896/0/ 5f 32 39 00 0e 00 00 00 5f 73 65 74 5f 63 6f 6e _29....._set_con 74 65 78 74 73 00 00 00 00 00 00 00 00 00 00 00 texts........... MICO::GIOPConn::input_ready () conn: 0x99c2af8 ev: GIOPConnCallback::InputReady t_mod: 1 pool: conn: _activerefs: 3 In Data 47 49 4f 50 01 00 01 01 0c 00 00 00 00 00 00 00 GIOP............ ff 94 00 00 00 00 00 00 ��...... IIOP: incoming data from inet:192.168.1.102:9005 GIOP: incoming Reply from inet:192.168.1.102:9005 for msgid 38143 status is 0 ORB::get_invoke (MsgId=38143) IIOPProxy::pull_invoke: id=0xf056878, rec = 0xd0e8328 IIOPProxy::handle_invoke_reply: rec=0xd0e8328) IIOPProxy::del_invoke: rec = 0xd0e8328 MICO::IIOPProxy::exec_invoke_reply (obj=0, *req=0xbfe6ce28, *conn=0x99c2af8) GIOPConn::deref: 0x99c2af8, refcnt: 1, activerefs: 3 ORB::wait for 0xf056878 ORB::del_invoke (MsgId=38143) ORB::add_invoke (MsgId=38144) void MICOPOA::POACurrent_impl::set( poa=0x9982210, POAObjectReference=0xf05ab78, Servant=0x9982814 ) void MICOPOA::POACurrent_impl::unset() ORB::wait for 0xf056878 ORB::del_invoke (MsgId=38144) ORB::add_invoke (MsgId=38145) void MICOPOA::POACurrent_impl::set( poa=0x9982210, POAObjectReference=0xf03ba18, Servant=0x9982814 ) void MICOPOA::POACurrent_impl::unset() ORB::wait for 0xf056878 ORB::del_invoke (MsgId=38145) [16137|3078887120] uncaught MICO exception: IDL:omg.org/CORBA/BAD_OPERATION:1.0 (0, not-completed) Exception stack trace: /home/mdopt/mdopt/icf/corba/Linux-2/lib/libmico2.3.13.so(CORBA::Exception::Exception()+0x7e) [0x1224e2e] /home/mdopt/mdopt/icf/corba/Linux-2/lib/libmico2.3.13.so(CORBA::SystemException::SystemException(CORBA::SystemException const&)+0x28) [0x1226258] /home/mdopt/mdopt/icf/corba/Linux-2/lib/libmico2.3.13.so(CORBA::BAD_OPERATION::BAD_OPERATION(CORBA::BAD_OPERATION const&)+0x29) [0x131dbf9] /home/mdopt/mdopt/icf/corba/Linux-2/lib/libmico2.3.13.so(CORBA::BAD_OPERATION::_throwit() const+0x34) [0x131dc44] /home/mdopt/mdopt/icf/corba/Linux-2/lib/libmico2.3.13.so(+0x3b26ac) [0x134d6ac] /home/mdopt/mdopt/icf/corba/Linux-2/lib/libmico2.3.13.so(CORBA::Contained_stub::id()+0x78) [0x1351488] idl(IRCopy::is_included_def(CORBA::Contained*)+0x3c) [0x81ab7dc] idl(IRCopy::copy(CORBA::Container*, bool)+0x4b) [0x81b0d8b] idl(IRCopy::copy(CORBA::Container*, bool)+0x20d) [0x81b0f4d] idl(IRCopy::copy(CORBA::Container*, bool)+0x20d) [0x81b0f4d] idl(IRCopy::copy(CORBA::Container*, bool)+0x20d) [0x81b0f4d] idl(IRCopier(DB&, IDLParam&, CORBA::Repository*, CORBA::Container*)+0x3f) [0x81b11bf] idl(main+0x653) [0x8089b23] /lib/libc.so.6(__libc_start_main+0xe6) [0x9a3e36] idl() [0x80893d1]Abort (core dumped) On 10/19/2011 08:31 AM, Rob Ratcliff wrote: > Here's another update: I recompiled mico with threads disabled and noticed > that the single-threaded idl program crashed when > communicating with the multi-threaded ird, but not with the single-threaded > ird. So it appears that the crash is related to enabling > threads in the ird. > > On 10/18/2011 10:04 AM, Rob Ratcliff wrote: >> Hi, >> >> I compiled MICO with multi-thread enabled (and CSIV2). When I attempt to >> load the CORBA.idl into the interface repository using >> idl --feed-ir CORBA.idl >> >> I get the following stack trace from the core dump: >> >> (gdb) where >> #0 0x0013a416 in __kernel_vsyscall () >> #1 0x003052f1 in raise () from /lib/libc.so.6 >> #2 0x00306d5e in abort () from /lib/libc.so.6 >> #3 0x007f6b1b in ?? () from /usr/lib/libstdc++.so.6 >> #4 0x007f6b53 in std::terminate() () from /usr/lib/libstdc++.so.6 >> #5 0x007f6cd2 in __cxa_throw () from /usr/lib/libstdc++.so.6 >> #6 0x00d0dc60 in CORBA::BAD_OPERATION::_throwit (this=0x9239be8) at >> ../include/mico/sysexc.h:36 >> #7 0x00d3d6ac in mico_throw (r=0xbffee144) at ../include/mico/throw.h:88 >> #8 mico_sii_throw (r=0xbffee144) at ../include/mico/throw.h:130 >> #9 0x00d41488 in CORBA::Contained_stub::id (this=0x9250a80) at ir.cc:331 >> #10 0x081ab7dc in IRCopy::is_included_def (this=0xbffee3b0, src=0x9250a80) >> at ir-copy.cc:123 >> #11 0x081b0d8b in IRCopy::copy (this=0xbffee3b0, src=0x92bd658, >> feed_included_defs=true) at ir-copy.cc:153 >> #12 0x081b0f4d in IRCopy::copy (this=0xbffee3b0, src=0x925cfe0, >> feed_included_defs=true) at ir-copy.cc:181 >> #13 0x081b0f4d in IRCopy::copy (this=0xbffee3b0, src=0x925bff0, >> feed_included_defs=true) at ir-copy.cc:181 >> #14 0x081b0f4d in IRCopy::copy (this=0xbffee3b0, src=0x9213910, >> feed_included_defs=true) at ir-copy.cc:181 >> #15 0x081b11bf in IRCopier (db=..., params=..., repo=0x922a860, >> cont=0x9213910) at ir-copy.cc:1628 >> #16 0x08089b23 in main (argc=17159044, argv=0x105d40c) at main.cc:357 >> >> I've attached my MakeVars for reference. >> >> I'm just beginning to troubleshoot it, but if anybody has some idea why this >> would be happening, please let me know. My gut feel is >> that there is some non-thread-safe code in the interface repository server >> since this works fine in the single-threaded version. >> I've also noticed that smaller IDL files load fine. >> >> Thanks, >> >> Rob >> >> >> > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Mico-devel mailing list > Mico-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mico-devel > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Mico-devel mailing list Mico-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mico-devel
