Return-Path: Delivered-To: apmail-axis-c-dev-archive@www.apache.org Received: (qmail 24268 invoked from network); 14 Jan 2011 22:35:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Jan 2011 22:35:10 -0000 Received: (qmail 21070 invoked by uid 500); 14 Jan 2011 22:35:10 -0000 Delivered-To: apmail-axis-c-dev-archive@axis.apache.org Received: (qmail 21023 invoked by uid 500); 14 Jan 2011 22:35:09 -0000 Mailing-List: contact c-dev-help@axis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list c-dev@axis.apache.org Received: (qmail 21015 invoked by uid 99); 14 Jan 2011 22:35:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Jan 2011 22:35:09 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Jan 2011 22:35:07 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id p0EMYjeV022101 for ; Fri, 14 Jan 2011 22:34:46 GMT Message-ID: <8117778.378171295044485941.JavaMail.jira@thor> Date: Fri, 14 Jan 2011 17:34:45 -0500 (EST) From: "Christof Schmalenbach (JIRA)" To: c-dev@axis.apache.org Subject: [jira] Created: (AXIS2C-1529) wsdl2c generates skeleton code with memoryleak inside MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org wsdl2c generates skeleton code with memoryleak inside ----------------------------------------------------- Key: AXIS2C-1529 URL: https://issues.apache.org/jira/browse/AXIS2C-1529 Project: Axis2-C Issue Type: Bug Components: wsdl2c tool Affects Versions: 1.6.0 Environment: This bug can be reproduced on linux as well as on Win32. On Win32 the following environment is used - axis2c version 1.6.0 - axis2 java version axis2-1.5.2 (axis2-1.5.3 on linux) - java full version "JRE 1.6.0 IBM Windows 32 build pwi3260sr8fp1-20100903_02 (SR8 FP1)" Reporter: Christof Schmalenbach One can reproduce the problem with the following steps: 1. Compile the following java class (only to generate a appropriate wsdl used in step 2) package memleak; public class MemLeak { public byte[] getServiceData(byte[] input) { byte[] output = new byte[10]; return(output); } } 2. generate wsdl with the following command from the MemLeak class java2wsdl -o . -of axis2cwsdl2cmembug.wsdl -sn axis2cmemleak -cn memleak.MemLeak 3. generate serverside code (skeletons) from the axis2cwsdl2cmembug.wsdl with the following command: wsdl2c -o .\c_axis2cwsdl2membug_skeleton -ss -uri axis2cwsdl2cmembug.wsdl Step 3. generates the following artefacts: ./axis2_skel_axis2cmemleak.c ./axis2_skel_axis2cmemleak.h ./axis2_svc_skel_axis2cmemleak.c ./src ./src./adb_getServiceData.c ./src./adb_getServiceData.h ./src./adb_getServiceDataResponse.c ./src./adb_getServiceDataResponse.h Especially .the generated code /src./adb_getServiceDataResponse.c contains a memory leak in the function adb_getServiceDataResponse_serialize within every webservice request cycle. Following code is generated in this function: text_value_1 =axutil_base64_binary_get_encoded_binary(_getServiceDataResponse->property_return, env); axutil_stream_write(stream, env, start_input_str, start_input_str_len); axutil_stream_write(stream, env, text_value_1, axutil_strlen(text_value_1)); axutil_stream_write(stream, env, end_input_str, end_input_str_len); AXIS2_FREE(env->allocator,start_input_str); AXIS2_FREE(env->allocator,end_input_str); memory for start_input_str and for end_input_str are released , BUT not the memory allocated in axutil_base64_binary_get_encoded_binary for the pointer text_value_1. An AXIS2_FREE(env->allocator,text_value_1.); is missed. This AXIS2_FREE can be included in the generated code, solving the memory leak without destabilizing the service. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: c-dev-unsubscribe@axis.apache.org For additional commands, e-mail: c-dev-help@axis.apache.org