Marshall exception

[Gregory, Peter]

Hi

Recently my company have upgraded the version of mico that we are using from 2.3.11 to 2.3.13.



We have done this because 2.3.11 failed to build on a new version of red hat that we have moved to. (Red Hat Enterprise Linux Server release 6.3 (Santiago))



Other than making some changes to get our software to build against the new compiler we haven't changed our code.



However when we run we are getting a marshall exception in the client (thrown by the server). The client is a java client built against jacorb.



The server is reporting the following error



Error: cannot decode args in StaticServerRequest.



In the idl the function call is defined as unsigned long getLikeSize(in long keyNum, in any key);



Switching on the full debugging reports the following



MICO::GIOPConn::input_ready ()

conn: 0x8079450

ev: GIOPConnCallback::InputReady

t_mod: 0

pool:

conn:

_activerefs: 1

In Data 47 49 4f 50 01 00 00 00 00 00 02 90 00 00 00 00 GIOP...........

00 00 00 02 01 00 00 00 00 00 00 16 2f 31 38 33 ............/183

35 34 2f 31 33 35 31 30 39 32 34 30 30 2f 30 2f 54/1351092400/0/

5f 30 00 00 00 00 00 0a 67 65 74 42 79 53 69 7a _0......getBySiz

65 00 00 00 00 00 00 00 00 00 00 01 00 00 00 0f e...............

00 00 02 0c 00 00 00 00 00 00 00 20 49 44 4c 3a ........... IDL:

77 63 73 2f 4d 68 65 4c 6f 63 6e 55 73 61 67 65 wcs/MheLocnUsage

2f 52 65 63 6f 72 64 3a 31 2e 30 00 00 00 00 07 /Record:1.0.....

52 65 63 6f 72 64 00 00 00 00 00 06 00 00 00 04 Record..........

6b 65 79 00 00 00 00 12 00 00 00 00 00 00 00 04 key.............

73 65 71 00 00 00 00 03 00 00 00 05 6c 6f 63 6e seq.........locn

