idlparser segmentation fault

[Victor Fusco]

Hi,

I am receiving a segfault when trying to generate code for a valuetype.
I think it has something to do with the valuetype supporting an
interface that is an alias.

I have isolated the problem using the two idl files attached. You can
reproduce it running "idl -I. myidl2.idl".

I also attached a patch that tries to solve the problem, but I am not
sure about it's correctness. Can you please take a look?

The gdb backtrace shows this:

Program received signal SIGSEGV, Segmentation fault.
IDLParser::collectValueDcl (this=0x7fffffffceb0, con=0x73b810,
node=0x728740) at idlparser.cc:2247
2247 if (sif->def_kind() == CORBA::dk_Interface) {

(gdb) bt
#0 IDLParser::collectValueDcl (this=0x7fffffffceb0, con=0x73b810,
node=0x728740) at idlparser.cc:2247
#1 0x0000000000438b6b in IDLParser::scan (this=0x7fffffffceb0,
con=0x73b810, node=<optimized out>) at idlparser.cc:272
#2 0x0000000000439e03 in IDLParser::collectModule (this=0x7fffffffceb0,
con=0x737030, node=0x7288c0) at idlparser.cc:807
#3 0x0000000000438b6b in IDLParser::scan (this=0x7fffffffceb0,
con=0x737030, node=<optimized out>) at idlparser.cc:272
#4 0x0000000000439e03 in IDLParser::collectModule (this=0x7fffffffceb0,
con=0x7327a0, node=0x728a00) at idlparser.cc:807
#5 0x0000000000438b6b in IDLParser::scan (this=0x7fffffffceb0,
con=0x7327a0, node=<optimized out>) at idlparser.cc:272
#6 0x000000000043a0ea in IDLParser::collect (this=0x7fffffffceb0,
cont=0x7327a0, root=0x728cc0) at idlparser.cc:89
#7 0x000000000041c5bd in main (argc=3, argv=<optimized out>) at
main.cc:189


Thanks,

Victor Fusco



"The future is here. It's just not widely distributed yet."
William Gibson

[Victor Fusco]

Hi,

Post by Victor Fusco
I am receiving a segfault when trying to generate code for a
valuetype. I think it has something to do with the valuetype
supporting an interface that is an alias.

I hit another case of the valuetype alias problem, but this time I got
an error instead of a segmentation fault. It happens when a valuetype
extends a valuetype that is an alias.

I've attached the new testcase and a patch that fixes the problem.

Thanks,

Victor Fusco



"The future is here. It's just not widely distributed yet."
William Gibson

[Karel Gardas]

Hi Victor,

the same as your previous patch. This one also assumes something which
is not in spec. Please see following snipped from the "OMG IDL Syntax
and Semantics 3" -- definitions which applies to both your cases.
You see that in both cases, your value shall inherit from <value_name>
which is just <scoped_name> and that your value may support one or more
<interface_name> which is also <scoped_name>.

(11) <interface_name> ::= <scoped_name>
(12) <scoped_name> ::= <identifier>
| “::” <identifier>
| <scoped_name> “::” <identifier>
(13) <value> ::= ( <value_dcl> | <value_abs_dcl> |
<value_box_dcl> | <value_forward_dcl>)
(14) <value_forward_dcl> ::= [ “abstract” ] “valuetype” <identifier>
(15) <value_box_dcl> ::= “valuetype” <identifier> <type_spec>
(16) <value_abs_dcl> ::= “abstract” “valuetype” <identifier>
[ <value_inheritance_spec> ]
“{“ <export>* “}”
(17) <value_dcl> ::= <value_header> “{“ < value_element>* “}”
(18) <value_header> ::= [“custom” ] “valuetype” <identifier>
[ <value_inheritance_spec> ]
(19)<value_inheritance_spec> ::= [ “:” [ “truncatable” ] <value_name>
{ “,” <value_name> }* ]
[ “supports” <interface_name>
{ “,” <interface_name> }* ]
(20) <value_name> ::= <scoped_name>


So following this grammar, your myidl2.idl from previous email should be:

#include <myidl.idl>

module scope1 {
module scope3 {
valuetype MyValueType supports scope1::scope2::MyAbstractInterface {
public boolean value;
};
};
};

and valuetype_basevalue.idl attached to this email should be fixed in
the same way, i.e.

module scope1 {
module scope2 {
abstract interface MyAbstractInterface {
string getName();
};
valuetype MyValueType supports MyAbstractInterface {
public boolean value;
};
};

module scope3 {
valuetype MyExtendedValueType : scope1::scope2::MyValueType {
public boolean valid;
};
};
};

Anyway, I agree with you that IDL compiler should not segfault, but
rather emit nice and clear error message in case non-valid IDL. Patch
for this would be highly appreciated.

Thanks!
Karel

Post by Victor Fusco
Hi,

Post by Victor Fusco
I am receiving a segfault when trying to generate code for a
valuetype. I think it has something to do with the valuetype
supporting an interface that is an alias.

