[Ace-users] Re: [tao-users] CORBA IOR seems to be malformed/incorrect

Johnny Willemsen jwillemsen at remedy.nl
Tue Sep 25 02:03:50 CDT 2007


Hi,

When I use 1.6.1 I get the output below. It seems you are using an
Orbix-style POOP which is maybe not fully supported. Does have IONA has a
IOR decoding tool, it would be interesting to see how the IOR looks like
there.

Regards,

Johnny Willemsen
Remedy IT
Postbus 101
2650 AC  Berkel en Rodenrijs
The Netherlands
www.theaceorb.nl / www.remedy.nl  

*** Integrated compile and test statistics see
http://scoreboard.theaceorb.nl ***
*** Commercial service and support for ACE/TAO/CIAO             ***
*** See http://www.theaceorb.nl/en/support.html                 *** 

reading the file t.txt

here is the IOR
IOR:

decoding an IOR:
The Byte Order: Big Endian
cannot read type id

here is the IOR
000000000000000c4c524d5f53657276616e740000000005000000000000006400010200000

decoding an POOP IOR

Abnormal program termination

"Somindra  Bhattacharya" <somindrab at gmail.com> wrote in message
news:<1190702667.146575.178640 at 50g2000hsm.googlegroups.com>...
>     TAO VERSION: 1.5
>     ACE VERSION: 5.5
> 
>     HOST MACHINE and OPERATING SYSTEM:
>     SunOS sun1 5.10 Generic_125100-10 sun4u sparc SUNW,Sun-Fire-V215
> 
>     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
>     COMPILER NAME AND VERSION (AND PATCHLEVEL):
>     g++:
>     bash-3.00$ /usr/sfw/bin/g++ -v
>     Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/
> specs
>     Configured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/
> gcc-3.4.3/
> 	configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
> --with-
>     ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --
> enable-shared
>     Thread model: posix
>     gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
> 
>     THE $ACE_ROOT/ace/config.h FILE:
>     (Should I copy the contents of the file here?)
> 
>     THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE:
>     platform_sunos5_g++.GNU
> 
>     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/
> default.features
>     (used by MPC when you generate your own makefiles):
> 
>     There is no such file in my build area.
> 
>     AREA/CLASS/EXAMPLE AFFECTED:
> 
>     DOES THE PROBLEM AFFECT:
>         COMPILATION?
>         No.
> 
>         LINKING?
>         No.
> 
>         EXECUTION?
> 	  Yes.
> 
>         OTHER (please specify)?
> 
>     SYNOPSIS:
>     CORBA IOR seems to be malformed/incorrect.
> 
>     DESCRIPTION:
>     I observed that one of our processes threw an error message:
> 
>     "TAO (9631|9) ERROR: Could not create all profiles while
> extracting object
>     TAO (9631|9) ERROR: reference from the CDR stream."
> 
>     The problem seems to be the IOR:
> 
> IOR:
>
000000000000000c4c524d5f53657276616e740000000005000000000000006400010200000
>
0000573756e310000b2ea0000001b14010f0052535446f7999c000216ee00000000000000010
000
>
0001000000000200000000000000080000000054414f00000000010000001800000000000100
010
>
00000010501000100010109000000000000000000000068000102000000000773756e2d63730
0ea
>
B2ea001b0000001b14010f0052535446f7999c000216ee000000000000000100000001020000
000
>
200000000000000080000000054414f000000000100000018000000000001000100000001050
100
>
0100010109000000000000000000000070000102000000001073756e2d63736c6f63616c2d76
697
>
000b2ea0f000000001b14010f0052535446f7999c000216ee000000000000000100000001000
000
>
000200000000000000080000000054414f000000000100000018000000000001000100000001
050
>
100010001010900000000000000000000006c000102000000000e73756e2d63732d73746e646
279
>
00b2ea0000001b14010f0052535446f7999c000216ee00000000000000010000000100000000
020
>
0000000000000080000000054414f00000000010000001800000000000100010000000105010
001
> 00010109000000000000000000000070000102000000000f73756e2d63736d676d742d7669
> 
> I tried using catior, but that produces a seemingly endless stream as
> output:
> 
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36
>      36 36 36 36 36 36 36 36 36 ^C
> 
> Please note that the test machine is a multi-homed machine with 4
> physical and 3 virtual
> interfaces (not including the local loopback).
> 
> What could have caused this? Any pointers?
> 
>     REPEAT BY:
> I have seen this happen a couple of times but is not reproducible at
> will.
> I do not know what caused this.
> 
>     SAMPLE FIX/WORKAROUND:
> I restarted the processes with the faulty IORs and it seemed to go
> away for now.
> 



More information about the Ace-users mailing list