Here's more info on the problem:
When I defined the method in the IDL as:
JobIds getFailedJobIds();
with JobIds defined in an included file as:
typedef JobIds sequence<string>;
The definition for this method when evaluated here appears to be a "Container"
with a repository ID of
"IDL:omg.org/CORBA/OperationDef:1.00"
class IRCopy {
...
bool IRCopy::copy (CORBA::Container_ptr src, bool feed_included_defs) {
....
dummy2 = CORBA::Container::_narrow (contents[i]);
if (!CORBA::is_nil (dummy2)) {
if (!copy (dummy2, _feed_included_defs)) {
return false;
}
}
...
which leads to the exception of:
uncaught MICO exception: IDL:omg.org/CORBA/BAD_OPERATION:1.0 (0, not-completed)
when an attempt is made to call id() on the dummy2 reference.
If "JobIds" is replaced with sequence<string>, the "OperationDef" repository ID
never appears and there is no error in loading the IDL.
I get the same failure when loading CORBA.idl where when this method is
evaluated:
IDL:omg.org/CORBA/Container/create_local_interface:1.0
it gets narrowed to a container and has an repository ID of:
IDL:omg.org/CORBA/OperationDef:1.00
Looks like perhaps the "idl" program or the ird is getting confused.
Here's the full method with the print statements in it:
bool
IRCopy::copy (CORBA::Container_ptr src,
bool feed_included_defs)
{
_feed_included_defs = feed_included_defs;
CORBA::Contained_var cs = CORBA::Contained::_narrow (src);
cout << " ident = " << src->_repoid() << src->_get_component() << "\n";
if (!CORBA::is_nil (cs) &&
(!is_included_def (cs) || _feed_included_defs ||
cs->def_kind() == CORBA::dk_Module)) {
CORBA::Contained_var tc = copy_Contained (cs);
if (CORBA::is_nil (tc)) {
return false;
}
}
CORBA::ContainedSeq_var contents = src->contents (CORBA::dk_all, 1);
CORBA::Contained_var dummy1;
CORBA::Container_var dummy2;
for (CORBA::ULong i=0; i<contents->length(); i++) {
CORBA::String_var absname = contents[i]->absolute_name ();
cout << " varname = " << absname << "\n";
CORBA::String_var failure = "::MDOPT::JobManager::getFailedJobIds";
if(absname == failure) {
cout << "found it\n"; // used to set my breakpoint
}
if (_db.is_implicit (absname)) {
continue;
}
if (!is_included_def (contents[i]) || _feed_included_defs ||
contents[i]->def_kind() == CORBA::dk_Module) {
dummy1 = copy_Contained (contents[i]);
if (CORBA::is_nil (dummy1)) {
return false;
}
}
dummy2 = CORBA::Container::_narrow (contents[i]);
if (!CORBA::is_nil (dummy2)) {
if (!copy (dummy2, _feed_included_defs)) {
return false;
}
}
}
return true;
}
On 10/23/2011 11:35 PM, Rob Ratcliff wrote:
> 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
>
------------------------------------------------------------------------------
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
