[omniORB] Debugging marshaling errors

[Jason Stelzer]

I have a simple value type I'm trying to coax omniorb into mapping.

I've created a factory for it which derives from the generated _init
class and implements create_for_unmarshal and the default create()
factory method for this object.

I have an implementation class which derives from the generated OBV
class and CORBA::DefaultValueRefCountBase. This class also implements
a no args constructor and a simple destructor as well as a _copy_value
() method.

Now, when I receive an object back from the jboss server, omniorb
segfaults. I'm trying to figure out why. The problem is, I'm not sure
how to ensure that the idl lines up with the corba stubs generated by
jboss at deployment time. As it stands I've registered the factory,
but I'm unable to determine why exactly things are blowing up. Is
there some other option to trace data marshaling calls?



omniORB: (0) Delete output value indirection tracker
omniORB: (0) inputMessage: from giop:tcp:10.67.90.64:3528 982 bytes
omniORB: (0)
4749 4f50 0102 0001 0000 03ca 0000 0004 GIOP............
0000 0000 0000 0000 7fff ff02 0000 004e ...............N
524d 493a 636f 6d2e 686d 736f 6e6c 696e RMI:com.hmsonlin
652e 6c6d 732e 636f 6d6d 6f6e 2e41 6464 e.lms.common.Add
7265 7373 5265 7375 6c74 733a 3433 4438 ressResults:43D8
3046 3332 3846 3133 3946 4530 3a30 3030 0F328F139FE0:000
3030 3030 3030 3133 3234 3045 3200 0000 00000013240E2...
0000 0000 7fff ff00 0000 0024 0036 0034 ...........$.6.4
0039 0020 0053 0020 0048 0045 004e 0044 .9. .S. .H.E.N.D
0045 0052 0053 004f 004e 0020 0052 0044 .E.R.S.O.N. .R.D
0000 0000 7fff ff00 0000 000e 0038 0036 .............8.6
0036 0033 0032 0036 0034 0000 7fff ff00 .6.3.2.6.4......
0000 001e 0034 0032 0030 0039 0031 0032 .....4.2.0.9.1.2
0030 0035 0039 0030 0035 0032 0030 0031 .0.5.9.0.5.2.0.1
0036 0000 7fff ff00 0000 004c 0050 0048 .6.........L.P.H
0049 004c 0041 0044 0045 004c 0050 0048 .I.L.A.D.E.L.P.H
0049 0041 002c 0020 0050 0041 0020 004d .I.A.,. .P.A. .M
0045 0054 0052 004f 0050 004f 004c 0049 .E.T.R.O.P.O.L.I
0054 0041 004e 0020 0044 0049 0056 0049 .T.A.N. .D.I.V.I
0053 0049 004f 004e 7fff ff00 0000 000a .S.I.O.N........
0033 0037 0039 0036 0034 0000 7fff ff00 .3.7.9.6.4......
0000 0092 0050 0048 0049 004c 0041 0044 .....P.H.I.L.A.D
0045 004c 0050 0048 0049 0041 002d 0043 .E.L.P.H.I.A.-.C
0041 004d 0044 0045 004e 002d 0057 0049 .A.M.D.E.N.-.W.I
004c 004d 0049 004e 0047 0054 004f 004e .L.M.I.N.G.T.O.N
002c 0020 0050 0041 002d 004e 004a 002d .,. .P.A.-.N.J.-
0044 0045 002d 004d 0044 0020 004d 0045 .D.E.-.M.D. .M.E
0054 0052 004f 0050 004f 004c 0049 0054 .T.R.O.P.O.L.I.T
0041 004e 0020 0053 0054 0041 0054 0049 .A.N. .S.T.A.T.I
0053 0054 0049 0043 0041 004c 0020 0041 .S.T.I.C.A.L. .A
0052 0045 0041 0000 7fff ff00 0000 000a .R.E.A..........
0033 0037 0039 0038 0030 0000 0000 0000 .3.7.9.8.0......
0000 0000 7fff ff00 0000 0022 004d 004f ...........".M.O
004e 0054 0047 004f 004d 0045 0052 0059 .N.T.G.O.M.E.R.Y
0020 0043 004f 0055 004e 0054 0059 0000 . .C.O.U.N.T.Y..
7fff ff00 0000 0086 0050 0048 0049 004c .........P.H.I.L
0041 0044 0045 004c 0050 0048 0049 0041 .A.D.E.L.P.H.I.A
002d 0043 0041 004d 0044 0045 004e 002d .-.C.A.M.D.E.N.-
0056 0049 004e 0045 004c 0041 004e 0044 .V.I.N.E.L.A.N.D
002c 0020 0050 0041 002d 004e 004a 002d .,. .P.A.-.N.J.-
0044 0045 002d 004d 0044 0020 0043 004f .D.E.-.M.D. .C.O
004d 0042 0049 004e 0045 0044 0020 0053 .M.B.I.N.E.D. .S
0054 0041 0054 0049 0053 0054 0049 0043 .T.A.T.I.S.T.I.C
0041 004c 0020 0041 0052 0045 0041 0000 .A.L. .A.R.E.A..
7fff ff00 0000 0006 0034 0032 0038 0000 .........4.2.8..
0000 0000 7fff ff00 0000 0006 0036 0034 .............6.4
0039 0000 7fff ff00 0000 0006 0041 0053 .9...........A.S
0030 0000 7fff ff00 0000 0002 0059 0000 .0...........Y..
7fff ff00 0000 0012 0048 0045 004e 0044 .........H.E.N.D
0045 0052 0053 004f 004e 0000 0000 0000 .E.R.S.O.N......
0000 0000 0000 0000 7fff ff00 0000 0002 ................
0053 0000 0000 0000 7fff ff00 0000 001e .S..............
004b 0049 004e 0047 0020 004f 0046 0020 .K.I.N.G. .O.F.
0050 0052 0055 0053 0053 0049 0041 0000 .P.R.U.S.S.I.A..
7fff ff00 0000 0002 0048 0000 7fff ff00 .........H......
0000 0004 0052 0044 0000 0000 0000 0000 .....R.D........
7fff ff00 0000 000e 0038 0036 0036 0033 .........8.6.6.3
0032 0036 0035 0000 7fff ff00 0000 0006 .2.6.5..........
0053 0038 0030 0000 7fff ff00 0000 0004 .S.8.0..........
0050 0041 7fff ff00 0000 0008 0033 0035 .P.A.........3.5
0032 0039 7fff ff00 0000 000a 0031 0039 .2.9.........1.9
0034 0030 0036 .4.0.6
omniORB: (0) Create input value indirection tracker
omniORB: (0) Unmarshal value
'RMI:com.hmsonline.lms.common.AddressResults:
43D80F328F139FE0:00000000013240E2'.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208641312 (LWP 14047)]
0x090f93d0 in ?? ()
(gdb) bt
#0 0x090f93d0 in ?? ()
#1 0x0062679d in _omni_ValueFactoryManager::create_for_unmarshal
(id=0x90fec98 "RMI:com.hmsonline.lms.common.AddressResults:
43D80F328F139FE0:00000000013240E2",
hashval=1731962682) at valueFactory.cc:286
#2 0x00629167 in unmarshalHeaderAndBody (stream=@0x90fe904,
cstreamp=0x0, tracker=0x90fe998, pos=24, tag=2147483394,
targetId=0x8f005c "RMI:com.hmsonline.lms.common.AddressResults:
43D80F328F139FE0:00000000013240E2", targetHash=152036432, tc=0x0) at
valueType.cc:523
#3 0x00628bf5 in omniValueType::unmarshal (repoId=0x8f005c
"RMI:com.hmsonline.lms.common.AddressResults:
43D80F328F139FE0:00000000013240E2", hashval=1731962682, tc=0x0,
stream=@0x90fe904) at valueType.cc:408
#4 0x008e2ed6 in
com::hmsonline::lms::common::AddressResults::_NP_unmarshal
(_0s=@0x90fe904) at AddressResultsSK.cc:96
#5 0x008e2f62 in
com::hmsonline::lms::common::AddressResults_Helper::unmarshal
(_0s=@0x90fe904) at AddressResultsSK.cc:110
#6 0x008ee9d3 in
_0RL_cd_4F69AB407274632C_00000000::unmarshalReturnedValues
(this=0xbfe8cd20, _n=@0x90fe904) at LmsCorbaSK.cc:185
#7 0x004ac94f in omniRemoteIdentity::dispatch (this=0x90fe6d0,
call_desc=@0xbfe8cd20) at remoteIdentity.cc:183
#8 0x0048bd24 in omniObjRef::_invoke (this=0x90fe4b0,
call_desc=@0xbfe8cd20, do_assert=true) at ../../../../include/
omniORB4/omniObjRef.h:252
#9 0x008eeadd in
com::hmsonline::lms::corba::session::_objref_LmsCorba::getLmsData
(this=0x90fe4a0, arg0=0x90fe710, arg1=0x90fe4e0, arg2=0x0,
arg3=0x90fe520, arg4=0x90fe538)
at LmsCorbaSK.cc:209
#10 0x008eadec in Lms::standardizeAddress (this=0x90f7840,
line1=0xbff46bee "649 S. Henderson Rd.", line2=0xbff46c03 "King of
prussia, pa 19406", line3=0x0,
line4=0xbff46c1d "SSH_AGENT_PID=4075", line5=0xbff46c30
"HOSTNAME=jstelzer-lin") at Lms.cpp:49
#11 0x008eaa25 in getAddressData (lms=0x90f7840, line1=0xbff46bee
"649 S. Henderson Rd.", line2=0xbff46c03 "King of prussia, pa 19406",
line3=0x0,
line4=0xbff46c1d "SSH_AGENT_PID=4075", line5=0xbff46c30
"HOSTNAME=jstelzer-lin") at Lms.cpp:11
#12 0x08048620 in main ()

