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 "Bill Blough (Jira)" <ji...@apache.org> on 2020/04/07 16:52:00 UTC
[jira] [Updated] (AXIS2C-1583) Memory leak in
axis2_simple_http_svr_conn_read_request() (File
core/transport/http/common/simple_http_svr_conn.c)
[ https://issues.apache.org/jira/browse/AXIS2C-1583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Blough updated AXIS2C-1583:
--------------------------------
Fix Version/s: 1.7.0
> Memory leak in axis2_simple_http_svr_conn_read_request() (File core/transport/http/common/simple_http_svr_conn.c)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: AXIS2C-1583
> URL: https://issues.apache.org/jira/browse/AXIS2C-1583
> Project: Axis2-C
> Issue Type: Bug
> Components: transport/http
> Affects Versions: 1.6.0
> Environment: Solaris 10
> Reporter: Serghei Samsi
> Assignee: Korale Gamaralalage Nandika Chandrasiri Jayawardana
> Priority: Major
> Labels: patch
> Fix For: 1.7.0
>
>
> While running stress custom tests on AXIS2C v.1.6.0 (Solaris 10 enviroment), I've observed memory leak which continously grows RSS segment of AXIS2C process (simple http server is used).
> Running via Solaris MDB pointed directly to problem:
> ADDR BUFADDR TIMESTAMP THREAD
> CACHE LASTLOG CONTENTS
> 818fc40 818e4c0 18c2bd8827be3 2
> 809d590 0 0
> libumem.so.1`umem_cache_alloc_debug+0x16c
> libumem.so.1`umem_cache_alloc+0x15c
> libumem.so.1`umem_alloc+0x3f
> libumem.so.1`malloc+0x23
> libaxutil.so.0.6.0`axutil_allocator_malloc_impl+0x1b
> libaxutil.so.0.6.0`axutil_strdup+0x37
> libaxutil.so.0.6.0`axutil_stracat+0x9d
> libaxis2_http_common.so.0.6.0`axis2_simple_http_svr_conn_read_r
> equest+0x30e
> libaxis2_http_receiver.so.0.6.0`axis2_svr_thread_worker_func+0x
> 7a
> libaxutil.so.0.6.0`dummy_worker+0x10
> libc.so.1`_thr_setup+0x4e
> libc.so.1`_lwp_start
> umem_alloc_16 leak: 1751 buffers, 16 bytes each, 28016 bytes total
> ADDR BUFADDR TIMESTAMP THREAD
> CACHE LASTLOG CONTENTS
> 81b79d8 81b4d60 18c2bdb208a68 4
> 809d590 0 0
> libumem.so.1`umem_cache_alloc_debug+0x16c
> libumem.so.1`umem_cache_alloc+0xe1
> libumem.so.1`umem_alloc+0x3f
> libumem.so.1`malloc+0x23
> libaxutil.so.0.6.0`axutil_allocator_malloc_impl+0x1b
> libaxutil.so.0.6.0`axutil_strdup+0x37
> libaxutil.so.0.6.0`axutil_stracat+0x9d
> libaxis2_http_common.so.0.6.0`axis2_simple_http_svr_conn_read_r
> equest+0x30e
> libaxis2_http_receiver.so.0.6.0`axis2_svr_thread_worker_func+0x
> 7a
> libaxutil.so.0.6.0`dummy_worker+0x10
> libc.so.1`_thr_setup+0x4e
> libc.so.1`_lwp_start
> It is a trivial patch fix proposed.
> --- axi2c-src-1.6.0-orig/src/core/transport/http/common/simple_http_svr_conn.c 2009-04-06 07:46:47.000000000 +0300
> +++ axis2c-src-1.6.0/src/core/transport/http/common/simple_http_svr_conn.c 2012-01-30 16:55:40.109233000 +0200
> @@ -307,6 +307,11 @@
> break;
> }
> }
> + if (str_line)
> + {
> + AXIS2_FREE(env->allocator, str_line);
> + str_line = NULL;
> + }
> return request;
> }
> A quick review of AXIS2c v.1.7.0 shows that v.1.7.0 doesn't experience such problem. But probably more investigation should be done.
> Anyhow AXIS2c v.1.6.0 can be fixed by proposed patch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: c-dev-help@axis.apache.org