Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of a.broekhuis@gmail.com
 designates 209.85.216.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <!&!AAAAAAAAAAAYAAAAAAAAADTwEdw/WnxCnhXxV8wjlFjigAAAEAAAAAZ0GfCSQUhEhVmgOqnobw4BAAAAAA==@student.kuleuven.be>
References: 
 <!&!AAAAAAAAAAAYAAAAAAAAADTwEdw/WnxCnhXxV8wjlFjigAAAEAAAAClBVHCiwP5NlpjZPDmbBDwBAAAAAA==@student.kuleuven.be>
	<CA+T-u8fwB2E3tV70or9Fmugw1w_Lpbq_-v8BL9j3KzJMMDGrzw@mail.gmail.com>
	<!&!AAAAAAAAAAAYAAAAAAAAADTwEdw/WnxCnhXxV8wjlFjigAAAEAAAAAZ0GfCSQUhEhVmgOqnobw4BAAAAAA==@student.kuleuven.be>
Date: Thu, 10 Apr 2014 21:08:05 +0200
Message-ID: 
 <CA+T-u8eqX-fU+xLbmRTRvGxG50zSx32ikDK+q2iZzkk6VM-AKQ@mail.gmail.com>
Subject: Re: APR memory dealocation when bundle stops
From: Alexander Broekhuis <a.broekhuis@gmail.com>
To: celix-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11c2dac0d7f9bf04f6b4ef7f

--001a11c2dac0d7f9bf04f6b4ef7f
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Thanks for the code, at first test I can't find anything strange with it.

Some more questions/thoughs
- Did you also do the same test on a x86 system? Just wondering if it might
be the cross compilations.
- If you stop a bundle, and start it again, does the memory grow? Or does
it reuse the memory and are you perhaps seeing a side-effect of the pool
where it doesn't release immediately (I am not sure on this one, and find
it difficult to debug APR in these instances, but maybe this has also to do
with the fact that I am using OSX).

Looking at the flow of the code, the context pool is created when the
bundles is started, and destroyed when the bundle is stopped.

I am not sure how long you are following the list, but a while ago I
started a discussion about the usage of APR [1]. Any thoughts on the topic
are still welcome. At this moment I feel Celix would benefit when APR was
taken out, but then again, this is quite a big job, so we didn't do
anything yet.

I'll look a bit more into it, any other ideas are welcome as well.

[1]: http://incubator.markmail.org/thread/wmyas74a3fhxorhu


2014-04-10 16:18 GMT+02:00 Thomas Quartier <
thomas.quartier@student.kuleuven.be>:

> Hi,
>
> This is my code:
>
> #include <stdlib.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <sys/time.h>
>
> #include <apr_general.h>
>
> #include "bundle_activator.h"
> #include "bundle_context.h"
> #include "service_tracker.h"
>
> #include <sys/wait.h>
> #include <sys/mman.h>
>
> struct activator_data {
>         bool running;
>         apr_pool_t *pool;
>         apr_thread_t *sender;
> };
>
> typedef struct activator_data * activator_data_pt;
>
> static void *APR_THREAD_FUNC my_thread_func(apr_thread_t *thd, void *data)
> {
>         int i = 0;
>         int j = 0;
>         activator_data_pt act = (activator_data_pt) data;
>         while (act->running) {
>                 printf("my_thread_for_1\n");
>                 j = 0;
>                 for(i = 0; i<=10000; i++){
>                         j+=rand();
>                 }
>                 printf("my_thread_for_1: for until %i\n", j);
>                 apr_sleep(1000000);
>         }
>         apr_thread_exit(thd, APR_SUCCESS);
>         return NULL;
> }
>
> celix_status_t bundleActivator_create(bundle_context_pt context, void
> **userData) {
>         apr_pool_t *pool;
>         celix_status_t status = bundleContext_getMemoryPool(context,
> &pool);
>         if (status == CELIX_SUCCESS) {
>                 *userData = apr_palloc(pool, sizeof(struct
> activator_data));
>                 ((activator_data_pt)(*userData))->running = false;
>                 ((activator_data_pt)(*userData))->pool = NULL;
>                 ((activator_data_pt)(*userData))->sender = NULL;
>         } else {
>                 status = CELIX_START_ERROR;
>         }
>         return CELIX_SUCCESS;
> }
>
> celix_status_t bundleActivator_start(void * userData, bundle_context_pt
> context) {
>         activator_data_pt act = (activator_data_pt) userData;
>         apr_pool_t *pool = NULL;
>         bundleContext_getMemoryPool(context, &pool);
>         act->pool=pool;
>         act->running=true;
>         apr_thread_create(&act->sender, NULL, my_thread_func, act,
> act->pool);
>         return CELIX_SUCCESS;
> }
>
> celix_status_t bundleActivator_stop(void * userData, bundle_context_pt
> context) {
>         apr_status_t aprStatusT = 0;
>         activator_data_pt act = (activator_data_pt) userData;
>         apr_status_t status;
>         act->running=false;
>         apr_thread_join(&status, act->sender);
>         return CELIX_SUCCESS;
> }
>
> celix_status_t bundleActivator_destroy(void * userData, bundle_context_pt
> context) {
>         activator_data_pt act = (activator_data_pt) userData;
>         act->sender = 0;
>         act = NULL;
>         return CELIX_SUCCESS;
> }
>
> Kind regards,
> Thomas
>
> -----Original Message-----
> From: Alexander Broekhuis [mailto:a.broekhuis@gmail.com]
> Sent: donderdag 10 april 2014 15:55
> To: celix-dev@incubator.apache.org
> Subject: Re: APR memory dealocation when bundle stops
>
> Hello,
>
> Could you send me an example of the code? I'll try to look into it and see
> whats going on.
>
>
> 2014-04-10 14:34 GMT+02:00 Thomas Quartier <
> thomas.quartier@student.kuleuven.be>:
>
> > Hello,
> >
> >
> >
> > I'm testing Celix for my master thesis. I've cross compiled Celix to
> > embedded Linux for an ARM at91sam9260-ek development board using
> Buildroot.
> > To test the memory footprint of Celix, I have 10 bundles that each
> > start and stop an APR thread in the bundleActivator_start and
> > bundleActivator_stop functions. I start and stop these 10 bundles one
> > by one. In the memory plot, I can see all bundles start but when
> > stopping them, memory is not deallocated. To stop a thread, I set a
> > bool to false and wait (join) for the thread to exit as in the echo
> > example. The execution of the thread and the bundle stops but memory
> > stays allocated. I also tried to use the apr_thread_exit function
> > after the join but that results in a segmentation fault.
> >
> >
> >
> >
> >
> > Kind regards,
> >
> > Thomas
> >
> >
> >
> >
> >
> >
>
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>
>


-- 
Met vriendelijke groet,

Alexander Broekhuis

--001a11c2dac0d7f9bf04f6b4ef7f--