--
J.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070730/9ee6511f/attachment.htm

[Duncan Grisby]

Post by Jason Stelzer
I have a simple value type I'm trying to coax omniorb into mapping.

[...]

Post by Jason Stelzer
Now, when I receive an object back from the jboss server, omniorb
segfaults. I'm trying to figure out why. The problem is, I'm not sure
how to ensure that the idl lines up with the corba stubs generated by
jboss at deployment time. As it stands I've registered the factory,
but I'm unable to determine why exactly things are blowing up. Is
there some other option to trace data marshaling calls?

You've posted a trace of the marshalled data. You can unpick the data
according to the GIOP spec to see if that tells you anything. It's a
painful and probably unnecessary exercise, though.

You should post the IDL and code you are using. Without that, it's
impossible to offer any advice. How does your code compare with the
simple valuetype example in src/examples/valuetype/simple?

The place it's segfaulting is where it tries to call _add_ref on the
factory you have registered, which suggests that perhaps you have
released too many references on it, causing it to be prematurely
deleted.

Cheers,

Duncan.

[Jason Stelzer]

Post by Duncan Grisby
You've posted a trace of the marshalled data. You can unpick the data
according to the GIOP spec to see if that tells you anything. It's a
painful and probably unnecessary exercise, though.
You should post the IDL and code you are using. Without that, it's
impossible to offer any advice. How does your code compare with the
simple valuetype example in src/examples/valuetype/simple?
The place it's segfaulting is where it tries to call _add_ref on the
factory you have registered, which suggests that perhaps you have
released too many references on it, causing it to be prematurely
deleted.

