divyang4481 / rcf-cpp

Automatically exported from code.google.com/p/rcf-cpp
0 stars 0 forks source link

RCF not returning expected values #15

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I am having issues with receiving a value back from a client.  Other
functions work, but this one does not....  I have tried returning a boolean
and a long (long's work on other function calls, just not this particular.
 This example is where I am attempting to try returning a long.

CLIENT SIDE:
long setLocation(std::string in_str)
    {
        bool flag = false;
        std::cout<<"cUFEImpl::setLocation() called in_str =
"<<in_str<<std::endl;

        flag = m_timezone.setlocation(in_str);

        std::cout<<"cUFEImpl::setLocation() status flag = "<<flag<<std::endl;

        if (flag == true)
        {
           std::cout<<"cUFEImpl::setLocation() returnign 9999"<<std::endl;
            return 9999;
        }
        return 0;
    }

SERVERSIDE:
bool sendTimeZone(std::string in_str)
{
#ifdef DEBUGOUT
    loggerimpl<<"cISSUFEImpl::sendTimeZone() called_val";
#endif
   try
   {
       long flag = -1;
       std::cout<<"ISSUFE::sendTimeZone() - Calling MA to set location with
"<<in_str<<std::endl;
       flag = mClient.setLocation(in_str);
       std::cout<<"ISSUFE::sendTimeZone() - MA returned
"<<(long)flag<<std::endl;
       if (flag > 0)
         return true;
       return false;
   }
   catch(...)
   {
#ifdef DEBUGOUT
       loggerimpl<<"cISSUFEImpl::sendTimeZone() Exception occurred.";
#endif
       return false;
   }
}

Attached is the IDL.  Server and Client are separate processes and builds,
but the IDL's are the same.

Here is what I receive when this code is called... 
ISSUFE::sendTimeZone() - Calling MA to set location with US/Michigan
cUFEImpl::setLocation() called in_str = US/Michigan
cTimeZoneObject()::setlocation()called inloc = US/Michigan
cTimeZoneObject()::setlocation() setting location genstring = ln -sf
/usr/share/zoneinfo/posix/US/Michigan /mnt/sdcard/.cxc/localtime
cUFEImpl::setLocation() status flag = 1
cUFEImpl::setLocation() returnign 9999
ISSUFE::sendTimeZone() - MA returned 0

So the Server is actually receiving a 0 and changing the initialized -1
value to 0.

I am compiling with the following parameters:
RCF_USE_BOOST_ASIO
RCF_USE_BOOST_READ_WRITE_MUTEX
RCF_USE_BOOST_THREADS
BOOST_ASIO_HAS_LOCAL_SOCKETS
RCF_USE_ZLIB

Any ideas on what might be happening?  As I said earlier though, other
functions work just fine and return what I would expect (including longs).

Original issue reported on code.google.com by ian.harr...@gmail.com on 23 Apr 2009 at 2:06

Attachments:

GoogleCodeExporter commented 9 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago

Original comment by jarl.lin...@gmail.com on 30 Jul 2009 at 9:19