00 00 00 00 00 00 00 0f 00 00 00 60 00 00 00 00 ...........`....

00 00 00 15 49 44 4c 3a 77 63 73 2f 4c 6f 63 61 ....IDL:wcs/Loca

74 69 6f 6e 3a 31 2e 30 00 00 00 00 00 00 00 09 tion:1.0........

4c 6f 63 61 74 69 6f 6e 00 00 00 00 00 00 00 02 Location........

00 00 00 05 7a 6f 6e 65 00 00 00 00 00 00 00 12 ....zone........



00 00 00 00 00 00 00 09 69 64 65 6e 74 69 74 79 ........identity

00 00 00 00 00 00 00 12 00 00 00 00 00 00 00 0e ................

6c 6f 63 61 74 69 6f 6e 5f 74 79 70 65 00 00 00 location_type...

00 00 00 11 00 00 00 ae 00 00 00 00 00 00 00 27 .......®.......'

49 44 4c 3a 77 63 73 2f 4d 68 65 4c 6f 63 6e 55 IDL:wcs/MheLocnU

73 61 67 65 2f 4c 6f 63 6e 55 73 61 67 65 54 79 sage/LocnUsageTy

70 65 3a 31 2e 30 00 00 00 00 00 0e 4c 6f 63 6e pe:1.0......Locn

55 73 61 67 65 54 79 70 65 00 00 00 00 00 00 04 UsageType.......

00 00 00 16 4d 48 45 5f 4c 4f 43 4e 5f 55 53 41 ....MHE_LOCN_USA

47 45 5f 4e 4f 52 4d 41 4c 00 00 00 00 00 00 13 GE_NORMAL.......

4d 48 45 5f 4c 4f 43 4e 5f 55 53 41 47 45 5f 41 MHE_LOCN_USAGE_A

4c 4c 00 00 00 00 00 14 4d 48 45 5f 4c 4f 43 4e LL......MHE_LOCN

5f 55 53 41 47 45 5f 4e 4f 4e 45 00 00 00 00 16 _USAGE_NONE.....

4d 48 45 5f 4c 4f 43 4e 5f 55 53 41 47 45 5f 4c MHE_LOCN_USAGE_L

49 53 54 45 44 00 00 00 00 00 00 04 6d 68 65 00 ISTED.......mhe.

00 00 00 0f 00 00 00 50 00 00 00 00 00 00 00 10 .......P........



49 44 4c 3a 77 63 73 2f 4d 68 65 3a 31 2e 30 00 IDL:wcs/Mhe:1.0.

00 00 00 04 4d 68 65 00 00 00 00 02 00 00 00 05 ....Mhe.........

74 79 70 65 00 00 00 00 00 00 00 12 00 00 00 00 type............

00 00 00 09 69 64 65 6e 74 69 74 79 00 00 00 00 ....identity....

00 00 00 12 00 00 00 00 00 00 00 09 6d 68 65 5f ............mhe_

74 79 70 65 00 00 00 00 ff ff ff ff ff ff fe d4 type....ÿÿÿÿÿÿþÔ

00 00 00 0c 41 69 73 6c 65 53 63 72 65 65 6e 00 ....AisleScreen.

00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 01 ................

00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 ................

00 00 00 01 00 00 00 00 00 00 00 00 ............

: ActiveMsgQueue::put_msg: (0x8070e68) msg: 0x806d908

T *operator[](0): returns 0x807b558

void_array::remove (0)

PassiveOperation::put_msg():0x806d908

PassiveOperation::_run():0x806d908

void InputHandler::process( msg_type& msg )

conn: 0x8079450

ev: 0

b: 0x807a220

MICO::Server::input_callback (GIOPConn *conn, CORBA::Buffer *inp)

conn: 0x8079450

inp: 0x807a220

IIOP: incoming data from inet:128.0.0.145:39238

GIOP: incoming Request from inet:128.0.0.145:39238 with msgid 2

IIOPServer::add_invoke (id=6)

ORB::add_invoke (MsgId=6)

void MICOPOA::POACurrent_impl::set( poa=0x806cb00, POAObjectReference=0xb6602780, Servant=0x807936c )

Error: cannot decode args in StaticServerRequest

void MICOPOA::POACurrent_impl::unset()

ORB::del_invoke (MsgId=6)

GIOP: sending Reply to inet:128.0.0.145:39238 for msgid 2 status is 2

MICO::GIOPConn::output (CORBA::Buffer *b)

b: 0xb66007f0

Out Data 47 49 4f 50 01 00 00 01 00 00 00 38 00 00 00 00 GIOP.......8....

00 00 00 02 00 00 00 02 00 00 00 1e 49 44 4c 3a ............IDL:

6f 6d 67 2e 6f 72 67 2f 43 4f 52 42 41 2f 4d 41 omg.org/CORBA/MA

52 53 48 41 4c 3a 31 2e 30 00 00 00 00 00 00 00 RSHAL:1.0.......

00 00 00 01 ....

IIOPServer::del_invoke (id=6)

GIOPConn::deref: 0x8079450, refcnt: 1, activerefs: 0

: ActiveMsgQueue::check_msg: (0x8070e68) msg:

void_array::__fast_insert (0x807b558): return 0

: ActiveMsgQueue::check_msg: (0x8070e68) msg:







Any help would be most appreciated.



Peter







Peter Gregory
Senior Software Engineer



DD: [phone] | Mobile: [phone] | Fax: [phone] ***@logistex.com <mailto:***@logistex.com> | www.logistex.com <http://www.logistex.com/>



Logistex - a sure thing

Logistex Limited, 2700 Kettering Parkway, Kettering, Northamptonshire, NN15 6XR, United Kingdom Main Phone. [phone]



Registered Company Name: Logistex Limited | Registered Company Address: 2700 Kettering Parkway, Kettering, Northamptonshire, NN15 6XR, United Kingdom
Place of Registration: England | Registration Number: 334189

This e-mail and any attachments are confidential and may contain legally privileged information. If you are not the intended recipient please reply to the sender or telephone [phone] without using or disclosing the information contained herein.

Please be aware, all mail received by any @logistex.com address may be scanned for spam, virus, indecent images and spyware.

[Gregory, Peter]

Hi

I have tracked this issue down and can confirm it is another problem
caused by the upgrade to gcc version 4.4.



A different problem with the same cause was reported in the issue
"typecode assertion failed on gcc 4.4
<https://sourceforge.net/mailarchive/message.php?msg_id=29183633> ".



The issue is caused by a change in behaviour of the switch statement.

With this version of gcc the switch statement in CORBA::TypeCode::decode
(DataDecoder &dc, MapPosTC *_omap, ULong level),

now enters the default block instead of the "case TK_RECURSIVE:" block.
This is because the value of TK_RECURSIVE is outside the range of the
TCKind enum.



I made the relevant changes to typecode.cc and tckind.h, and the issue
is resolved.



Peter

[Karel Gardas]

Hi Peter,

this looks like an issue solved by this patch on MICO HEAD, isn't it?

Sun Jan 3 18:59:34 CET 2010 Karel Gardas <***@objectsecurity.com>
* fix "miscompilation" of typecode.cc by GNU C++ >= 4.4
This patch fixes typecode.cc to not use TK_RECURSIVE definition since
this makes GNU C++ >= 4.4 miscompiling several of typecode.cc's switch
statements where it simply omits case blocks where TK_RECURSIVE is
used, since TK_RECURSIVE provides value which is not defined in the
TCKind enum type. Whole behaviour is completed by emitted warnings:
typecode.cc:<line>: warning: case label value is less than minimum
value for type
Unfortunatelly GCC community members claim the compiler is right here
so I enhanced tckind.h by a provided bootstrap patch to include
tk_recursive value inside the TCKind enum definition which makes GNU
C++ happy and resulting MICO working again. For more information about
this issue see GCC PR#42576
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42576)


Thanks!
Karel

Post by Gregory, Peter
Hi
I have tracked this issue down and can confirm it is another problem
caused by the upgrade to gcc version 4.4.
A different problem with the same cause was reported in the issue
"typecode assertion failed on gcc 4.4
<https://sourceforge.net/mailarchive/message.php?msg_id=29183633> ".
The issue is caused by a change in behaviour of the switch statement.
With this version of gcc the switch statement in CORBA::TypeCode::decode
(DataDecoder&dc, MapPosTC *_omap, ULong level),
now enters the default block instead of the "case TK_RECURSIVE:" block.
This is because the value of TK_RECURSIVE is outside the range of the
TCKind enum.
I made the relevant changes to typecode.cc and tckind.h, and the issue
is resolved.
Peter
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Mico-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mico-devel

[Gregory, Peter]

Hi Karel,
Yes, you are right the issue is fixed by that patch.

Interesting comments from the GCC community members.
Whilst I agree with validation of the case values against the enum, I
think this really should be an error not a warning, since it results in
very different behaviour when you upgrade to that version of GCC.

Do you know of any plans to release a new version of MICO to include all
fixes currently in the MICO HEAD.

Peter

[Mark Glasberg]

Please unsubscribe me from the list.

Mark Glasberg

Post by Gregory, Peter
Hi Karel,
Yes, you are right the issue is fixed by that patch.
Interesting comments from the GCC community members.
Whilst I agree with validation of the case values against the enum, I
think this really should be an error not a warning, since it results in
very different behaviour when you upgrade to that version of GCC.
Do you know of any plans to release a new version of MICO to include all
fixes currently in the MICO HEAD.
Peter
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Mico-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mico-devel