As far as the returned data goes, on a high level it looks right. I
mean, I see the strings I'd expect to see given the address I've just
geocoded. Picking it further apart is probably not going to be
productive for me.


Thank you for the reply and sorry not all relevant information was
present. Should you care to look, all code is here:
http://neverlight.com/~cynic/libLms/


It's essentially me feeling my way through a prototype so its a bit
of a mess right now. However, it is representative of the codebase
which lead to the error in the last post.
The initial milestone release used only primitives and it did work.
However using only strings and splitting complex data structures
apart was... error prone. So, I'm simply trying to figure out how to
expose a pojo and use it as a struct to hold the results of geocoding
an address.

Lms.cpp is the 'main' program. It is what is compiled to a shared
library. Currently it fails when the call to getLmsData() fails as
shown by the marshaling error.

Since jboss uses reflection to deploy corba services through jacorb,
the idl in the idl directory was generated from class files and
'fixed up'. It is very likely that I need to alter them further I
suppose.

For reference I've been using http://docs.sun.com/source/817-0462-10/
dccpp.html
as a reference on what needs fixed up when you generate idl this way.


AddressResultsImpl.* is the implementing class(es) for the
corresponding stub code generated from the idl for the AddressResults
pojo. Is this simply a matter of me needing to adjust the idl a bit
and define the return types to the location manager differently?
Meaning, return AddressResultsImpl* instead of AddressResults* and
register the factory as such?


Thanks for any time you give this. Yes, I'm learning quite a bit at
once so I apologize in advance for things being messy. I'm trying to
bridge java/ejb->corba->C++->C->perl.


--
J.

[Duncan Grisby]

[...]

Post by Jason Stelzer

Post by Duncan Grisby
The place it's segfaulting is where it tries to call _add_ref on the
factory you have registered, which suggests that perhaps you have
released too many references on it, causing it to be prematurely
deleted.

