You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org> on 2005/03/07 05:24:52 UTC
[jira] Created: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
--------------------------------------------------------------------
Key: AXISCPP-507
URL: http://issues.apache.org/jira/browse/AXISCPP-507
Project: Axis-C++
Type: Bug
Components: SOAP
Versions: current (nightly)
Reporter: Samisa Abeysinghe
Fix For: 1.5 Final
Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
Hence, the generated code should take care of the clearance of memeory.
I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=comments#action_60414 ]
Samisa Abeysinghe commented on AXISCPP-507:
-------------------------------------------
Looks like the issue is still complex when it comes to arrays.
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Assignee: Samisa Abeysinghe
> Fix For: 1.5 Final
> Attachments: Document style.txt, RPC style.txt
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=comments#action_60351 ]
Samisa Abeysinghe commented on AXISCPP-507:
-------------------------------------------
Hi Adrian,
I too agree that, given the short life, if we are to clean memory in the destructor, it complicates the issues.
Hence the best would be to delete the memory at stub level, in which case, we may need to make a copy of the value of the pointer and delete the memory in generated code, and leave the destructor empty.
Implementing the more cleaner model of destructor releasing memory at this point is a bit risky as it would trigger changes at multiple places of the code.
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Fix For: 1.5 Final
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Adrian Dick (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=comments#action_60349 ]
Adrian Dick commented on AXISCPP-507:
-------------------------------------
While I agree that deleting storage in the destructor would be neatest solution for avoiding memory leaks, when I wrote these classes it wasn't quite so simple to do this.
These xsd objects have a very short lifecycle within the engine, and yet are typically nested several layers into the engine, meaning we'd need to carry out several deep copies before handing back to the customer application. Personally, I think this is a more robust way to program, but there are numerous routes by which we can reach these XSD objects, all of which will need reworking.
The best compromise is probably making a deep copy in the generated stubs, then deleting the storage, as I believe was Samisa's proposal.
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Fix For: 1.5 Final
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=comments#action_60412 ]
Samisa Abeysinghe commented on AXISCPP-507:
-------------------------------------------
Hi Chinthana,
I had a look at the RPC style solution you provided here. It solves the problem partially - but not completely :(
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Assignee: Samisa Abeysinghe
> Fix For: 1.5 Final
> Attachments: Document style.txt, RPC style.txt
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Chinthana Danapala (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=comments#action_60343 ]
Chinthana Danapala commented on AXISCPP-507:
--------------------------------------------
In XSD class int.cpp has the problem.
Here m_Int pointer is not deleting anywhere in the code.
It should delete in destructor.
Int::~Int()
{
delete m_Int;
}
and make a deep copy in a calling classes.
And there is short way of doing this as bellow.
we can have deep copy in auto generated code and delete the pointer there like this.
In WSDL style="document"
xsd__int r =* pReturn;
Ret = r;
delete pReturn;
return Ret;
In WSDL style="rpc"
xsd__int r = *Ret;
delete Ret;
return r;
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Fix For: 1.5 Final
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
Re: [jira] Closed: (AXISCPP-507) Memory leaks in deserialize methods of XSD
classes (in src/soap/xsd)
Posted by Adrian Dick <ad...@uk.ibm.com>.
Samisa,
While working on resolving AXISCPP-515 (
http://issues.apache.org/jira/browse/AXISCPP-515 ) I've been seeing
problems with the recent changes made to prevent memory leaks in the
generated stubs.
A simple fix, that I've found to work, is to simply remove some of the
recent fixes, as shown in the attached patch file: (See attached file:
org.apache.axis.wsdl.wsdl2ws.cpp.literal.BeanParamWriter.java.diff)
I'd prefer not to re-introduce the memory leaks you've recently fixed, so
do you have any thoughts on what can be done such that the ComplexLists
test works?
Incidentally, one of the problems I'm seeing has already been reported by
Tim Bartley in AXISCPP-511 (
http://issues.apache.org/jira/browse/AXISCPP-511 ), and he has provided
some thoughts on potential resolutions.
Thanks,
Adrian
_______________________________________
Adrian Dick (adrian.dick@uk.ibm.com)
"Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org> wrote on 08/03/2005
09:42:53:
> [ http://issues.apache.org/jira/browse/AXISCPP-507?page=history ]
>
> Samisa Abeysinghe closed AXISCPP-507:
> -------------------------------------
>
> Resolution: Fixed
>
> The WSDL tool code as well as some SoapDeSerializer class stuff and
> XSD class stuff were fixed to eliminate memory leaks.
>
> > Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> > --------------------------------------------------------------------
> >
> > Key: AXISCPP-507
> > URL: http://issues.apache.org/jira/browse/AXISCPP-507
> > Project: Axis-C++
> > Type: Bug
> > Components: SOAP
> > Versions: current (nightly)
> > Reporter: Samisa Abeysinghe
> > Assignee: Samisa Abeysinghe
> > Fix For: 1.5 Final
> > Attachments: Document style.txt, RPC style.txt
> >
> > Deserialize method returns a pointer that is never deleted. The
> generated code, dereferances the pointer and returns values to the Stub.
> > Hence, the generated code should take care of the clearance of memeory.
> > I tried to release this memeory in the destructor of the XSD
> class, but then by the time the generated code tries to access the
> value, the pointer is no more. This leaves the only option of
> deleting the memory returned in the generated code where it invokes
> the respective method.
> > Alternatively, we can make the XSD class manage its own memory and
> let the code accessing the memory make a deep copy of the returned
> pointer (that is generated code)
> > Whateve the fix would be, it needs changes to code generator.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
[jira] Closed: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=history ]
Samisa Abeysinghe closed AXISCPP-507:
-------------------------------------
Resolution: Fixed
The WSDL tool code as well as some SoapDeSerializer class stuff and XSD class stuff were fixed to eliminate memory leaks.
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Assignee: Samisa Abeysinghe
> Fix For: 1.5 Final
> Attachments: Document style.txt, RPC style.txt
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Chinthana Danapala (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=history ]
Chinthana Danapala updated AXISCPP-507:
---------------------------------------
Attachment: RPC style.txt
Document style.txt
I have attached the modifications to the ClientStubWriter.java in wsdl. This modification will solve the problem. But I didn't check further memory leaks with the modifications.
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Fix For: 1.5 Final
> Attachments: Document style.txt, RPC style.txt
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=comments#action_60413 ]
Samisa Abeysinghe commented on AXISCPP-507:
-------------------------------------------
OK I figured out the other problems - there seem to be some classes calling others in deserailizing - e.g. Int -> Long -> Integer
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Assignee: Samisa Abeysinghe
> Fix For: 1.5 Final
> Attachments: Document style.txt, RPC style.txt
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Assigned: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Posted by "Samisa Abeysinghe (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-507?page=history ]
Samisa Abeysinghe reassigned AXISCPP-507:
-----------------------------------------
Assign To: Samisa Abeysinghe
> Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
> --------------------------------------------------------------------
>
> Key: AXISCPP-507
> URL: http://issues.apache.org/jira/browse/AXISCPP-507
> Project: Axis-C++
> Type: Bug
> Components: SOAP
> Versions: current (nightly)
> Reporter: Samisa Abeysinghe
> Assignee: Samisa Abeysinghe
> Fix For: 1.5 Final
> Attachments: Document style.txt, RPC style.txt
>
> Deserialize method returns a pointer that is never deleted. The generated code, dereferances the pointer and returns values to the Stub.
> Hence, the generated code should take care of the clearance of memeory.
> I tried to release this memeory in the destructor of the XSD class, but then by the time the generated code tries to access the value, the pointer is no more. This leaves the only option of deleting the memory returned in the generated code where it invokes the respective method.
> Alternatively, we can make the XSD class manage its own memory and let the code accessing the memory make a deep copy of the returned pointer (that is generated code)
> Whateve the fix would be, it needs changes to code generator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira