Archived

This forum has been archived. Please start a new discussion on GitHub.

AMD callback - using arguments after ice_response()

Andrew S
Andrew S
in Help Center
Hi!

We are using amd dispatch in our ice application:
1. complete request
2. analyze request data.

For example:
// ["ami", "amd"] void OnItemComplete(["cpp:array"] Ice::ByteSeq btResult);

virtual void OnItemComplete_async
  (
       constagent::AMD_IItemEvent_OnItemCompletePtr &pRes,
       const ::std::pair<const ::Ice::Byte*, const ::Ice::Byte*> &resData,
       const ::Ice::Current& /* = ::Ice::Current */
  )
{
    // complete just now!
    pRes->ice_response();
    OnItemComplete(resData);
}

Is it ok to use the argument buffer in such puttern, or it will be invalidated after ice_response()? It's works, but once we have received a strange buffer with partially damaged data - surely header of the another ice packet: 
0x0B845465  ac 10 81 b1 ca 12 ed 8e 11 c5 78 55 be 2f 84 c9  ¬.&#1027;±&#1050;.&#1085;&#1035;.&#1045;xU&#1109;/.&#1049;
0x0B845475  50 18 7f 2f a3 eb 00 00 49 63 65 50 01 00 01 00  P../&#1032;&#1083;..IceP....
0x0B845485  00 00 e9 02 00 00 4a 02 00 00 24 33 31 63 61 30  ..&#1081;...J...$31ca0
0x0B845495  36 36 37 2d 64 33 39 38 2d 34 33 39 35 2d 61 61  667-d398-4395-aa
0x0B8454A5  66 30 2d 64 37 33 30 39 62 35 35 31 66 34 61 00  f0-d7309b551f4a.
0x0B8454B5  00 0e 4f 6e 49 74 65 6d 43 6f 6d 70 6c 65 74 65  ..OnItemComplete

May be this is a bug on other side, f.e., while filling a request data, but at first look it seems can't be possible... And moreover - we sometimes see "bad magic" exceptions in our's logs - may be, this are linked problems...

Thanks!

--
Andrew Solodovnikov

Comments

  • dwayne
    dwayne St. John's, Newfoundland
    No, in this case is is not correct to access resData after ice_response() has been called. Since you are using ["cpp:array"] with a byte sequence, the pointers point directly into the transport buffer, which is no longer valid once the call completes (through a regular call returning or a amd call calling ice_response).
  • Andrew S
    Andrew S
    dwayne wrote: »
    No, in this case is is not correct to access resData after ice_response() has been called. Since you are using ["cpp:array"] with a byte sequence, the pointers point directly into the transport buffer, which is no longer valid once the call completes (through a regular call returning or a amd call calling ice_response).

    Thanks! I looked into generated proxy code, but it was not clear before your answer. But, maybe, it is good idea for ICE to hold buffer until dispatch call completes, not just until ice_response?
  • dwayne
    dwayne St. John's, Newfoundland
    Actually, having looked into this a bit further my previous statement is incorrect. The resData should remain valid until the dispatch call returns, whether it is amd or not.

    Therefore we are not sure why you are seeing this behavior. Perhaps you could try using a memory profiler such as valgrind and see what it says about memory usage.
  • Andrew S
    Andrew S
    dwayne wrote: »
    Actually, having looked into this a bit further my previous statement is incorrect. The resData should remain valid until the dispatch call returns, whether it is amd or not.

    Therefore we are not sure why you are seeing this behavior. Perhaps you could try using a memory profiler such as valgrind and see what it says about memory usage.

    It could be so simple solution... :( Thanks, i will try to verify client code - maybe, it can form incorrect buffer. But for now it looks like impossible situation.
    bwt, there is another problem with bad magic exception - i describe it in another topic.

Categories