Thank you for the reply and sorry not all relevant information was
http://neverlight.com/~cynic/libLms/

As I guessed, the problem is that you are releasing too many references
on your ValueFactory. This is the code:

CORBA::ValueFactoryBase_var vf = new com::hmsonline::lms::common::AddressResultsFactory();
CORBA::String_var repIdV = com::hmsonline::lms::common::AddressResults::_PD_repoId;
orb->register_value_factory(repIdV.in(),vf.in());
vf->_remove_ref();

The _var type automatically releases the reference to the factory when
the _var goes out of scope. Add that to the explicit _remove_ref, and
the factory object is deleted. That leads to the segfault when the ORB
later tries to use the factory. If you remove the call to _remove_ref,
that problem will go away.

Cheers,

Duncan.

[Jason Stelzer]

Post by Duncan Grisby
The _var type automatically releases the reference to the factory when
the _var goes out of scope. Add that to the explicit _remove_ref, and
the factory object is deleted. That leads to the segfault when the ORB
later tries to use the factory. If you remove the call to _remove_ref,
that problem will go away.

Thanks. I just misunderstood the example in Pure Corba. At this point
it looks as if the right callbacks are firing. The factory seems to
be doing the right thing, sort of.

I see

omniORB: (0) Unmarshal value
'RMI:com.hmsonline.lms.common.AddressResults:
43D80F328F139FE0:00000000013240E2'.
omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
omniORB: (0) Received UTF-16 string with no byte order mark.
omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
...

Howerver, when I try and access the data that should have been
marshaled it seems to be null. Further, when I look at the returned
pointer, I see
(gdb) print *output
$5 = {
<CORBA::ValueBase> = {
_vptr.ValueBase = 0x59c744,
static _PD_repoId = 0x4e7524 "IDL:omg.org/CORBA/ValueBase:1.0",
static _PR_magic = 1447119938,
_pd_magic = 1447119938
},
members of com::hmsonline::lms::common::AddressResults:
_vptr.AddressResults = 0x59c5a8,
static _PD_repoId = 0x5970d4
"RMI:com.hmsonline.lms.common.AddressResults:
43D80F328F139FE0:00000000013240E2"
}


My understanding of the way this is supposed to work is this:
1. remote method is called which returns a pass by value object
2. The local orb reads the rep ID and looks up the factory in its
factory table.
3. The orb calls create_for_unmarshal on the factory (which returns
the Impl class).
4. The orb is then responsible for initializing the new object
returned by the factory.
5. The returned object is the unmarshaled value object.

I would have expected to see quite a bit more data in the returned
structure.

--
J.

[Jason Stelzer]

Post by Jason Stelzer
Thanks. I just misunderstood the example in Pure Corba. At this
point it looks as if the right callbacks are firing. The factory
seems to be doing the right thing, sort of.
I see
omniORB: (0) Unmarshal value
43D80F328F139FE0:00000000013240E2'.
omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
omniORB: (0) Received UTF-16 string with no byte order mark.
omniORB: (0) Unmarshal value 'IDL:omg.org/CORBA/WStringValue:1.0'.
...
Howerver, when I try and access the data that should have been
marshaled it seems to be null. Further, when I look at the returned
pointer, I see
(gdb) print *output
$5 = {
<CORBA::ValueBase> = {
_vptr.ValueBase = 0x59c744,
static _PD_repoId = 0x4e7524 "IDL:omg.org/CORBA/ValueBase:1.0",
static _PR_magic = 1447119938,
_pd_magic = 1447119938
},
_vptr.AddressResults = 0x59c5a8,
static _PD_repoId = 0x5970d4
43D80F328F139FE0:00000000013240E2"
}
1. remote method is called which returns a pass by value object
2. The local orb reads the rep ID and looks up the factory in its
factory table.
3. The orb calls create_for_unmarshal on the factory (which returns
the Impl class).
4. The orb is then responsible for initializing the new object
returned by the factory.
5. The returned object is the unmarshaled value object.
I would have expected to see quite a bit more data in the returned
structure.

Just a follow up on how I resolved this.

After exploring memory addresses and dumping objects, I'm reasonably
sure that my idl is simply subtly busted or overly complicated.

What I did find that worked quite well was to use a java object with
public member varialbles as a glorified struct for return values.
Yes, it breaks encapsulation, but it has something the object with
accessor methods lacked. Namely it operates correctly. So, I just
regenerated the idl from the class and access string data from
results.member directly.

Thanks for all the help :)

--
J.