Return-Path: Delivered-To: apmail-ws-axis-c-user-archive@www.apache.org Received: (qmail 72638 invoked from network); 20 Nov 2007 07:07:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Nov 2007 07:07:14 -0000 Received: (qmail 18787 invoked by uid 500); 20 Nov 2007 07:07:00 -0000 Delivered-To: apmail-ws-axis-c-user-archive@ws.apache.org Received: (qmail 18780 invoked by uid 500); 20 Nov 2007 07:07:00 -0000 Mailing-List: contact axis-c-user-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: "Apache AXIS C User List" Reply-To: "Apache AXIS C User List" Delivered-To: mailing list axis-c-user@ws.apache.org Received: (qmail 18769 invoked by uid 99); 20 Nov 2007 07:07:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Nov 2007 23:07:00 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dimuthuc@gmail.com designates 209.85.146.182 as permitted sender) Received: from [209.85.146.182] (HELO wa-out-1112.google.com) (209.85.146.182) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Nov 2007 07:06:50 +0000 Received: by wa-out-1112.google.com with SMTP id k22so2472755waf for ; Mon, 19 Nov 2007 23:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=zMyuJnJkS89wkSSHGHDHDjbQZhQhGi7DInAKCH18SKA=; b=bTxFoxJvFuARC49Vv+j7T9L3+Uuw0LmpvlWYcI1naerXIr2WoinXFqD3LO0lcHEXeaWpUaLMCmRB81dmvsZlfWCPHNDDqpg5mouCPsCdwit60FOomI39tz8KTn6t+NoZY6n8nbSogq8sA+RfRBX9kUTbZCaOn9FTzdOypiv/oe0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=sgQ8CkrwiB31vvjYSibC31iKCPYnZCJqJu+G3KktHrOVJBGYXKaoQks/hruQ14nB/XxFdH6I5Qb7ejKEdvXR73OKpls0fozBpeOyAhF8CTPf4kHkn7Q56dXnMsgNWiXspxhveQEZaa+TXeWEWvyZZ1+Mq+ivTR3k3paYUSte3jg= Received: by 10.115.32.1 with SMTP id k1mr175620waj.1195542404102; Mon, 19 Nov 2007 23:06:44 -0800 (PST) Received: by 10.114.211.6 with HTTP; Mon, 19 Nov 2007 23:06:44 -0800 (PST) Message-ID: Date: Tue, 20 Nov 2007 12:36:44 +0530 From: "Dimuthu Gamage" To: "Apache AXIS C User List" Subject: Re: Axis2/C Memory Leaks In-Reply-To: <535BC169F3AFFD47926A743A46F882C8AE260A@CORPUSMX60C.corp.emc.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_20317_15489227.1195542404095" References: <535BC169F3AFFD47926A743A46F882C8AE260A@CORPUSMX60C.corp.emc.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_20317_15489227.1195542404095 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, You dont need to free any axis2, adb related thing in your server side when you works on generated code using wsdl2c (at least Theoretically:) ) . Only thing you need to do is write the business logic, and free whatever you malloced inside there. Thanks Dimuthu On Nov 20, 2007 3:34 AM, wrote: > Hi, > > I am designing some web service client code using the Axis2/C framework > (used WSDL2C to generate client stubs that call the framework). I have > a separate executable C file (C file that a main()) that calls the stub. > When I ran valgrind initially on it, I saw many memory leaks from this; > 49 loss records to be exact. However, after inserting axis2_stub_free > and axutil_env_free before my end return statement in my executable C > file, I noticed that the loss records decreased greatly to 5. I noticed > that this freeing of the stub and env variables is not in the sample > client code. Should the sample client code also demonstrate this > freeing, and is this freeing logical to do on the client side? Also, I > did some initial tests on the server side and noticed many memory leaks > as well. Should this client-side freeing be also implemented on my > server code, or is the server-side freeing done differently and how if > anyone can describe where to insert the freeing statements? > > Thanks, > Edward > > --------------------------------------------------------------------- > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org > For additional commands, e-mail: axis-c-user-help@ws.apache.org > > ------=_Part_20317_15489227.1195542404095 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
You dont need to free any axis2, adb related thing in your server side when you works on generated code using wsdl2c (at least Theoretically:) ) . Only thing you need to do is write the business logic, and free whatever you malloced inside there.

Thanks
Dimuthu

On Nov 20, 2007 3:34 AM, <Liu_Edward@emc.com> wrote:
Hi,

I am designing some web service client code using the Axis2/C framework
(used WSDL2C to generate client stubs that call the framework).  I have
a separate executable C file (C file that a main()) that calls the stub.
When I ran valgrind initially on it, I saw many memory leaks from this;
49 loss records to be exact.  However, after inserting axis2_stub_free
and axutil_env_free before my end return statement in my executable C
file, I noticed that the loss records decreased greatly to 5.  I noticed
that this freeing of the stub and env variables is not in the sample
client code.  Should the sample client code also demonstrate this
freeing, and is this freeing logical to do on the client side?  Also, I
did some initial tests on the server side and noticed many memory leaks
as well.  Should this client-side freeing be also implemented on my
server code, or is the server-side freeing done differently and how if
anyone can describe where to insert the freeing statements?


Thanks,
Edward

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org


------=_Part_20317_15489227.1195542404095--