I hit another case of the valuetype alias problem, but this time I got
an error instead of a segmentation fault. It happens when a valuetype
extends a valuetype that is an alias.
I've attached the new testcase and a patch that fixes the problem.
Thanks,
Victor Fusco
"The future is here. It's just not widely distributed yet."
William Gibson
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Mico-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mico-devel

[Karel Gardas]

Hi Victor,

thanks a lot for your patch. It's correct and solving your issue, but
I'm afraid here you hit different bug in MICO than what you thought.
First of all, I'd like to let you know that following CORBA spec, at
least as I read it (strickly) is that the construct you are using in
myidl2.idl is not legal. Following IDL grammar you can use just
<interface_name> on this place, where <interface_name> is <scope_name>
-- but not any kind of alias. So as MICO was always focused on
correctness of CORBA implementation I'm not going to merge your attached
patch. What I would certainly consider for merging is a patch which will
fix the crash in your case and emit some clear error message complaining
about not valid IDL.

Thanks!
Karel

Post by Victor Fusco
Hi,
I am receiving a segfault when trying to generate code for a valuetype.
I think it has something to do with the valuetype supporting an
interface that is an alias.
I have isolated the problem using the two idl files attached. You can
reproduce it running "idl -I. myidl2.idl".
I also attached a patch that tries to solve the problem, but I am not
sure about it's correctness. Can you please take a look?
Program received signal SIGSEGV, Segmentation fault.
IDLParser::collectValueDcl (this=0x7fffffffceb0, con=0x73b810,
node=0x728740) at idlparser.cc:2247
2247 if (sif->def_kind() == CORBA::dk_Interface) {
(gdb) bt
#0 IDLParser::collectValueDcl (this=0x7fffffffceb0, con=0x73b810,
node=0x728740) at idlparser.cc:2247
#1 0x0000000000438b6b in IDLParser::scan (this=0x7fffffffceb0,
con=0x73b810, node=<optimized out>) at idlparser.cc:272
#2 0x0000000000439e03 in IDLParser::collectModule (this=0x7fffffffceb0,
con=0x737030, node=0x7288c0) at idlparser.cc:807
#3 0x0000000000438b6b in IDLParser::scan (this=0x7fffffffceb0,
con=0x737030, node=<optimized out>) at idlparser.cc:272
#4 0x0000000000439e03 in IDLParser::collectModule (this=0x7fffffffceb0,
con=0x7327a0, node=0x728a00) at idlparser.cc:807
#5 0x0000000000438b6b in IDLParser::scan (this=0x7fffffffceb0,
con=0x7327a0, node=<optimized out>) at idlparser.cc:272
#6 0x000000000043a0ea in IDLParser::collect (this=0x7fffffffceb0,
cont=0x7327a0, root=0x728cc0) at idlparser.cc:89
#7 0x000000000041c5bd in main (argc=3, argv=<optimized out>) at
main.cc:189
Thanks,
Victor Fusco
"The future is here. It's just not widely distributed yet."
William Gibson
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today.
http://p.sf.net/sfu/quest-dev2dev2
_______________________________________________
Mico-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mico-devel

[Victor Fusco]

Hi Karel,

First, thanks for answering my e-mail.

Post by Karel Gardas
the same as your previous patch. This one also assumes something
which is not in spec. Please see following snipped from the "OMG IDL
Syntax and Semantics 3" -- definitions which applies to both your
cases. You see that in both cases, your value shall inherit from
<value_name> which is just <scoped_name> and that your value may
support one or more <interface_name> which is also <scoped_name>.

You are right, the syntax rules reads as you say. My fault, I did not
check the syntax rules because the other orb that I am using does
support this. And because it seems like a normal way to write.

But while re-reading the specification, I got a doubt. On the section
"7.9.1.3 Value Inheritance Specification" it says:

"Each <value_name> in a <value_inheritance_spec> must be the name of a
previously defined value type or an alias to a previously defined value
type. Each <interface_name> in a <value_inheritance_spec> must be the
name of a previously defined interface or an alias to a previously
defined interface."

This is not the case here?

Thanks,

Victor Fusco



"The future is here. It's just not widely distributed yet."
William Gibson

[Victor Fusco]

Hi Karel,

First, thanks for answering my e-mail.

Post by Karel Gardas
the same as your previous patch. This one also assumes something
which is not in spec. Please see following snipped from the "OMG IDL
Syntax and Semantics 3" -- definitions which applies to both your
cases. You see that in both cases, your value shall inherit from
<value_name> which is just <scoped_name> and that your value may
support one or more <interface_name> which is also <scoped_name>.

You are right, the syntax rules reads as you say. My fault, I did not
check the syntax rules because the other orb that I am using does
support this. And because it seems like a normal way to write.

But while re-reading the specification, I got a doubt. On the section
"7.9.1.3 Value Inheritance Specification" it says:

"Each <value_name> in a <value_inheritance_spec> must be the name of a
previously defined value type or an alias to a previously defined value
type. Each <interface_name> in a <value_inheritance_spec> must be the
name of a previously defined interface or an alias to a previously
defined interface."

This is not the case here?

Thanks,

Victor Fusco



"The future is here. It's just not widely distributed yet."
William Gibson