Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: pass (hermes.apache.org: domain of samisa.abeysinghe@gmail.com
 designates 64.233.184.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=k6CWNMMvHRL32N5ZQpkIAP3UWLNyjETiFWCZEOcZHpKemAeaSE7EmSfPvyQkoqnZxjyiJfK5aTkYnd7mD7TJt59UvRkNc9vdtxfGTB4DeDKVit1k9fL/VvP/5BBEO/dyCR8TV6qn+ri0wSVsKbctdqtJRMpjuJlFlCdkiQp02Sw=
Message-ID: <a0f0c14804122102572b9be9d6@mail.gmail.com>
Date: Tue, 21 Dec 2004 10:57:50 +0000
From: Samisa Abeysinghe <samisa.abeysinghe@gmail.com>
Reply-To: Samisa Abeysinghe <samisa.abeysinghe@gmail.com>
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>,
	susantha@opensource.lk
Subject: Re: [Fwd: Re: Problems with deleting void*]
In-Reply-To: <41C7B15F.3020809@opensource.lk>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <41C79D22.1010108@opensource.lk> <41C7B15F.3020809@opensource.lk>

Oh I did not know that. Is this documented anywhere. BTW, how do we
delete an array with this? Treat array as an object I guess.

Samisa...


On Tue, 21 Dec 2004 11:15:11 +0600, Susantha Kumara
<susantha@opensource.lk> wrote:
>  Hi Samisa
>  
> 
>  Well this is not about cleaning returned arrays. The error appears in
> places, where the already allocated memory is cleaned in case of returning
> an empty array when an error is encountered. We need to have some fix for
> this to gauard against memory leaks. Samisa... Yes from within Axis we
> ALWAYS allocate complex objects using AXIS_OBJECT_CREATE_FUNCT function and
> they should ALWAYS be deallocated using AXIS_OBJECT_DELETE_FUNCT function. 
>  
>  Regards,
>  
>  Susantha..
> 
>  
>  
>  On Mon, 20 Dec 2004 17:44:00 +0600, Susantha Kumara
> <susantha@opensource.lk> wrote: 
>  Samisa Abeysinghe wrote: I dont get this. Then would not there be a memory
> leak? Samisa... On Mon, 
>  20 Dec 2004 17:24:53 +0600, Susantha Kumara <susantha@opensource.lk> wrote:
>  Samisa Abeysinghe wrote: 
>  Hi All, In the SoapDeSerializer class, I get the following warning 
>  when compiling. I fixed similar warnings at other places in the same 
>  class prior to the release of 1.4 Alpha, but could not fix these few, 
>  as there is no knowlege of the types that we are dealing with in 
>  this scope. The warning is as follows: SoapDeSerializer.cpp: In member 
>  function `virtual axiscpp::Axis_Array
> axiscpp::SoapDeSerializer::getCmplxArray(void*, void*, void*, void*, const
> char*, const char*)': SoapDeSerializer.cpp:606: warning: deleting `void*' is
>  undefined SoapDeSerializer.cpp:631: warning: deleting `void*' is 
>  undefined SoapDeSerializer.cpp:672: warning: deleting `void*' is 
>  undefined I think it is importat to fix this, as even though it is a 
>  warning, it says, "deleting `void*' is undefined". This may well mean that 
>  the runtime is not doing anything (or may be the compiler is fooling us ;-)
>  ) Any ideas on how to fix this? Thanks, Samisa... Could you please 
>  use following 3 lines ((AXIS_OBJECT_DELETE_FUNCT) pDelFunct) 
>  (Array.m_Array, true, Array.m_Size); Array.m_Array = 0; Array.m_Size = 
>  0; instead of , delete[]Array.m_Array; Array.m_Size = 0; That is the 
>  intended way to deallocate any memory of complex type objects allocated 
>  using AXIS_OBJECT_CREATE_FUNCT. Thanks, Susantha. No. 
>  ((AXIS_OBJECT_DELETE_FUNCT) pDelFunct) (Array.m_Array, true, Array.m_Size);
> function calls the generated delete method of the type's 
>  wrapper where this array is deleted properly. see the delete function of 
>  SOAPStruct: /* 
>  * This static method delete a SOAPStruct type of object */ void
> Axis_Delete_SOAPStruct(SOAPStruct* param, bool bArray = false, int nSize=0)
> { if (bArray) { delete [] param; //array is deleted here } else { delete
> param; } } 
>