Even though OperationDef is not a Container, a Container_stub is used. I wonder
if the "!strcmp" logic is incorrect when there is an
OperationDef?
ir.cc
...
CORBA::Container::_narrow( CORBA::Object_ptr _obj )
{
CORBA::Container_ptr _o;
if( !CORBA::is_nil( _obj ) ) {
void *_p;
if( (_p = _obj->_narrow_helper( "IDL:omg.org/CORBA/Container:1.0" )))
return _duplicate( (CORBA::Container_ptr) _p );
if (!strcmp (_obj->_repoid(), "IDL:omg.org/CORBA/Container:1.0") ||
_obj->_is_a_remote ("IDL:omg.org/CORBA/Container:1.0")) {
_o = new CORBA::Container_stub;
_o->CORBA::Object::operator=( *_obj );
return _o;
}
}
return _nil();
}
On 10/25/2011 10:25 PM, Rob Ratcliff wrote:
> 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
>
------------------------------------------------------------------------------
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
