Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 18 Sep 2013 16:29:30 +0200
From: =?UTF-8?Q?Bj=C3=B6rn_Petri?= <bjoern.petri@sundevil.de>
To: <celix-dev@incubator.apache.org>
Subject: Re: Remote service using shared mem
In-Reply-To: 
 <CA+T-u8eecxMJvwwuP=LZU9TXEkv09C3EZXtUFnOWCOfuGBs4nA@mail.gmail.com>
References: <5213C63A.1050002@gmail.com>
 <E825BCB2-EAFD-4E97-88C0-B1BB1085506A@luminis.nl>
 <52150460.7070606@gmail.com>
 <CA+T-u8e2tvMgKdj9FjQ6h5ACQFmT11k8RpvKJ-Ci64HoW9fYEw@mail.gmail.com>
 <52356979.1040002@sundevil.de>
 <CA+T-u8fOd9TbY5W2h4PYxrLJzo1-mM09c3=CbOMEQ8TLio-Rqw@mail.gmail.com>
 <03fa0772516eaaab4c1fcf59f52f00e9@imap.sundevil.de>
 <CA+T-u8cs9Bioac7NwDFf3xuggRfSgBnKORrwwLJB34y_LE6QWQ@mail.gmail.com>
 <dbdb0588141d589373b66404ce2b8ecd@imap.sundevil.de>
 <CA+T-u8ccYmz15uZd8TP3LAZGW74MCTbrUs=+Bqay=jR6pZQ=eA@mail.gmail.com>
 <5238198D.8050209@sundevil.de>
 <CA+T-u8e4s4UuDbXk=wDZkhZ7+OSo7Z22E8ROQk5hSyD9DvdxVw@mail.gmail.com>
 <CA+T-u8eecxMJvwwuP=LZU9TXEkv09C3EZXtUFnOWCOfuGBs4nA@mail.gmail.com>
Message-ID: <4f9dbca6c64a7583e34c4be4cab8eadc@imap.sundevil.de>
User-Agent: Roundcube Webmail/RCMAIL_VERSION


Hi Alexander,

Proposed changes are included and a new patch is available within 
CELIX-81. But I stumbled over another problem: when importing or 
exporting a service, the according reference is saved in a hashMaps 
within the RSA and the topology manager. But there is no functionality 
yet to remove those. This leads to a segfault (at least in the RSA_SHM) 
when issuing a (add/sub/sqrt-) command after re-starting the 
example-service. A possible solution has been already discussed with 
Pepijn and I'll try to provide an according patch within the next weeks.

Regards,
   Bjoern


Am 2013-09-17 19:50, schrieb Alexander Broekhuis:
> I did some more testing/debugging and have some changes :)
>
> 1) In remote_services/CMakeLists.txt you re-enabled the inclusion of 
> the
> utils directory.
>
> 2) The thread in Discovery and the RSA itself do not have a return 
> value,
> also the thread_exit is only called if a precondition is met, 
> otherwise the
> method just return without an exit. This can be solved by always 
> calling
> apr_thread_exit and returning NULL at the end.
>
> 3) As mentioned in the other mail, the RSA needs to be updated for
> CELIX-82. Simple fix, take a look at the other RSA for the code :).
>
> 4) When creating a thread in the RSA you add a NULL pointer to the 
> hashmap
> and only later on create an actual pointer. This results in a NULL 
> pointer
> in the hashmap and the pointer to the thread being "lost".  Simply 
> putting
> the thread pointer in the hashmap after thread creation is enough to 
> fix
> this. This one was also the reason for the segfault when the 
> framework
> stops and not the use of shmem etc.
>
> Ps: I can make those changes and add the code, but if you prefer to 
> verify
> my remarks and make a new patch I can wait a bit.
>
> Pps: The code looks good! And together with a few simple fixes Pepijn
> committed today I think not a lot of extra work is needed before 
> committing
> this.
>
>
>
>
>
> 2013/9/17 Alexander Broekhuis <a.broekhuis@gmail.com>
>
>> Hi,
>>
>> Unrelated to the previous problems, Pepijn today fixed issue 
>> CELIX-82 [1].
>> This also requires an update in the SHM code. Could you also port 
>> that
>> change to your code?
>>
>> 2013/9/17 Björn Petri <bjoern.petri@sundevil.de>
>>
>>>
>>> Hi Alexander,
>>>
>>> I already updated the issues we spoke about, so stopping the
>>> example-service does not segfault any more.
>>
>>
>> I tried a bit with the new patch, and still have a problem. I 
>> haven't
>> tested it in detail, but during the stop of the RSA something 
>> unexpected
>> happens.
>>
>> The problem reported is: celix(82209,0x10ff7a180) malloc: *** error 
>> for
>> object 0x7f9ff48dda00: pointer being freed was not allocated
>> *** set a breakpoint in malloc_error_break to debug
>>
>> A reason for such errors can be the use of pools and still freeing
>> pointers. If a pointer which is in a pool is being freed, during the 
>> apr
>> shutdown it is freed again.
>> In this case I suspect it has to do with the use of APR for some 
>> shmem
>> functions, while other parts are done using standard (low level) api 
>> calls.
>>
>>
>> [1]: https://issues.apache.org/jira/browse/CELIX-82
>>
>>
>> --
>> Met vriendelijke groet,
>>
>> Alexander Broekhuis
>>