You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-user@axis.apache.org by Alex Bolgarov <al...@bolgarov.org> on 2008/03/28 20:38:25 UTC
Memory leak in mod_axis2?
Hi again.
I've just run the echo service sample within the Apache2 httpd server
(with the mod_axis2 module), I used the echo client but put the
send-receive into the loop with 1,000,000 iterations.
What I observed, was constant increasing of the memory (both resident
and virtual, as the 'top' command shows) in the httpd process: approx.
1 megabyte every 5 sec. After 20 min. all phisical memory on my
computer was used, and it started hitting the swap, so I terminated
the test.
What is interesting though, when I run the same echo service with a
standalone Axis2/server (axis2_http_server application), there was no
increase of the memory usage by it - the whole 40 min. the test was
running, the memory usage was stable, and the whole 1 million requests
were successful.
Should we made a conclusion from this that there is a memory leak, and
specifically, a memory leak in the mod_axis2 code?
I'm using Ubuntu Linux 7.10, Apache httpd 2.2.4 compiled from sources.
Yes, I know, the latest version of Apache2 is 2.2.8, so I'm going to
download and build this version and will try with it again.
Thank you,
alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Milinda Pathirage wrote:
> Hi,
> I think Dinesh's solution will be a quick fix for this. But we have to
> concentrate on the pareser specific code inside om_stax_builder.c also.
+1 for fixing it this way for the time being.
Thanks,
Samisa...
>
> Thanks
> Milinda...
>
> On Wed, Apr 16, 2008 at 12:05 PM, Dinesh Premalal <xydinesh@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi,
>
> Other solution may be we could define AXIS2_LIBXML2_DEFINED
> with --enable-libxml2 and modify the logic according to it. There
> are only 4 or 5 places that need to be changed.
>
> +1 for fixing this before 1.3.1 release.
>
> thanks,
> Dinesh
>
>
> On Wed, Apr 16, 2008 at 11:58 AM, Milinda Pathirage
> <milinda.pathirage@gmail.com <ma...@gmail.com>>
> wrote:
>
> Hi,
> I think the hack samisa proposed earlier is not working,
> because we didn't include any header files specific to
> guththila inside axiom code which related to
> om_stax_builder.c. If we include it in axiom_xml_reader.h, it
> worked well. But this hack is not acceptable due to it parser
> specific code inside axiom code (other than wrappers). Is
> there any specific '#define' for libxml. If we have one we can
> change the current code to check whether libxml is enabled, or
> we can simple define AXIS2_ENABLE_GUTHTHILA at configuration.
>
> Other than the comment handling, there are many places in
> om_stax_builder.c which we have use AXIS2_GUTHTHILA_ENABLED. I
> think we must fix this before 1.3.1 release.
>
> Please feel free to comment in this.
>
> Thanks
> Milinda.
>
>
> On Fri, Apr 11, 2008 at 10:44 PM, Samisa Abeysinghe
> <samisa@wso2.com <ma...@wso2.com>> wrote:
>
>
> Milinda Pathirage wrote:
>
> Hi Alex and Samisa,
>
> This bug was caused by recent change of default
> parser. In the om_stax_builder.c, we previously check
> whether guththila is enabled and free the comment
> vlaue when we encounter a comment. Now guththila is
> default we don have AXIS2_GUTHTHILA_ENABLED defined at
> the compile time.
>
>
> hmm, Good point. The whole trouble is because of a design
> flow, how come a parser specific thing came to a parser
> independent logic? :)
>
> As an immediat efix, we can define AXIS2_GUTHTHILA_ENABLED
> in some Guththila header. However that is a hack, and not
> a neat fix. In the long run, we need to find why we have
> to treat comments form different parsers differently and
> fix that issue.
>
> Please raise a Jira on this.
>
> Thanks,
> Samisa...
>
>
> #ifdef AXIS2_GUTHTHILA_ENABLED*/
>
> AXIS2_FREE(env->allocator,comment_value);
>
> #else
>
>
> axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
>
> #endif
>
> I changed the above lines to following
>
> /*#ifdef AXIS2_GUTHTHILA_ENABLED*/
>
> AXIS2_FREE(env->allocator,comment_value);
>
> /*#else*/
> #ifdef AXIS2_LIBXML_ENABLED
>
> axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
>
> #endif
>
> and now definitely lost: 690 bytes in 46 blocks.
>
> I have attached the valgrind log. I don't know the
> correct way to handle LIBXML enabling. Please can some
> one change the 'axiom_stax_builder_create_om_comment'
> function in om_stax_builder.c file to reflect recent
> changes in default parser.
>
> Thanks
> Milinda
>
>
> On Thu, Apr 10, 2008 at 6:01 PM, Samisa Abeysinghe
> <samisa@wso2.com <ma...@wso2.com>
> <mailto:samisa@wso2.com <ma...@wso2.com>>> wrote:
>
> Alex,
> In the mean time, try with libxml2 paarser.
> Samisa...
>
>
> Samisa Abeysinghe wrote:
>
> Samisa Abeysinghe wrote:
>
>
> Alex Bolgarov wrote:
>
> On Wed, Apr 9, 2008 at 3:36 PM, Samisa
> Abeysinghe
> <samisa@wso2.com
> <ma...@wso2.com> <mailto:samisa@wso2.com
> <ma...@wso2.com>>> wrote:
>
> In the mean time, please send the
> valgrind log.
>
>
> I did send the valgrind log to the list
>
>
> Sorry, I missed it (was a bit sleepy at the
> time I replied
> ;) )
>
> Looking at the log, it is a newly
> introduced one, with
> Guththila parser. I remember Lahuri
> mentioning about this
> leak once, and I was under the impression
> that this was
> fixed. Anyway I will have a look.
>
>
> I had a more detailed look into the code and
> there are some
> leaks to be fixed. I am curretly at ApacheCon
> and do not have
> access to a Linux box, and would only have time
> to fix this
> next week. Can someone please look into this in
> the mean time.
>
> Thanks,
> Samisa...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> axis-c-user-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> <mailto:axis-c-user-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>>
>
> For additional commands, e-mail:
> axis-c-user-help@ws.apache.org
> <ma...@ws.apache.org>
> <mailto:axis-c-user-help@ws.apache.org
> <ma...@ws.apache.org>>
>
>
>
>
>
>
> -- Samisa Abeysinghe Software Architect; WSO2 Inc.
>
> http://www.wso2.com/ - "Oxygenating the Web Service
> Platform."
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> axis-c-user-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> <mailto:axis-c-user-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>>
>
> For additional commands, e-mail:
> axis-c-user-help@ws.apache.org
> <ma...@ws.apache.org>
> <mailto:axis-c-user-help@ws.apache.org
> <ma...@ws.apache.org>>
>
>
>
>
>
> --
> http://inf-dimensions.blogspot.com "Infinite Dimensions"
> http://wsaxc.blogspot.com "Web Services With Axis2/C"
> ------------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> axis-c-user-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail:
> axis-c-user-help@ws.apache.org
> <ma...@ws.apache.org>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG. Version: 7.5.519 / Virus Database:
> 269.22.11/1368 - Release Date: 4/9/2008 4:20 PM
>
>
>
> --
> Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>
> http://www.wso2.com/ - "The Open Source SOA Company"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> axis-c-user-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail:
> axis-c-user-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
> --
> http://inf-dimensions.blogspot.com "Infinite Dimensions"
> http://wsaxc.blogspot.com "Web Services With Axis2/C"
>
>
>
>
> --
> http://nethu.org/
>
>
>
>
> --
> http://inf-dimensions.blogspot.com "Infinite Dimensions"
> http://wsaxc.blogspot.com "Web Services With Axis2/C"
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.23.0/1379 - Release Date: 4/15/2008 6:10 PM
>
--
Samisa Abeysinghe
Director, Engineering; WSO2 Inc.
http://www.wso2.com/ - "The Open Source SOA Company"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Milinda Pathirage <mi...@gmail.com>.
Hi,
I think Dinesh's solution will be a quick fix for this. But we have to
concentrate on the pareser specific code inside om_stax_builder.c also.
Thanks
Milinda...
On Wed, Apr 16, 2008 at 12:05 PM, Dinesh Premalal <xy...@gmail.com>
wrote:
> Hi,
>
> Other solution may be we could define AXIS2_LIBXML2_DEFINED with
> --enable-libxml2 and modify the logic according to it. There are only 4 or 5
> places that need to be changed.
>
> +1 for fixing this before 1.3.1 release.
>
> thanks,
> Dinesh
>
>
> On Wed, Apr 16, 2008 at 11:58 AM, Milinda Pathirage <
> milinda.pathirage@gmail.com> wrote:
>
> > Hi,
> > I think the hack samisa proposed earlier is not working, because we
> > didn't include any header files specific to guththila inside axiom code
> > which related to om_stax_builder.c. If we include it in axiom_xml_reader.h,
> > it worked well. But this hack is not acceptable due to it parser specific
> > code inside axiom code (other than wrappers). Is there any specific
> > '#define' for libxml. If we have one we can change the current code to check
> > whether libxml is enabled, or we can simple define AXIS2_ENABLE_GUTHTHILA at
> > configuration.
> >
> > Other than the comment handling, there are many places in
> > om_stax_builder.c which we have use AXIS2_GUTHTHILA_ENABLED. I think we must
> > fix this before 1.3.1 release.
> >
> > Please feel free to comment in this.
> >
> > Thanks
> > Milinda.
> >
> >
> > On Fri, Apr 11, 2008 at 10:44 PM, Samisa Abeysinghe <sa...@wso2.com>
> > wrote:
> >
> > >
> > > Milinda Pathirage wrote:
> > >
> > > > Hi Alex and Samisa,
> > > >
> > > > This bug was caused by recent change of default parser. In the
> > > > om_stax_builder.c, we previously check whether guththila is enabled and free
> > > > the comment vlaue when we encounter a comment. Now guththila is default we
> > > > don have AXIS2_GUTHTHILA_ENABLED defined at the compile time.
> > > >
> > >
> > > hmm, Good point. The whole trouble is because of a design flow, how
> > > come a parser specific thing came to a parser independent logic? :)
> > >
> > > As an immediat efix, we can define AXIS2_GUTHTHILA_ENABLED in some
> > > Guththila header. However that is a hack, and not a neat fix. In the long
> > > run, we need to find why we have to treat comments form different parsers
> > > differently and fix that issue.
> > >
> > > Please raise a Jira on this.
> > >
> > > Thanks,
> > > Samisa...
> > >
> > >
> > > > #ifdef AXIS2_GUTHTHILA_ENABLED*/
> > > >
> > > > AXIS2_FREE(env->allocator,comment_value);
> > > >
> > > > #else
> > > >
> > > > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> > > >
> > > > #endif
> > > >
> > > > I changed the above lines to following
> > > >
> > > > /*#ifdef AXIS2_GUTHTHILA_ENABLED*/
> > > >
> > > > AXIS2_FREE(env->allocator,comment_value);
> > > >
> > > > /*#else*/
> > > > #ifdef AXIS2_LIBXML_ENABLED
> > > > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> > > >
> > > > #endif
> > > >
> > > > and now definitely lost: 690 bytes in 46 blocks.
> > > >
> > > > I have attached the valgrind log. I don't know the correct way to
> > > > handle LIBXML enabling. Please can some one change the
> > > > 'axiom_stax_builder_create_om_comment' function in om_stax_builder.c file to
> > > > reflect recent changes in default parser.
> > > >
> > > > Thanks
> > > > Milinda
> > > >
> > > >
> > > > On Thu, Apr 10, 2008 at 6:01 PM, Samisa Abeysinghe <samisa@wso2.com<mailto:
> > > > samisa@wso2.com>> wrote:
> > > >
> > > > Alex,
> > > > In the mean time, try with libxml2 paarser.
> > > > Samisa...
> > > >
> > > >
> > > > Samisa Abeysinghe wrote:
> > > >
> > > > Samisa Abeysinghe wrote:
> > > >
> > > >
> > > > Alex Bolgarov wrote:
> > > >
> > > > On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe
> > > > <samisa@wso2.com <ma...@wso2.com>> wrote:
> > > >
> > > > In the mean time, please send the valgrind log.
> > > >
> > > >
> > > > I did send the valgrind log to the list
> > > >
> > > >
> > > > Sorry, I missed it (was a bit sleepy at the time I
> > > > replied
> > > > ;) )
> > > >
> > > > Looking at the log, it is a newly introduced one, with
> > > > Guththila parser. I remember Lahuri mentioning about this
> > > > leak once, and I was under the impression that this was
> > > > fixed. Anyway I will have a look.
> > > >
> > > >
> > > > I had a more detailed look into the code and there are some
> > > > leaks to be fixed. I am curretly at ApacheCon and do not have
> > > > access to a Linux box, and would only have time to fix this
> > > > next week. Can someone please look into this in the mean
> > > > time.
> > > >
> > > > Thanks,
> > > > Samisa...
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > > <ma...@ws.apache.org>
> > > > For additional commands, e-mail:
> > > > axis-c-user-help@ws.apache.org
> > > > <ma...@ws.apache.org>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -- Samisa Abeysinghe Software Architect; WSO2 Inc.
> > > >
> > > > http://www.wso2.com/ - "Oxygenating the Web Service Platform."
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > > <ma...@ws.apache.org>
> > > > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > > > <ma...@ws.apache.org>
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://inf-dimensions.blogspot.com "Infinite Dimensions"
> > > > http://wsaxc.blogspot.com "Web Services With Axis2/C"
> > > >
> > > > ------------------------------------------------------------------------
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > > >
> > > > ------------------------------------------------------------------------
> > > >
> > > > No virus found in this incoming message.
> > > > Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.11/1368 -
> > > > Release Date: 4/9/2008 4:20 PM
> > > >
> > >
> > >
> > > --
> > > Samisa Abeysinghe Director, Engineering; WSO2 Inc.
> > >
> > > http://www.wso2.com/ - "The Open Source SOA Company"
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > http://inf-dimensions.blogspot.com "Infinite Dimensions"
> > http://wsaxc.blogspot.com "Web Services With Axis2/C"
> >
>
>
>
> --
> http://nethu.org/
--
http://inf-dimensions.blogspot.com "Infinite Dimensions"
http://wsaxc.blogspot.com "Web Services With Axis2/C"
Re: Memory leak in mod_axis2?
Posted by Dinesh Premalal <xy...@gmail.com>.
Hi,
Other solution may be we could define AXIS2_LIBXML2_DEFINED with
--enable-libxml2 and modify the logic according to it. There are only 4 or 5
places that need to be changed.
+1 for fixing this before 1.3.1 release.
thanks,
Dinesh
On Wed, Apr 16, 2008 at 11:58 AM, Milinda Pathirage <
milinda.pathirage@gmail.com> wrote:
> Hi,
> I think the hack samisa proposed earlier is not working, because we didn't
> include any header files specific to guththila inside axiom code which
> related to om_stax_builder.c. If we include it in axiom_xml_reader.h, it
> worked well. But this hack is not acceptable due to it parser specific code
> inside axiom code (other than wrappers). Is there any specific '#define' for
> libxml. If we have one we can change the current code to check whether
> libxml is enabled, or we can simple define AXIS2_ENABLE_GUTHTHILA at
> configuration.
>
> Other than the comment handling, there are many places in
> om_stax_builder.c which we have use AXIS2_GUTHTHILA_ENABLED. I think we must
> fix this before 1.3.1 release.
>
> Please feel free to comment in this.
>
> Thanks
> Milinda.
>
>
> On Fri, Apr 11, 2008 at 10:44 PM, Samisa Abeysinghe <sa...@wso2.com>
> wrote:
>
> >
> > Milinda Pathirage wrote:
> >
> > > Hi Alex and Samisa,
> > >
> > > This bug was caused by recent change of default parser. In the
> > > om_stax_builder.c, we previously check whether guththila is enabled and free
> > > the comment vlaue when we encounter a comment. Now guththila is default we
> > > don have AXIS2_GUTHTHILA_ENABLED defined at the compile time.
> > >
> >
> > hmm, Good point. The whole trouble is because of a design flow, how come
> > a parser specific thing came to a parser independent logic? :)
> >
> > As an immediat efix, we can define AXIS2_GUTHTHILA_ENABLED in some
> > Guththila header. However that is a hack, and not a neat fix. In the long
> > run, we need to find why we have to treat comments form different parsers
> > differently and fix that issue.
> >
> > Please raise a Jira on this.
> >
> > Thanks,
> > Samisa...
> >
> >
> > > #ifdef AXIS2_GUTHTHILA_ENABLED*/
> > >
> > > AXIS2_FREE(env->allocator,comment_value);
> > >
> > > #else
> > >
> > > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> > >
> > > #endif
> > >
> > > I changed the above lines to following
> > >
> > > /*#ifdef AXIS2_GUTHTHILA_ENABLED*/
> > >
> > > AXIS2_FREE(env->allocator,comment_value);
> > >
> > > /*#else*/
> > > #ifdef AXIS2_LIBXML_ENABLED
> > > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> > >
> > > #endif
> > >
> > > and now definitely lost: 690 bytes in 46 blocks.
> > >
> > > I have attached the valgrind log. I don't know the correct way to
> > > handle LIBXML enabling. Please can some one change the
> > > 'axiom_stax_builder_create_om_comment' function in om_stax_builder.c file to
> > > reflect recent changes in default parser.
> > >
> > > Thanks
> > > Milinda
> > >
> > >
> > > On Thu, Apr 10, 2008 at 6:01 PM, Samisa Abeysinghe <samisa@wso2.com<mailto:
> > > samisa@wso2.com>> wrote:
> > >
> > > Alex,
> > > In the mean time, try with libxml2 paarser.
> > > Samisa...
> > >
> > >
> > > Samisa Abeysinghe wrote:
> > >
> > > Samisa Abeysinghe wrote:
> > >
> > >
> > > Alex Bolgarov wrote:
> > >
> > > On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe
> > > <samisa@wso2.com <ma...@wso2.com>> wrote:
> > >
> > > In the mean time, please send the valgrind log.
> > >
> > >
> > > I did send the valgrind log to the list
> > >
> > >
> > > Sorry, I missed it (was a bit sleepy at the time I replied
> > > ;) )
> > >
> > > Looking at the log, it is a newly introduced one, with
> > > Guththila parser. I remember Lahuri mentioning about this
> > > leak once, and I was under the impression that this was
> > > fixed. Anyway I will have a look.
> > >
> > >
> > > I had a more detailed look into the code and there are some
> > > leaks to be fixed. I am curretly at ApacheCon and do not have
> > > access to a Linux box, and would only have time to fix this
> > > next week. Can someone please look into this in the mean time.
> > >
> > > Thanks,
> > > Samisa...
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > <ma...@ws.apache.org>
> > > For additional commands, e-mail:
> > > axis-c-user-help@ws.apache.org
> > > <ma...@ws.apache.org>
> > >
> > >
> > >
> > >
> > >
> > > -- Samisa Abeysinghe Software Architect; WSO2 Inc.
> > >
> > > http://www.wso2.com/ - "Oxygenating the Web Service Platform."
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > <ma...@ws.apache.org>
> > > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > > <ma...@ws.apache.org>
> > >
> > >
> > >
> > >
> > > --
> > > http://inf-dimensions.blogspot.com "Infinite Dimensions"
> > > http://wsaxc.blogspot.com "Web Services With Axis2/C"
> > >
> > > ------------------------------------------------------------------------
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > >
> > > ------------------------------------------------------------------------
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.11/1368 -
> > > Release Date: 4/9/2008 4:20 PM
> > >
> >
> >
> > --
> > Samisa Abeysinghe Director, Engineering; WSO2 Inc.
> >
> > http://www.wso2.com/ - "The Open Source SOA Company"
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> >
> >
>
>
> --
> http://inf-dimensions.blogspot.com "Infinite Dimensions"
> http://wsaxc.blogspot.com "Web Services With Axis2/C"
>
--
http://nethu.org/
Re: Memory leak in mod_axis2?
Posted by Dinesh Premalal <xy...@gmail.com>.
Hi,
Other solution may be we could define AXIS2_LIBXML2_DEFINED with
--enable-libxml2 and modify the logic according to it. There are only 4 or 5
places that need to be changed.
+1 for fixing this before 1.3.1 release.
thanks,
Dinesh
On Wed, Apr 16, 2008 at 11:58 AM, Milinda Pathirage <
milinda.pathirage@gmail.com> wrote:
> Hi,
> I think the hack samisa proposed earlier is not working, because we didn't
> include any header files specific to guththila inside axiom code which
> related to om_stax_builder.c. If we include it in axiom_xml_reader.h, it
> worked well. But this hack is not acceptable due to it parser specific code
> inside axiom code (other than wrappers). Is there any specific '#define' for
> libxml. If we have one we can change the current code to check whether
> libxml is enabled, or we can simple define AXIS2_ENABLE_GUTHTHILA at
> configuration.
>
> Other than the comment handling, there are many places in
> om_stax_builder.c which we have use AXIS2_GUTHTHILA_ENABLED. I think we must
> fix this before 1.3.1 release.
>
> Please feel free to comment in this.
>
> Thanks
> Milinda.
>
>
> On Fri, Apr 11, 2008 at 10:44 PM, Samisa Abeysinghe <sa...@wso2.com>
> wrote:
>
> >
> > Milinda Pathirage wrote:
> >
> > > Hi Alex and Samisa,
> > >
> > > This bug was caused by recent change of default parser. In the
> > > om_stax_builder.c, we previously check whether guththila is enabled and free
> > > the comment vlaue when we encounter a comment. Now guththila is default we
> > > don have AXIS2_GUTHTHILA_ENABLED defined at the compile time.
> > >
> >
> > hmm, Good point. The whole trouble is because of a design flow, how come
> > a parser specific thing came to a parser independent logic? :)
> >
> > As an immediat efix, we can define AXIS2_GUTHTHILA_ENABLED in some
> > Guththila header. However that is a hack, and not a neat fix. In the long
> > run, we need to find why we have to treat comments form different parsers
> > differently and fix that issue.
> >
> > Please raise a Jira on this.
> >
> > Thanks,
> > Samisa...
> >
> >
> > > #ifdef AXIS2_GUTHTHILA_ENABLED*/
> > >
> > > AXIS2_FREE(env->allocator,comment_value);
> > >
> > > #else
> > >
> > > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> > >
> > > #endif
> > >
> > > I changed the above lines to following
> > >
> > > /*#ifdef AXIS2_GUTHTHILA_ENABLED*/
> > >
> > > AXIS2_FREE(env->allocator,comment_value);
> > >
> > > /*#else*/
> > > #ifdef AXIS2_LIBXML_ENABLED
> > > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> > >
> > > #endif
> > >
> > > and now definitely lost: 690 bytes in 46 blocks.
> > >
> > > I have attached the valgrind log. I don't know the correct way to
> > > handle LIBXML enabling. Please can some one change the
> > > 'axiom_stax_builder_create_om_comment' function in om_stax_builder.c file to
> > > reflect recent changes in default parser.
> > >
> > > Thanks
> > > Milinda
> > >
> > >
> > > On Thu, Apr 10, 2008 at 6:01 PM, Samisa Abeysinghe <samisa@wso2.com<mailto:
> > > samisa@wso2.com>> wrote:
> > >
> > > Alex,
> > > In the mean time, try with libxml2 paarser.
> > > Samisa...
> > >
> > >
> > > Samisa Abeysinghe wrote:
> > >
> > > Samisa Abeysinghe wrote:
> > >
> > >
> > > Alex Bolgarov wrote:
> > >
> > > On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe
> > > <samisa@wso2.com <ma...@wso2.com>> wrote:
> > >
> > > In the mean time, please send the valgrind log.
> > >
> > >
> > > I did send the valgrind log to the list
> > >
> > >
> > > Sorry, I missed it (was a bit sleepy at the time I replied
> > > ;) )
> > >
> > > Looking at the log, it is a newly introduced one, with
> > > Guththila parser. I remember Lahuri mentioning about this
> > > leak once, and I was under the impression that this was
> > > fixed. Anyway I will have a look.
> > >
> > >
> > > I had a more detailed look into the code and there are some
> > > leaks to be fixed. I am curretly at ApacheCon and do not have
> > > access to a Linux box, and would only have time to fix this
> > > next week. Can someone please look into this in the mean time.
> > >
> > > Thanks,
> > > Samisa...
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > <ma...@ws.apache.org>
> > > For additional commands, e-mail:
> > > axis-c-user-help@ws.apache.org
> > > <ma...@ws.apache.org>
> > >
> > >
> > >
> > >
> > >
> > > -- Samisa Abeysinghe Software Architect; WSO2 Inc.
> > >
> > > http://www.wso2.com/ - "Oxygenating the Web Service Platform."
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > <ma...@ws.apache.org>
> > > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > > <ma...@ws.apache.org>
> > >
> > >
> > >
> > >
> > > --
> > > http://inf-dimensions.blogspot.com "Infinite Dimensions"
> > > http://wsaxc.blogspot.com "Web Services With Axis2/C"
> > >
> > > ------------------------------------------------------------------------
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > >
> > > ------------------------------------------------------------------------
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.11/1368 -
> > > Release Date: 4/9/2008 4:20 PM
> > >
> >
> >
> > --
> > Samisa Abeysinghe Director, Engineering; WSO2 Inc.
> >
> > http://www.wso2.com/ - "The Open Source SOA Company"
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> >
> >
>
>
> --
> http://inf-dimensions.blogspot.com "Infinite Dimensions"
> http://wsaxc.blogspot.com "Web Services With Axis2/C"
>
--
http://nethu.org/
Re: Memory leak in mod_axis2?
Posted by Milinda Pathirage <mi...@gmail.com>.
Hi,
I think the hack samisa proposed earlier is not working, because we didn't
include any header files specific to guththila inside axiom code which
related to om_stax_builder.c. If we include it in axiom_xml_reader.h, it
worked well. But this hack is not acceptable due to it parser specific code
inside axiom code (other than wrappers). Is there any specific '#define' for
libxml. If we have one we can change the current code to check whether
libxml is enabled, or we can simple define AXIS2_ENABLE_GUTHTHILA at
configuration.
Other than the comment handling, there are many places in om_stax_builder.c
which we have use AXIS2_GUTHTHILA_ENABLED. I think we must fix this before
1.3.1 release.
Please feel free to comment in this.
Thanks
Milinda.
On Fri, Apr 11, 2008 at 10:44 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
>
> Milinda Pathirage wrote:
>
> > Hi Alex and Samisa,
> >
> > This bug was caused by recent change of default parser. In the
> > om_stax_builder.c, we previously check whether guththila is enabled and free
> > the comment vlaue when we encounter a comment. Now guththila is default we
> > don have AXIS2_GUTHTHILA_ENABLED defined at the compile time.
> >
>
> hmm, Good point. The whole trouble is because of a design flow, how come a
> parser specific thing came to a parser independent logic? :)
>
> As an immediat efix, we can define AXIS2_GUTHTHILA_ENABLED in some
> Guththila header. However that is a hack, and not a neat fix. In the long
> run, we need to find why we have to treat comments form different parsers
> differently and fix that issue.
>
> Please raise a Jira on this.
>
> Thanks,
> Samisa...
>
>
> > #ifdef AXIS2_GUTHTHILA_ENABLED*/
> >
> > AXIS2_FREE(env->allocator,comment_value);
> >
> > #else
> >
> > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> >
> > #endif
> >
> > I changed the above lines to following
> >
> > /*#ifdef AXIS2_GUTHTHILA_ENABLED*/
> >
> > AXIS2_FREE(env->allocator,comment_value);
> >
> > /*#else*/
> > #ifdef AXIS2_LIBXML_ENABLED
> > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> >
> > #endif
> >
> > and now definitely lost: 690 bytes in 46 blocks.
> >
> > I have attached the valgrind log. I don't know the correct way to handle
> > LIBXML enabling. Please can some one change the
> > 'axiom_stax_builder_create_om_comment' function in om_stax_builder.c file to
> > reflect recent changes in default parser.
> >
> > Thanks
> > Milinda
> >
> >
> > On Thu, Apr 10, 2008 at 6:01 PM, Samisa Abeysinghe <samisa@wso2.com<mailto:
> > samisa@wso2.com>> wrote:
> >
> > Alex,
> > In the mean time, try with libxml2 paarser.
> > Samisa...
> >
> >
> > Samisa Abeysinghe wrote:
> >
> > Samisa Abeysinghe wrote:
> >
> >
> > Alex Bolgarov wrote:
> >
> > On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe
> > <samisa@wso2.com <ma...@wso2.com>> wrote:
> >
> > In the mean time, please send the valgrind log.
> >
> >
> > I did send the valgrind log to the list
> >
> >
> > Sorry, I missed it (was a bit sleepy at the time I replied
> > ;) )
> >
> > Looking at the log, it is a newly introduced one, with
> > Guththila parser. I remember Lahuri mentioning about this
> > leak once, and I was under the impression that this was
> > fixed. Anyway I will have a look.
> >
> >
> > I had a more detailed look into the code and there are some
> > leaks to be fixed. I am curretly at ApacheCon and do not have
> > access to a Linux box, and would only have time to fix this
> > next week. Can someone please look into this in the mean time.
> >
> > Thanks,
> > Samisa...
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail:
> > axis-c-user-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> >
> > -- Samisa Abeysinghe Software Architect; WSO2 Inc.
> >
> > http://www.wso2.com/ - "Oxygenating the Web Service Platform."
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> > --
> > http://inf-dimensions.blogspot.com "Infinite Dimensions"
> > http://wsaxc.blogspot.com "Web Services With Axis2/C"
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > ------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.11/1368 -
> > Release Date: 4/9/2008 4:20 PM
> >
>
>
> --
> Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>
> http://www.wso2.com/ - "The Open Source SOA Company"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
--
http://inf-dimensions.blogspot.com "Infinite Dimensions"
http://wsaxc.blogspot.com "Web Services With Axis2/C"
Re: Memory leak in mod_axis2?
Posted by Milinda Pathirage <mi...@gmail.com>.
Hi,
I think the hack samisa proposed earlier is not working, because we didn't
include any header files specific to guththila inside axiom code which
related to om_stax_builder.c. If we include it in axiom_xml_reader.h, it
worked well. But this hack is not acceptable due to it parser specific code
inside axiom code (other than wrappers). Is there any specific '#define' for
libxml. If we have one we can change the current code to check whether
libxml is enabled, or we can simple define AXIS2_ENABLE_GUTHTHILA at
configuration.
Other than the comment handling, there are many places in om_stax_builder.c
which we have use AXIS2_GUTHTHILA_ENABLED. I think we must fix this before
1.3.1 release.
Please feel free to comment in this.
Thanks
Milinda.
On Fri, Apr 11, 2008 at 10:44 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
>
> Milinda Pathirage wrote:
>
> > Hi Alex and Samisa,
> >
> > This bug was caused by recent change of default parser. In the
> > om_stax_builder.c, we previously check whether guththila is enabled and free
> > the comment vlaue when we encounter a comment. Now guththila is default we
> > don have AXIS2_GUTHTHILA_ENABLED defined at the compile time.
> >
>
> hmm, Good point. The whole trouble is because of a design flow, how come a
> parser specific thing came to a parser independent logic? :)
>
> As an immediat efix, we can define AXIS2_GUTHTHILA_ENABLED in some
> Guththila header. However that is a hack, and not a neat fix. In the long
> run, we need to find why we have to treat comments form different parsers
> differently and fix that issue.
>
> Please raise a Jira on this.
>
> Thanks,
> Samisa...
>
>
> > #ifdef AXIS2_GUTHTHILA_ENABLED*/
> >
> > AXIS2_FREE(env->allocator,comment_value);
> >
> > #else
> >
> > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> >
> > #endif
> >
> > I changed the above lines to following
> >
> > /*#ifdef AXIS2_GUTHTHILA_ENABLED*/
> >
> > AXIS2_FREE(env->allocator,comment_value);
> >
> > /*#else*/
> > #ifdef AXIS2_LIBXML_ENABLED
> > axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
> >
> > #endif
> >
> > and now definitely lost: 690 bytes in 46 blocks.
> >
> > I have attached the valgrind log. I don't know the correct way to handle
> > LIBXML enabling. Please can some one change the
> > 'axiom_stax_builder_create_om_comment' function in om_stax_builder.c file to
> > reflect recent changes in default parser.
> >
> > Thanks
> > Milinda
> >
> >
> > On Thu, Apr 10, 2008 at 6:01 PM, Samisa Abeysinghe <samisa@wso2.com<mailto:
> > samisa@wso2.com>> wrote:
> >
> > Alex,
> > In the mean time, try with libxml2 paarser.
> > Samisa...
> >
> >
> > Samisa Abeysinghe wrote:
> >
> > Samisa Abeysinghe wrote:
> >
> >
> > Alex Bolgarov wrote:
> >
> > On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe
> > <samisa@wso2.com <ma...@wso2.com>> wrote:
> >
> > In the mean time, please send the valgrind log.
> >
> >
> > I did send the valgrind log to the list
> >
> >
> > Sorry, I missed it (was a bit sleepy at the time I replied
> > ;) )
> >
> > Looking at the log, it is a newly introduced one, with
> > Guththila parser. I remember Lahuri mentioning about this
> > leak once, and I was under the impression that this was
> > fixed. Anyway I will have a look.
> >
> >
> > I had a more detailed look into the code and there are some
> > leaks to be fixed. I am curretly at ApacheCon and do not have
> > access to a Linux box, and would only have time to fix this
> > next week. Can someone please look into this in the mean time.
> >
> > Thanks,
> > Samisa...
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail:
> > axis-c-user-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> >
> > -- Samisa Abeysinghe Software Architect; WSO2 Inc.
> >
> > http://www.wso2.com/ - "Oxygenating the Web Service Platform."
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > <ma...@ws.apache.org>
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > <ma...@ws.apache.org>
> >
> >
> >
> >
> > --
> > http://inf-dimensions.blogspot.com "Infinite Dimensions"
> > http://wsaxc.blogspot.com "Web Services With Axis2/C"
> > ------------------------------------------------------------------------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > ------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.11/1368 -
> > Release Date: 4/9/2008 4:20 PM
> >
>
>
> --
> Samisa Abeysinghe Director, Engineering; WSO2 Inc.
>
> http://www.wso2.com/ - "The Open Source SOA Company"
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
--
http://inf-dimensions.blogspot.com "Infinite Dimensions"
http://wsaxc.blogspot.com "Web Services With Axis2/C"
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Milinda Pathirage wrote:
> Hi Alex and Samisa,
>
> This bug was caused by recent change of default parser. In the
> om_stax_builder.c, we previously check whether guththila is enabled
> and free the comment vlaue when we encounter a comment. Now guththila
> is default we don have AXIS2_GUTHTHILA_ENABLED defined at the compile
> time.
hmm, Good point. The whole trouble is because of a design flow, how come
a parser specific thing came to a parser independent logic? :)
As an immediat efix, we can define AXIS2_GUTHTHILA_ENABLED in some
Guththila header. However that is a hack, and not a neat fix. In the
long run, we need to find why we have to treat comments form different
parsers differently and fix that issue.
Please raise a Jira on this.
Thanks,
Samisa...
>
> #ifdef AXIS2_GUTHTHILA_ENABLED*/
>
> AXIS2_FREE(env->allocator,comment_value);
>
> #else
>
> axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
>
> #endif
>
> I changed the above lines to following
>
> /*#ifdef AXIS2_GUTHTHILA_ENABLED*/
>
> AXIS2_FREE(env->allocator,comment_value);
>
> /*#else*/
> #ifdef AXIS2_LIBXML_ENABLED
> axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
>
> #endif
>
> and now definitely lost: 690 bytes in 46 blocks.
>
> I have attached the valgrind log. I don't know the correct way to
> handle LIBXML enabling. Please can some one change the
> 'axiom_stax_builder_create_om_comment' function in om_stax_builder.c
> file to reflect recent changes in default parser.
>
> Thanks
> Milinda
>
>
> On Thu, Apr 10, 2008 at 6:01 PM, Samisa Abeysinghe <samisa@wso2.com
> <ma...@wso2.com>> wrote:
>
> Alex,
> In the mean time, try with libxml2 paarser.
> Samisa...
>
>
> Samisa Abeysinghe wrote:
>
> Samisa Abeysinghe wrote:
>
>
> Alex Bolgarov wrote:
>
> On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe
> <samisa@wso2.com <ma...@wso2.com>> wrote:
>
>
> In the mean time, please send the valgrind log.
>
>
>
> I did send the valgrind log to the list
>
>
> Sorry, I missed it (was a bit sleepy at the time I replied
> ;) )
>
> Looking at the log, it is a newly introduced one, with
> Guththila parser. I remember Lahuri mentioning about this
> leak once, and I was under the impression that this was
> fixed. Anyway I will have a look.
>
>
> I had a more detailed look into the code and there are some
> leaks to be fixed. I am curretly at ApacheCon and do not have
> access to a Linux box, and would only have time to fix this
> next week. Can someone please look into this in the mean time.
>
> Thanks,
> Samisa...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail:
> axis-c-user-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
> --
> Samisa Abeysinghe Software Architect; WSO2 Inc.
>
> http://www.wso2.com/ - "Oxygenating the Web Service Platform."
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
> --
> http://inf-dimensions.blogspot.com "Infinite Dimensions"
> http://wsaxc.blogspot.com "Web Services With Axis2/C"
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.11/1368 - Release Date: 4/9/2008 4:20 PM
--
Samisa Abeysinghe
Director, Engineering; WSO2 Inc.
http://www.wso2.com/ - "The Open Source SOA Company"
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Milinda Pathirage <mi...@gmail.com>.
Hi Alex and Samisa,
This bug was caused by recent change of default parser. In the
om_stax_builder.c, we previously check whether guththila is enabled and free
the comment vlaue when we encounter a comment. Now guththila is default we
don have AXIS2_GUTHTHILA_ENABLED defined at the compile time.
#ifdef AXIS2_GUTHTHILA_ENABLED*/
AXIS2_FREE(env->allocator,comment_value);
#else
axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
#endif
I changed the above lines to following
/*#ifdef AXIS2_GUTHTHILA_ENABLED*/
AXIS2_FREE(env->allocator,comment_value);
/*#else*/
#ifdef AXIS2_LIBXML_ENABLED
axiom_xml_reader_xml_free(om_builder->parser,env,comment_value);
#endif
and now definitely lost: 690 bytes in 46 blocks.
I have attached the valgrind log. I don't know the correct way to handle
LIBXML enabling. Please can some one change the
'axiom_stax_builder_create_om_comment' function in om_stax_builder.c file to
reflect recent changes in default parser.
Thanks
Milinda
On Thu, Apr 10, 2008 at 6:01 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
> Alex,
> In the mean time, try with libxml2 paarser.
> Samisa...
>
>
> Samisa Abeysinghe wrote:
>
> > Samisa Abeysinghe wrote:
> >
> > >
> > > Alex Bolgarov wrote:
> > >
> > > > On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe <sa...@wso2.com>
> > > > wrote:
> > > >
> > > >
> > > > > In the mean time, please send the valgrind log.
> > > > >
> > > > >
> > > >
> > > > I did send the valgrind log to the list
> > > >
> > >
> > > Sorry, I missed it (was a bit sleepy at the time I replied ;) )
> > >
> > > Looking at the log, it is a newly introduced one, with Guththila
> > > parser. I remember Lahuri mentioning about this leak once, and I was under
> > > the impression that this was fixed. Anyway I will have a look.
> > >
> >
> > I had a more detailed look into the code and there are some leaks to be
> > fixed. I am curretly at ApacheCon and do not have access to a Linux box, and
> > would only have time to fix this next week. Can someone please look into
> > this in the mean time.
> >
> > Thanks,
> > Samisa...
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> >
> >
> >
> >
>
> --
> Samisa Abeysinghe Software Architect; WSO2 Inc.
>
> http://www.wso2.com/ - "Oxygenating the Web Service Platform."
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
--
http://inf-dimensions.blogspot.com "Infinite Dimensions"
http://wsaxc.blogspot.com "Web Services With Axis2/C"
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Alex,
In the mean time, try with libxml2 paarser.
Samisa...
Samisa Abeysinghe wrote:
> Samisa Abeysinghe wrote:
>>
>> Alex Bolgarov wrote:
>>> On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe <sa...@wso2.com>
>>> wrote:
>>>
>>>> In the mean time, please send the valgrind log.
>>>>
>>>
>>> I did send the valgrind log to the list
>>
>> Sorry, I missed it (was a bit sleepy at the time I replied ;) )
>>
>> Looking at the log, it is a newly introduced one, with Guththila
>> parser. I remember Lahuri mentioning about this leak once, and I was
>> under the impression that this was fixed. Anyway I will have a look.
>
> I had a more detailed look into the code and there are some leaks to
> be fixed. I am curretly at ApacheCon and do not have access to a Linux
> box, and would only have time to fix this next week. Can someone
> please look into this in the mean time.
>
> Thanks,
> Samisa...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
>
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Samisa Abeysinghe wrote:
>
> Alex Bolgarov wrote:
>> On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe <sa...@wso2.com>
>> wrote:
>>
>>> In the mean time, please send the valgrind log.
>>>
>>
>> I did send the valgrind log to the list
>
> Sorry, I missed it (was a bit sleepy at the time I replied ;) )
>
> Looking at the log, it is a newly introduced one, with Guththila
> parser. I remember Lahuri mentioning about this leak once, and I was
> under the impression that this was fixed. Anyway I will have a look.
I had a more detailed look into the code and there are some leaks to be
fixed. I am curretly at ApacheCon and do not have access to a Linux box,
and would only have time to fix this next week. Can someone please look
into this in the mean time.
Thanks,
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Alex Bolgarov wrote:
> On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
>
>> In the mean time, please send the valgrind log.
>>
>
> I did send the valgrind log to the list
Sorry, I missed it (was a bit sleepy at the time I replied ;) )
Looking at the log, it is a newly introduced one, with Guththila parser.
I remember Lahuri mentioning about this leak once, and I was under the
impression that this was fixed. Anyway I will have a look.
Samisa...
> :) - you can even see it in
> the marc.info archive, at the bottom of the message:
>
> http://marc.info/?l=axis-c-user&m=120776918704827
>
> Or here is the link from the marc.info to download it as a text file:
>
> http://marc.info/?l=axis-c-user&m=120776918704827&q=p3
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
>
>
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Alex Bolgarov <al...@bolgarov.org>.
On Wed, Apr 9, 2008 at 3:36 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
> In the mean time, please send the valgrind log.
I did send the valgrind log to the list :) - you can even see it in
the marc.info archive, at the bottom of the message:
http://marc.info/?l=axis-c-user&m=120776918704827
Or here is the link from the marc.info to download it as a text file:
http://marc.info/?l=axis-c-user&m=120776918704827&q=p3
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Alex Bolgarov wrote:
> Samisa, thank you; I checked out the SVN trunk version, build it and
> run the test again.
>
> On the server side (mod_axis2) there is no more memory leaks: I run
> the test with 100000 iterations, it took 4 minutes, httpd process
> memory usage is stable and is not increasing.
>
> But now there is a memory leak on the client side. I noticed that my
> modified echo client (I modified the sample code to run the requests
> in a loop) increases the memory usage all the time.
>
> Then I compiled the original, unmodified echo.c sample from the
> samples/client/echo directory, and run it through the valgrind. I'm
> attaching the valgrind's log file; in a hope that this will help to
> fix this. According to the valgrind log, there is a 6K bytes that
> valgrind decided are 'definitely lost'.
>
I did not run valgrind recently on my machine, however, in 1.2, it used
to hit 0. May be there is a new leak added due to changes. I am right
now on Windows, and would check this when I get a chance. In the mean
time, please send the valgrind log.
Samisa...
>
>
> Thank you,
>
> alex.
>
>
> On Tue, Apr 8, 2008 at 9:21 AM, Samisa Abeysinghe <sa...@wso2.com> wrote:
>
>> Local pools have been integrated to mod_axis2 in Axis2/C trunk.
>>
>> You may run the tests again and see the improved memory footprint.
>>
>> Samisa...
>>
>>
>>
>> Samisa Abeysinghe wrote:
>>
>>
>>> Alex Bolgarov wrote:
>>>
>>>
>>>> On Mon, Mar 31, 2008 at 11:17 PM, Uthaiyashankar <sh...@wso2.com>
>>>>
>> wrote:
>>
>>>>
>>>>> I doubt whether it is a memory leak. When using mod_axis2, memory
>>>>> management is done by apache apr. Memory is released only when pools
>>>>>
>> are
>>
>>>>> destroyed. Memory will not be released when calling AXIS2_FREE.
>>>>> (axis2_module_free is implemented in mod_axis2.c:412 and it is an
>>>>>
>> empty
>>
>>>>> method unless the pool associated with is global shared pool).
>>>>>
>>>>>
>>>>>
>>>> Well, we can of course discuss the meaning of a term 'memory leak',
>>>> but what happens here is awfully close to any sensible definition :)
>>>>
>>>> Thank you for pointing out that the mod_axis2 does not really release
>>>> memory by design.
>>>>
>>>>
>>> What we are using is APR model of pools. So you cannot say that we are not
>>>
>> releasing memory by design. We are depending on APR pools to release memory
>> by design.
>>
>>> We have looked deep into this issue in the past, and proven that the
>>>
>> request pool is reclaimed by main pool upon request completion.
>>
>>>
>>>> How do you think what happens if I change the
>>>> allocator used by mod_axis2 to use malloc()/free(), not the APR's
>>>> apr_pool_...() functions? Will the memory leak go away?.. Actually,
>>>> this is exactly what I'm going to do. I have some experience in
>>>> developing Apache httpd modules, and I write them in C++ and freely
>>>> use new/delete operators, so I know that using a memory allocator
>>>> other then APR's pool functions in the httpd process is OK.
>>>>
>>>>
>>> If you go and discuss this with httpd or apr list, they will sure tell you
>>>
>> that this is the wrong way to do that.
>>
>>> There are better ways of doing this, like using using local pools, which
>>>
>> we are going to implement soon.
>>
>>> Samisa...
>>>
>>>
>>>
>>>> I will
>>>> report my findings here, hopefully in a couple of days.
>>>>
>>>>
>>>> Thank you,
>>>>
>>>> alex.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> --
>> Samisa Abeysinghe Software Architect; WSO2 Inc.
>>
>> http://www.wso2.com/ - "Oxygenating the Web Service Platform."
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>> ------------------------------------------------------------------------
>>
>> No virus found in this incoming message.
>> Checked by AVG.
>> Version: 7.5.519 / Virus Database: 269.22.10/1366 - Release Date: 4/8/2008 5:03 PM
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Alex Bolgarov wrote:
> Samisa, thank you; I checked out the SVN trunk version, build it and
> run the test again.
>
> On the server side (mod_axis2) there is no more memory leaks: I run
> the test with 100000 iterations, it took 4 minutes, httpd process
> memory usage is stable and is not increasing.
>
> But now there is a memory leak on the client side. I noticed that my
> modified echo client (I modified the sample code to run the requests
> in a loop) increases the memory usage all the time.
>
> Then I compiled the original, unmodified echo.c sample from the
> samples/client/echo directory, and run it through the valgrind. I'm
> attaching the valgrind's log file; in a hope that this will help to
> fix this. According to the valgrind log, there is a 6K bytes that
> valgrind decided are 'definitely lost'.
>
All these leaks are now fixed in the latest 1.3.1 release artifacts.
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Alex Bolgarov <al...@bolgarov.org>.
Samisa, thank you; I checked out the SVN trunk version, build it and
run the test again.
On the server side (mod_axis2) there is no more memory leaks: I run
the test with 100000 iterations, it took 4 minutes, httpd process
memory usage is stable and is not increasing.
But now there is a memory leak on the client side. I noticed that my
modified echo client (I modified the sample code to run the requests
in a loop) increases the memory usage all the time.
Then I compiled the original, unmodified echo.c sample from the
samples/client/echo directory, and run it through the valgrind. I'm
attaching the valgrind's log file; in a hope that this will help to
fix this. According to the valgrind log, there is a 6K bytes that
valgrind decided are 'definitely lost'.
Thank you,
alex.
On Tue, Apr 8, 2008 at 9:21 AM, Samisa Abeysinghe <sa...@wso2.com> wrote:
> Local pools have been integrated to mod_axis2 in Axis2/C trunk.
>
> You may run the tests again and see the improved memory footprint.
>
> Samisa...
>
>
>
> Samisa Abeysinghe wrote:
>
> > Alex Bolgarov wrote:
> >
> > > On Mon, Mar 31, 2008 at 11:17 PM, Uthaiyashankar <sh...@wso2.com>
> wrote:
> > >
> > >
> > > > I doubt whether it is a memory leak. When using mod_axis2, memory
> > > > management is done by apache apr. Memory is released only when pools
> are
> > > > destroyed. Memory will not be released when calling AXIS2_FREE.
> > > > (axis2_module_free is implemented in mod_axis2.c:412 and it is an
> empty
> > > > method unless the pool associated with is global shared pool).
> > > >
> > > >
> > >
> > > Well, we can of course discuss the meaning of a term 'memory leak',
> > > but what happens here is awfully close to any sensible definition :)
> > >
> > > Thank you for pointing out that the mod_axis2 does not really release
> > > memory by design.
> > >
> >
> > What we are using is APR model of pools. So you cannot say that we are not
> releasing memory by design. We are depending on APR pools to release memory
> by design.
> > We have looked deep into this issue in the past, and proven that the
> request pool is reclaimed by main pool upon request completion.
> >
> >
> > > How do you think what happens if I change the
> > > allocator used by mod_axis2 to use malloc()/free(), not the APR's
> > > apr_pool_...() functions? Will the memory leak go away?.. Actually,
> > > this is exactly what I'm going to do. I have some experience in
> > > developing Apache httpd modules, and I write them in C++ and freely
> > > use new/delete operators, so I know that using a memory allocator
> > > other then APR's pool functions in the httpd process is OK.
> > >
> >
> > If you go and discuss this with httpd or apr list, they will sure tell you
> that this is the wrong way to do that.
> >
> > There are better ways of doing this, like using using local pools, which
> we are going to implement soon.
> >
> > Samisa...
> >
> >
> > > I will
> > > report my findings here, hopefully in a couple of days.
> > >
> > >
> > > Thank you,
> > >
> > > alex.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
> --
> Samisa Abeysinghe Software Architect; WSO2 Inc.
>
> http://www.wso2.com/ - "Oxygenating the Web Service Platform."
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Local pools have been integrated to mod_axis2 in Axis2/C trunk.
You may run the tests again and see the improved memory footprint.
Samisa...
Samisa Abeysinghe wrote:
> Alex Bolgarov wrote:
>> On Mon, Mar 31, 2008 at 11:17 PM, Uthaiyashankar <sh...@wso2.com>
>> wrote:
>>
>>> I doubt whether it is a memory leak. When using mod_axis2, memory
>>> management is done by apache apr. Memory is released only when
>>> pools are
>>> destroyed. Memory will not be released when calling AXIS2_FREE.
>>> (axis2_module_free is implemented in mod_axis2.c:412 and it is an
>>> empty
>>> method unless the pool associated with is global shared pool).
>>>
>>
>> Well, we can of course discuss the meaning of a term 'memory leak',
>> but what happens here is awfully close to any sensible definition :)
>>
>> Thank you for pointing out that the mod_axis2 does not really release
>> memory by design.
>
> What we are using is APR model of pools. So you cannot say that we are
> not releasing memory by design. We are depending on APR pools to
> release memory by design.
> We have looked deep into this issue in the past, and proven that the
> request pool is reclaimed by main pool upon request completion.
>
>> How do you think what happens if I change the
>> allocator used by mod_axis2 to use malloc()/free(), not the APR's
>> apr_pool_...() functions? Will the memory leak go away?.. Actually,
>> this is exactly what I'm going to do. I have some experience in
>> developing Apache httpd modules, and I write them in C++ and freely
>> use new/delete operators, so I know that using a memory allocator
>> other then APR's pool functions in the httpd process is OK.
>
> If you go and discuss this with httpd or apr list, they will sure tell
> you that this is the wrong way to do that.
>
> There are better ways of doing this, like using using local pools,
> which we are going to implement soon.
>
> Samisa...
>
>> I will
>> report my findings here, hopefully in a couple of days.
>>
>>
>> Thank you,
>>
>> alex.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>>
>>
>>
>>
>
>
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Alex Bolgarov wrote:
> On Mon, Mar 31, 2008 at 11:17 PM, Uthaiyashankar <sh...@wso2.com> wrote:
>
>> I doubt whether it is a memory leak. When using mod_axis2, memory
>> management is done by apache apr. Memory is released only when pools are
>> destroyed. Memory will not be released when calling AXIS2_FREE.
>> (axis2_module_free is implemented in mod_axis2.c:412 and it is an empty
>> method unless the pool associated with is global shared pool).
>>
>
> Well, we can of course discuss the meaning of a term 'memory leak',
> but what happens here is awfully close to any sensible definition :)
>
> Thank you for pointing out that the mod_axis2 does not really release
> memory by design.
What we are using is APR model of pools. So you cannot say that we are
not releasing memory by design. We are depending on APR pools to release
memory by design.
We have looked deep into this issue in the past, and proven that the
request pool is reclaimed by main pool upon request completion.
> How do you think what happens if I change the
> allocator used by mod_axis2 to use malloc()/free(), not the APR's
> apr_pool_...() functions? Will the memory leak go away?.. Actually,
> this is exactly what I'm going to do. I have some experience in
> developing Apache httpd modules, and I write them in C++ and freely
> use new/delete operators, so I know that using a memory allocator
> other then APR's pool functions in the httpd process is OK.
If you go and discuss this with httpd or apr list, they will sure tell
you that this is the wrong way to do that.
There are better ways of doing this, like using using local pools, which
we are going to implement soon.
Samisa...
> I will
> report my findings here, hopefully in a couple of days.
>
>
> Thank you,
>
> alex.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
>
>
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Manjula Peiris <ma...@wso2.com>.
But If you are going to use this on a production environment it is
better to use apr_pools. Because malloc() allocates memory from OS but
with apr_pools it is from the pool. so as performance wise it is better.
-Manjula.
On Tue, 2008-04-01 at 20:10 -0800, Supun Kamburugamuva wrote:
> Hi Alex,
>
> Since we don't have memory leaks with simple http server, using
> malloc()/free() will solve your problem.
>
> Regards,
> Supun..
>
> On Tue, Apr 1, 2008 at 6:15 AM, Alex Bolgarov <al...@bolgarov.org> wrote:
> > On Mon, Mar 31, 2008 at 11:17 PM, Uthaiyashankar <sh...@wso2.com> wrote:
> > >
> > > I doubt whether it is a memory leak. When using mod_axis2, memory
> > > management is done by apache apr. Memory is released only when pools are
> > > destroyed. Memory will not be released when calling AXIS2_FREE.
> > > (axis2_module_free is implemented in mod_axis2.c:412 and it is an empty
> > > method unless the pool associated with is global shared pool).
> >
> > Well, we can of course discuss the meaning of a term 'memory leak',
> > but what happens here is awfully close to any sensible definition :)
> >
> > Thank you for pointing out that the mod_axis2 does not really release
> > memory by design. How do you think what happens if I change the
> > allocator used by mod_axis2 to use malloc()/free(), not the APR's
> > apr_pool_...() functions? Will the memory leak go away?.. Actually,
> > this is exactly what I'm going to do. I have some experience in
> > developing Apache httpd modules, and I write them in C++ and freely
> > use new/delete operators, so I know that using a memory allocator
> > other then APR's pool functions in the httpd process is OK. I will
> > report my findings here, hopefully in a couple of days.
> >
> >
> >
> >
> > Thank you,
> >
> > alex.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-c-user-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Supun Kamburugamuva <su...@gmail.com>.
Hi Alex,
Since we don't have memory leaks with simple http server, using
malloc()/free() will solve your problem.
Regards,
Supun..
On Tue, Apr 1, 2008 at 6:15 AM, Alex Bolgarov <al...@bolgarov.org> wrote:
> On Mon, Mar 31, 2008 at 11:17 PM, Uthaiyashankar <sh...@wso2.com> wrote:
> >
> > I doubt whether it is a memory leak. When using mod_axis2, memory
> > management is done by apache apr. Memory is released only when pools are
> > destroyed. Memory will not be released when calling AXIS2_FREE.
> > (axis2_module_free is implemented in mod_axis2.c:412 and it is an empty
> > method unless the pool associated with is global shared pool).
>
> Well, we can of course discuss the meaning of a term 'memory leak',
> but what happens here is awfully close to any sensible definition :)
>
> Thank you for pointing out that the mod_axis2 does not really release
> memory by design. How do you think what happens if I change the
> allocator used by mod_axis2 to use malloc()/free(), not the APR's
> apr_pool_...() functions? Will the memory leak go away?.. Actually,
> this is exactly what I'm going to do. I have some experience in
> developing Apache httpd modules, and I write them in C++ and freely
> use new/delete operators, so I know that using a memory allocator
> other then APR's pool functions in the httpd process is OK. I will
> report my findings here, hopefully in a couple of days.
>
>
>
>
> Thank you,
>
> alex.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Alex Bolgarov <al...@bolgarov.org>.
On Mon, Mar 31, 2008 at 11:17 PM, Uthaiyashankar <sh...@wso2.com> wrote:
>
> I doubt whether it is a memory leak. When using mod_axis2, memory
> management is done by apache apr. Memory is released only when pools are
> destroyed. Memory will not be released when calling AXIS2_FREE.
> (axis2_module_free is implemented in mod_axis2.c:412 and it is an empty
> method unless the pool associated with is global shared pool).
Well, we can of course discuss the meaning of a term 'memory leak',
but what happens here is awfully close to any sensible definition :)
Thank you for pointing out that the mod_axis2 does not really release
memory by design. How do you think what happens if I change the
allocator used by mod_axis2 to use malloc()/free(), not the APR's
apr_pool_...() functions? Will the memory leak go away?.. Actually,
this is exactly what I'm going to do. I have some experience in
developing Apache httpd modules, and I write them in C++ and freely
use new/delete operators, so I know that using a memory allocator
other then APR's pool functions in the httpd process is OK. I will
report my findings here, hopefully in a couple of days.
Thank you,
alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Uthaiyashankar <sh...@wso2.com>.
>
> No, MaxRequstsPerClient is set to 0, and yes, I understand that I can
> use this to kill old children processes with accumulated memory leaks
> and start new fresh ones, but you know, using MaxRequestPerClient is
> kind of cheating :) - there should not be memory leaks in the
> mod_axis2 in the first place...
>
I doubt whether it is a memory leak. When using mod_axis2, memory
management is done by apache apr. Memory is released only when pools are
destroyed. Memory will not be released when calling AXIS2_FREE.
(axis2_module_free is implemented in mod_axis2.c:412 and it is an empty
method unless the pool associated with is global shared pool).
When to destroy a pool is in the control of apache. MaxRequestPerClient
is a cheating way to force apache to release the pool :)
Regards,
Shankar
>
> Thank you,
>
> alex.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Alex Bolgarov wrote:
> On Sat, Mar 29, 2008 at 10:48 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
>
>> Alex Bolgarov wrote:
>> > Hi again.
>> >
>> > I've just run the echo service sample within the Apache2 httpd server
>> > (with the mod_axis2 module), I used the echo client but put the
>> > send-receive into the loop with 1,000,000 iterations.
>> >
>> > What I observed, was constant increasing of the memory (both resident
>> > and virtual, as the 'top' command shows) in the httpd process: approx.
>> > 1 megabyte every 5 sec. After 20 min. all physical memory on my
>> > computer was used, and it started hitting the swap, so I terminated
>> > the test.
>> >
>> > What is interesting though, when I run the same echo service with a
>> > standalone Axis2/server (axis2_http_server application), there was no
>> > increase of the memory usage by it - the whole 40 min. the test was
>> > running, the memory usage was stable, and the whole 1 million requests
>> > were successful.
>> >
>> > Should we made a conclusion from this that there is a memory leak, and
>> > specifically, a memory leak in the mod_axis2 code?
>> >
>>
>> What MPM setting did you use with httpd?
>>
>
> The MPM is 'worker' MPM; if this helps, here is call of the
> ./configure from the shell script that I use to build the Apache:
>
> ----------------------------------------
>
> CFLAGS="-O0 -g" \
> ./configure\
> "--prefix=${APACHE_PREFIX}"\
> --with-mpm=worker\
> --enable-so\
> --enable-ssl\
> --enable-info=shared\
> --enable-proxy=shared\
> --enable-proxy-connect=shared\
> --enable-proxy-ftp=shared\
> --enable-proxy-http=shared\
> --enable-proxy-ajp=shared\
> --enable-proxy-balancer=shared\
> --with-included-apr\
> --with-expat=builtin
>
> ----------------------------------------
>
>
>> Did you set MaxRequstsPerClient setting?
>>
>
> No, MaxRequstsPerClient is set to 0, and yes, I understand that I can
> use this to kill old children processes with accumulated memory leaks
> and start new fresh ones, but you know, using MaxRequestPerClient is
> kind of cheating :) - there should not be memory leaks in the
> mod_axis2 in the first place...
>
If there are leaks, can you please point to them so that we can fix them?
Samisa...
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Alex Bolgarov <al...@bolgarov.org>.
On Sat, Mar 29, 2008 at 10:48 PM, Samisa Abeysinghe <sa...@wso2.com> wrote:
> Alex Bolgarov wrote:
> > Hi again.
> >
> > I've just run the echo service sample within the Apache2 httpd server
> > (with the mod_axis2 module), I used the echo client but put the
> > send-receive into the loop with 1,000,000 iterations.
> >
> > What I observed, was constant increasing of the memory (both resident
> > and virtual, as the 'top' command shows) in the httpd process: approx.
> > 1 megabyte every 5 sec. After 20 min. all physical memory on my
> > computer was used, and it started hitting the swap, so I terminated
> > the test.
> >
> > What is interesting though, when I run the same echo service with a
> > standalone Axis2/server (axis2_http_server application), there was no
> > increase of the memory usage by it - the whole 40 min. the test was
> > running, the memory usage was stable, and the whole 1 million requests
> > were successful.
> >
> > Should we made a conclusion from this that there is a memory leak, and
> > specifically, a memory leak in the mod_axis2 code?
> >
>
> What MPM setting did you use with httpd?
The MPM is 'worker' MPM; if this helps, here is call of the
./configure from the shell script that I use to build the Apache:
----------------------------------------
CFLAGS="-O0 -g" \
./configure\
"--prefix=${APACHE_PREFIX}"\
--with-mpm=worker\
--enable-so\
--enable-ssl\
--enable-info=shared\
--enable-proxy=shared\
--enable-proxy-connect=shared\
--enable-proxy-ftp=shared\
--enable-proxy-http=shared\
--enable-proxy-ajp=shared\
--enable-proxy-balancer=shared\
--with-included-apr\
--with-expat=builtin
----------------------------------------
>
> Did you set MaxRequstsPerClient setting?
No, MaxRequstsPerClient is set to 0, and yes, I understand that I can
use this to kill old children processes with accumulated memory leaks
and start new fresh ones, but you know, using MaxRequestPerClient is
kind of cheating :) - there should not be memory leaks in the
mod_axis2 in the first place...
Thank you,
alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org
Re: Memory leak in mod_axis2?
Posted by Samisa Abeysinghe <sa...@wso2.com>.
Alex Bolgarov wrote:
> Hi again.
>
> I've just run the echo service sample within the Apache2 httpd server
> (with the mod_axis2 module), I used the echo client but put the
> send-receive into the loop with 1,000,000 iterations.
>
> What I observed, was constant increasing of the memory (both resident
> and virtual, as the 'top' command shows) in the httpd process: approx.
> 1 megabyte every 5 sec. After 20 min. all phisical memory on my
> computer was used, and it started hitting the swap, so I terminated
> the test.
>
> What is interesting though, when I run the same echo service with a
> standalone Axis2/server (axis2_http_server application), there was no
> increase of the memory usage by it - the whole 40 min. the test was
> running, the memory usage was stable, and the whole 1 million requests
> were successful.
>
> Should we made a conclusion from this that there is a memory leak, and
> specifically, a memory leak in the mod_axis2 code?
>
What MPM setting did you use with httpd?
Did you set MaxRequstsPerClient setting?
Samisa...
> I'm using Ubuntu Linux 7.10, Apache httpd 2.2.4 compiled from sources.
> Yes, I know, the latest version of Apache2 is 2.2.8, so I'm going to
> download and build this version and will try with it again.
>
>
> Thank you,
>
> alex.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
>
>
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org