Karel,
I haven't found the root cause of the problem yet. I'm running both the "idl
--feed-ir" command and the "ird" in multi-threaded
mode. I've noticed that I can make a slight change to a method signature such
as:
typedef sequence<string> Items; (defined in an include file)
...
interface Test {
...
Items getItems();
...
}
vs.
...
interface Test {
...
sequence<string> getItems();
...
}
The second will work and the first will not. I haven't been able to distill it
to a small test case, since deleting the
"non-offensive" IDL from the files before loading it will fix the problem with
the formerly "offensive" IDL.
But, thankfully, for a given IDL file, the "Bad Operation" call will always
happen at the same place in the IDL. For one case I'm
debugging, it happens during the second pass of IRCopy::copy command during the
"is_included_def(cs)" method shown here:
http://www.futuretek.com/mico/mico-stack-trace.png
This method dies when the id is attempted to be retrieved out of the remote src
object:
bool IRCopy::is_included_def (CORBA::Contained_ptr src)
{
string toplev = _db.get_toplevel_fname();
if (toplev.length() == 0) {
return false;
}
if (CORBA::is_nil (src)) {
return false;
}
CORBA::String_var id = src->id (); // dies here
string strid = id.in();
...
}
It appears to be a tricky problem, so any suggestions are appreciated!
Rob
On 10/20/2011 06:04 AM, Karel Gardas wrote:
>
> Hi Rob,
>
> indeed, this would point to some race-condition in ird itself. However even
> part or not majority of interface repository (at least
> this contained in libmicoir) should be thread-safe as this is also used in
> ObjectWall[1] and its generally thread-safe and tested
> a lot under hight load in multi-threading setup on multi-cpu servers. So what
> you perhaps see is relict of single-threaded MICO
> which should be fixed. If you do have already a patch for this or some
> attempt on it, please send it to here for review.
>
> Thanks!
> Karel
>
> [1]: http://www.objectsecurity.com/en-products-objectwall.html
>
> On 10/19/11 03:31 PM, 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
>>
>
>
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Mico-devel mailing list
Mico-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mico-devel
