Open GoogleCodeExporter opened 8 years ago
The real kicker is that this works great on a PC. But when I run on an ARM
processor
it fails. However, the other functions return values correctly. Just not
this one
in particular.
Original comment by ian.harr...@gmail.com
on 23 Apr 2009 at 9:38
If I understand correctly, you have a server implementation function returning
9999
as a long, and the client instead receives 0?
That's rather odd, especially if the other functions returning longs, don't
exhibit
the same behavior. If you return 9999 from the other functions, do you get 9999
on
the client?
Original comment by jarl.lin...@gmail.com
on 26 Apr 2009 at 8:43
Its very odd, I originally had it returning a Boolean indicating success.
Always
received a "false". Then I tried long and strings. Same results of it not
returning what I send it back from the server.
Its just very odd because it works fine on the PC. And all the other IDL's
work (to
the best of my knowledge) and return their values back. Also occassionally I
get the
following failure:
UFE: /home/iharrold/Libraries/tar/RCF-1.0/include/RCF/util/Assert.hpp:27:
util::VarArgAssert::VarArgAssert(): Assertion `0' failed.
I have tried to change the compiler flags from -O3 to -O0 to see if perhaps the
optimization was having an effect. But nothing.
Any ideas where I can debug this from?
Original comment by ian.harr...@gmail.com
on 27 Apr 2009 at 6:42
Here is something else that is odd. I changed the return type to
"std::string" and
had it return either the string, "true" or "false". If I passed in an invalid
string
(for the time zone that I am) setting which causes it to return "false", I
receive
"false" in the client. However, if I return the string "true" the client
receives a
NULL string... "".
Example of successful response:
ISSUFE::sendTimeZone() - Calling MA to set location with -0700
cUFEImpl::setLocation() called in_str = -0700
cUFEImpl::setLocation2() called in_str = -0700
cTimeZoneObject()::setlocation()called inloc = -0700
cTimeZoneObject()::setlocation() - Destination location not found
cUFEImpl::setLocation2() status flag = 0
MAUFEImpl::setLocation() - returning flag = 0
MAUFEImpl::setLocation() - returning false
ISSUFE::sendTimeZone() - MA returned false
Note how the very last line is "false" after "ISSUFE::sendTimeZone() - MA
returned "
Example of it failed:
ISSUFE::sendTimeZone() - Calling MA to set location with Africa/Addis_Ababa
cUFEImpl::setLocation() called in_str = Africa/Addis_Ababa
cUFEImpl::setLocation2() called in_str = Africa/Addis_Ababa
cTimeZoneObject()::setlocation()called inloc = Africa/Addis_Ababa
cTimeZoneObject()::setlocation() setting location genstring = ln -sf
/usr/share/zoneinfo/posix/Africa/Addis_Ababa /mnt/sdcard/.cxc/localtime
cUFEImpl::setLocation2() status flag = 1
MAUFEImpl::setLocation() - returning flag = 1
MAUFEImpl::setLocation() - returning true
ISSUFE::sendTimeZone() - MA returned
Note how the very last line is "" after "ISSUFE::sendTimeZone() - MA returned "
Any ideas? This is just very weird behavior. And I'm dumbfounded on how to
solve it.
Original comment by ian.harr...@gmail.com
on 27 Apr 2009 at 7:39
I am really sorry to keep posting. But I am trying to solve this. I modified
"SF/string.hpp" as indicated in the attached file. And when I get a "NULL"
string,
the IDL is not calling the read section of the archive.
Print out below....
1st) When I send a value that causes a "false" to be returned....
ISSUFE::sendTimeZone() - Calling MA to set location with -0500
SF/String:: Write - count = 5
SF/String:: Write - cstr = -0500
SF/String:: Write - charsToRead = 5 bytesToRead = 5
SF/String:: Read - cstr = -0500
cUFEImpl::setLocation() called in_str = -0500
cUFEImpl::setLocation2() called in_str = -0500
cTimeZoneObject()::setlocation()called inloc = -0500
cTimeZoneObject()::setlocation() - Destination location not found
cUFEImpl::setLocation2() status flag = 0
MAUFEImpl::setLocation() - returning flag = 0
MAUFEImpl::setLocation() - returning false
SF/String:: Write - count = 5
SF/String:: Write - cstr = false
SF/String:: Write - charsToRead = 5 bytesToRead = 5
SF/String:: Read - cstr = false
ISSUFE::sendTimeZone() - MA returned false
2nd) When I send a value that causes a "true" to be returned....
ISSUFE::sendTimeZone() - Calling MA to set location with Africa/Accra
SF/String:: Write - count = 12
SF/String:: Write - cstr = Africa/Accra
SF/String:: Write - charsToRead = 12 bytesToRead = 12
SF/String:: Read - cstr = Africa/Accra
cUFEImpl::setLocation() called in_str = Africa/Accra
cUFEImpl::setLocation2() called in_str = Africa/Accra
cTimeZoneObject()::setlocation()called inloc = Africa/Accra
cTimeZoneObject()::setlocation() setting location genstring = ln -sf
/usr/share/zoneinfo/posix/Africa/Accra /mnt/sdcard/.cxc/localtime
SCHED: 2009-04-27 03:10:57 Mon now playing [8cfbc4c58c4e4ca39999edca32d3e8ce
[PNG]]
cUFEImpl::setLocation2() status flag = 1
MAUFEImpl::setLocation() - returning flag = 1
MAUFEImpl::setLocation() - returning true
SF/String:: Write - count = 4
SF/String:: Write - cstr = true
<<<<<<< NOTE THERE IS NO READ CALLED TO DESERIALIZE THE STRING >>>>>>>>
ISSUFE::sendTimeZone() - MA returned
Original comment by ian.harr...@gmail.com
on 27 Apr 2009 at 8:17
Attachments:
Jarl, still trying to debug this some more. I added some more comments into
marshal.inl, Marshall.hpp and Serialization Protocol.cpp; I have attached them
with
this post.
Here is my output. When I have the set time fail it returns the correct value
of
"false". And it works as expected. Below is the console output:
ISSUFE::sendTimeZone() - Calling MA to set location with -0500
SerializationProtocolOut::reset() - called
SF/String:: serialize
SF/String:: Write - count = 5
SF/String:: Write - cstr = -0500
ClientMarshal_R1 calling ret
Marshal.inl - Before doInReturnValue
SerializationProtocolOut::reset() - called
SerializationProtocolIn::getRemainingArchiveLength() - pos = 0 len = 36
Remianing = 36
SF/String:: serialize
SF/String:: Read Entered
SF/String:: Read - count = 5
SF/String:: Read - charsToRead = 5 bytesToRead = 5
SF/String:: Read - cstr = -0500
cUFEImpl::setLocation() called in_str = -0500
cUFEImpl::setLocation2() called in_str = -0500
cTimeZoneObject()::setlocation()called inloc = -0500
cTimeZoneObject()::setlocation() - Destination location not found
cUFEImpl::setLocation2() status flag = 0
MAUFEImpl::setLocation() - returning flag = 0
MAUFEImpl::setLocation() - returning false
SF/String:: serialize
SF/String:: Write - count = 5
SF/String:: Write - cstr = false
SerializationProtocolIn::clearByteBuffer() - called
Marshal.inl - After doInReturnValue
Marshal.inl - inside if (!oneway && !retry)
SerializationProtocolIn::getRemainingArchiveLength() - pos = 0 len = 36
Remianing = 36
Marshal.inl - before deserialzie
SF/String:: serialize
SF/String:: Read Entered
SF/String:: Read - count = 5
SF/String:: Read - charsToRead = 5 bytesToRead = 5
SF/String:: Read - cstr = false
Marshal.inl - after deserialzie
ClientMarshal_R1 returned from ret
SerializationProtocolIn::clearByteBuffer() - called
ClientMarshal_R1 entered ret.get()
ISSUFE::sendTimeZone() - MA returned false
Now I send in a correct command and have it set the time. It now fails and
does NOT
behave as expected. The code has not changed between runs and in fact the
application is kept running.
ISSUFE::sendTimeZone() - Calling MA to set location with Africa/Accra
SerializationProtocolOut::reset() - called
SF/String:: serialize
SF/String:: Write - count = 12
SF/String:: Write - cstr = Africa/Accra
ClientMarshal_R1 calling ret
Marshal.inl - Before doInReturnValue
SerializationProtocolOut::reset() - called
SerializationProtocolIn::getRemainingArchiveLength() - pos = 0 len = 43
Remianing = 43
SF/String:: serialize
SF/String:: Read Entered
SF/String:: Read - count = 12
SF/String:: Read - charsToRead = 12 bytesToRead = 12
SF/String:: Read - cstr = Africa/Accra
cUFEImpl::setLocation() called in_str = Africa/Accra
cUFEImpl::setLocation2() called in_str = Africa/Accra
cTimeZoneObject()::setlocation()called inloc = Africa/Accra
SerializationProtocolOut::reset() - called <--- This gets called here and not
called
when successfully returns value in first scenario
cTimeZoneObject()::setlocation() setting location genstring = ln -sf
/usr/share/zoneinfo/posix/Africa/Accra /mnt/sdcard/.cxc/localtime
cUFEImpl::setLocation2() status flag = 1
MAUFEImpl::setLocation() - returning flag = 1
MAUFEImpl::setLocation() - returning true
SF/String:: serialize
SF/String:: Write - count = 13
SF/String:: Write - cstr = truestmaximus
SerializationProtocolIn::clearByteBuffer() - called <--- This gets called here
and
not called when successfully returns value in first scenario
SerializationProtocolIn::clearByteBuffer() - called <--- This gets called here
and
not called when successfully returns value in first scenario
SerializationProtocolIn::clear() - called <--- This gets called here and not
called
when successfully returns value in first scenario
SerializationProtocolOut::clear() - called <--- This gets called here and not
called
when successfully returns value in first scenario
SerializationProtocolOut::reset() - called <--- This gets called here and not
called
when successfully returns value in first scenario
SerializationProtocolIn::clearByteBuffer() - called <--- This gets called here
and
not called when successfully returns value in first scenario
Marshal.inl - After doInReturnValue
Marshal.inl - inside if (!oneway && !retry)
SerializationProtocolIn::getRemainingArchiveLength() - pos = 0 len = 0
Remianing = 0
<--- length is 0 because stream appears to have been cleared.
ClientMarshal_R1 returned from ret
SerializationProtocolIn::clearByteBuffer() - called
ClientMarshal_R1 entered ret.get()
ISSUFE::sendTimeZone() - MA returned
Any ideas you may have on where I can investigate further to solve this would be
greatly appreciated. Thanks... Ian
Original comment by ian.harr...@gmail.com
on 28 Apr 2009 at 2:31
Attachments:
Thanks for the detective work... I can kind of understand what is happening
(but not
why).
First of all, if you are sometimes getting an assert, then make sure you break
into
the debugger and get a stack trace - there shouldn't be any asserts happening
at all.
Secondly, when your server implementation function returns "true" (that's what
it
returns right?), I'm seeing this line in your trace output:
SF/String:: Write - cstr = truestmaximus
I would expect to see "true" here, not "truestmaximus" ... Any idea what's
going on
there? If you are actually returning "true", then this would seem to indicate
some
kind of memory corruption.
What then seems to happen, is that the reply the server is sending back to the
client gets truncated: the string contents that should have been serialized,
didn't
make it into the message. When the client then gets the message, it tries to
deserialize a string, but because it sees that there is no binary data at all
to
work from, it just returns a default initialized string (ie the one with a NULL
pointer).
Does that help any?
Original comment by jarl.lin...@gmail.com
on 30 Apr 2009 at 12:13
Original comment by jarl.lin...@gmail.com
on 30 Jul 2009 at 9:19
Original issue reported on code.google.com by
ian.harr...@gmail.com
on 23 Apr 2009 at 2:06Attachments: