axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Blecken" <cblec...@macrovision.com>
Subject RE: [jira] Closed: (AXISCPP-507) Memory leaks in deserialize methods of XSD classes (in src/soap/xsd)
Date Wed, 09 Mar 2005 02:14:32 GMT
Hi Adrian,

I hope that you mean rolling back only the added delete sections.

The section 
  					writer.write("\t" + attribs[i].getTypeName() + " * " + attribs[i].getParamNameAsMember()+
" = NULL;\n");
  					writer.write("\tif ((" + attribs[i].getParamNameAsMember()+ " = pIWSDZ->"+CUtils.getParameterGetValueMethodName(attribs[i].getTypeName(),
attribs[i].isAttribute())+"( \""+ soapTagName +"\",0)) != NULL)\n");
  					writer.write("\t\tparam->"+attribs[i].getParamNameAsMember()+" = *( " + attribs[i].getParamNameAsMember()+"
);\n");

was put in to prevent SEGV for optional elements (AXISCPP-480) which we have
been running into.

Carsten

-----Original Message-----
From: Samisa Abeysinghe [mailto:sabeysinghe@virtusa.com]
Sent: Tuesday, March 08, 2005 5:51 PM
To: Apache AXIS C Developers List
Subject: Re: [jira] Closed: (AXISCPP-507) Memory leaks in deserialize
methods of XSD classes (in src/soap/xsd)


Hi Adrian,
	Please go ahead and remove these sections.
	Once 515 is fixed, I will have a look back into memory leaks and see
how to fix this without breaking deserialization. I think that would be
the easiest thing to do.
	Once 515 is fixed and the test case is working, I can use the same test
case to check for memory leaks, so that we can be sure that the leak
fixes would not break functionality.

Thanks,
Samisa...

On Wed, 2005-03-09 at 00:17, Adrian Dick wrote:
> 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)" <axis-c-dev@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
> >
-- 
Samisa Abeysinghe <sabeysinghe@virtusa.com>
Virtusa Corporation

Mime
View raw message