Lifetime of service client response having staff::DataObject nodes issue

13 views
Skip to first unread message

Mike

unread,
Sep 4, 2014, 7:23:44 AM9/4/14
to wsf-...@googlegroups.com
Staff generated service client code (xml to C++ structures) does not 
properly take care of xs::Any elements that are stored in form of
std::list<staff::DataObject> AnyElements.

For example, we have service client that has two methods 

- method1(Response1 response), 
- method2(Response2 response)

responses contains C++ data converted from xml having any elements inside:

<xs:any namespace="##other" processContents="lax" minOccurs="0"maxOccurs="unbounded"/>

so staff generated response may have something similar like this:

struct Response1 
{
    std::list<staff::DataObject> AnyElements
}

where serialization   operator <<(Response1 &response , const staff::DataObject & res)
copies res to response.AnyElements  this way (generated  code by staffgen)

response.AnyElements = res; // originally AnyElements are named tUnnamed0

so staff::DataObjects in AnyElements have only references to axiom nodes

Response1 response1;
Response2 response2;

service->method1(response1);
service->method2(response2); 
// now all axiom nodes of DataObjects that are in response1.AnyElements are already distroyed
// because on each request axis2c releases/frees these axiom nodes that have been created as a response for method1 call (request)

My observation is that serialization code generated by staffgen code should use 
- staff::DataObject::Clone() function otherwise application will blow up,
- and staff::DataObject::SetOwner(true) to not to make memory leaks

Example:

Response1 response1;
Response2 response2;

service->method1(response1);
service->method2(response2); 
response1.AnyElements.begin().GetLocalName() // blows up because of axiom node does not exists (memory violation)



Dmitry Utkin

unread,
Sep 4, 2014, 7:35:19 AM9/4/14
to wsf-...@googlegroups.com
Hi Mike,

Sorry, I don't have time to check it now. Only I tough it's better to stay off Clone() method, because it is expensive. I believe DetachNode() could be used instead.

If you have patch to fix this issue I glad to commit it.

четверг, 4 сентября 2014 г., 15:23:44 UTC+4 пользователь Mike написал:
Reply all
Reply to author
Forward
0 new messages