You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Igor Galić <i....@brainsware.org> on 2013/04/17 17:14:31 UTC
undefined reference to `apr_pool_mutex_set'
Hi folks,
I'm having issue with a piece of software (unimrcp) failing to build:
Making all in unimrcp-server
make[2]: Entering directory `/build/unimrcp/platforms/unimrcp-server'
/bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -pthread -o unimrcpserver main.o uni_cmdline.o uni_daemon.o ../../platforms/libunimrcp-server/libunimrcpserver.la
gcc -g -O2 -pthread -o .libs/unimrcpserver main.o uni_cmdline.o uni_daemon.o ../../platforms/libunimrcp-server/.libs/libunimrcpserver.so -L/usr/lib /usr/lib/libapr-1.so /usr/lib/libaprutil-1.so -lsofia-sip-ua -lm -Wl,--rpath -Wl,/usr/lib
../../platforms/libunimrcp-server/.libs/libunimrcpserver.so: undefined reference to `apr_pool_mutex_set'
collect2: ld returned 1 exit status
The reason, detailed here: https://code.google.com/p/unimrcp/issues/detail?id=78
Seems to be caused by this projects creative use of APR: https://code.google.com/p/unimrcp/issues/detail?id=29
Is there anything I can do other than compile a sepcial version of APR for this project's requirements?
So long,
-- i
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: undefined reference to `apr_pool_mutex_set'
Posted by Arsen Chaloyan <ac...@yahoo.com>.
Hi Igor,
The patched APR library has been included in the UniMRCP dependencies package for many years now. The latest version can be downloaded from the following link.
http://code.google.com/p/unimrcp/downloads/detail?name=unimrcp-deps-1.1.3.tar.gz
If you have any further question with regards to UniMRCP, I'd suggest we use the corresponding Discussion Group.
Arsen
________________________________
From: Igor Galić <i....@brainsware.org>
To: Arsen Chaloyan <ac...@yahoo.com>
Cc: Philip Martin <ph...@codematters.co.uk>; William A. Rowe Jr. <wr...@rowe-clan.net>; dev@apr.apache.org
Sent: Monday, April 22, 2013 7:48 AM
Subject: Re: undefined reference to `apr_pool_mutex_set'
Hi Arsen,
the only problem with patching APR is that someone has to maintain that patch/package now.
The incentive for package distributors is rather low to add this patch to their standard set.
What's your deployment recommendation?
-- i
________________________________
Hello Igor, William and Philip,
>
>
>As the author of the piece of software Igor was referring to, I'd add a few comments regarding the use of the APR memory pools in the UniMRCP project.
>
>
>First of all, when I just started using the APR library I had an impression that operations on memory pools are thread-safe. That was obviously my oversight. Facing this problem, I had no choice but to patch the APR memory pools, since memory allocations are done indirectly inside the APR lib at least in some places. In fact, the patch was initially borrowed from another project, FreeSWITCH, which seemed to encounter the same problem. Later, I came across similar patches in other projects too and now I'm not sure where this patch came from originally. Perhaps this doesn't really matter at this point.
>
>
>
>I personally didn't bring this up to the APR group, since the patch didn't address general use, and from what I could see, the APR maintainers seemed to be opposed adding support for thread-safe memory pools. I understand all the concerns regarding concurrent use of memory pools and don't encourage that either, but having such an option seems commonsensical to me.
>
>
>
>Now, why the patch makes perfect sense for the UniMRCP project but cannot be considered for general use. I use an event driven architecture with a fixed number of threads/tasks created upon initialization of MRCP client or server stacks. A new memory pool is created for each MRCP session. The majority of other objects created in the scope of that session are allocated from the same session pool. The pool might be concurrently used by sub-tasks/threads. Although the probability of the concurrent use is very low, it still does exist. Eventually, when the session and its associated memory pool are getting destroyed, it's guaranteed that these objects are not referenced from any other place, in other words, there are no dangling references. This routine is implemented internally, out of the APR scope. Theoretically, I could relatively easily avoid the concurrent use of memory pools by creating a sub-pool for each sub-task/thread, but this would have a clear
downside too such as memory usage (unnecessary creation of a new memory block of 4/8k for each pool).
>
>
>I'm certainly not very happy having APR patched but at the same time I realize this is something I should live with.
>
>
>http://www.unimrcp.org/dependencies/apr-1.4.6.patch
>
>
>
>Thanks for your attention!
>
>--
>Arsen Chaloyan
>Author of UniMRCP
>http://www.unimrcp.org
>
>
>
>
>
>________________________________
> From: Philip Martin <ph...@codematters.co.uk>
>To: William A. Rowe Jr. <wr...@rowe-clan.net>
>Cc: dev@apr.apache.org; i.galic@brainsware.org
>Sent: Thursday, April 18, 2013 2:57 AM
>Subject: Re: undefined reference to `apr_pool_mutex_set'
>
>
>"William A. Rowe Jr." <wr...@rowe-clan.net> writes:
>
>
>> On Wed, 17 Apr 2013 15:14:31 +0000 (UTC)
>> Igor Galić <i....@brainsware.org> wrote:
>>>
>>> caused by this projects creative use of APR:
>>> https://code.google.com/p/unimrcp/issues/detail?id=29
>>>
>>> Is there anything I can do other than compile a sepcial version of
>>> APR for this project's requirements?
>>
>> That's what happens
when projects don't push hacks upstream :(
>> Sorry we can't provide too much guidance. If there is a submitted
>> patch under the AL lying around somewhere, please flag it to the
>> dev@ list for consideration.
>
>
>The patch adds a mutex to apr_pool_t and locks the mutex in calls to
>apr_palloc, apr_pool_clear and apr_pool_destroy. That may make those
>individual calls threadsafe but it doesn't really make pool use as a
>whole threadsafe. If one thread clears a pool every other thread using
>the pool is left with dangling references. It looks like a lot of
>locking for no real gain.
>
>
>--
>Philip
>
>
>
Re: undefined reference to `apr_pool_mutex_set'
Posted by Igor Galić <i....@brainsware.org>.
Hi Arsen,
the only problem with patching APR is that someone has to maintain that patch/package now.
The incentive for package distributors is rather low to add this patch to their standard set.
What's your deployment recommendation?
-- i
----- Original Message -----
> Hello Igor, William and Philip,
> As the author of the piece of software Igor was referring to, I'd add
> a few comments regarding the use of the APR memory pools in the
> UniMRCP project.
> First of all, when I just started using the APR library I had an
> impression that operations on memory pools are thread-safe. That was
> obviously my oversight. Facing this problem, I had no choice but to
> patch the APR memory pools, since memory allocations are done
> indirectly inside the APR lib at least in some places. In fact, the
> patch was initially borrowed from another project, FreeSWITCH, which
> seemed to encounter the same problem. Later, I came across similar
> patches in other projects too and now I'm not sure where this patch
> came from originally. Perhaps this doesn't really matter at this
> point.
> I personally didn't bring this up to the APR group, since the patch
> didn't address general use, and from what I could see, the APR
> maintainers seemed to be opposed adding support for thread-safe
> memory pools. I understand all the concerns regarding concurrent use
> of memory pools and don't encourage that either, but having such an
> option seems commonsensical to me.
> Now, why the patch makes perfect sense for the UniMRCP project but
> cannot be considered for general use. I use an event driven
> architecture with a fixed number of threads/tasks created upon
> initialization of MRCP client or server stacks. A new memory pool is
> created for each MRCP session. The majority of other objects created
> in the scope of that session are allocated from the same session
> pool. The pool might be concurrently used by sub-tasks/threads.
> Although the probability of the concurrent use is very low, it still
> does exist. Eventually, when the session and its associated memory
> pool are getting destroyed, it's guaranteed that these objects are
> not referenced from any other place, in other words, there are no
> dangling references. This routine is implemented internally, out of
> the APR scope. Theoretically, I could relatively easily avoid the
> concurrent use of memory pools by creating a sub-pool for each
> sub-task/thread, but this would have a clear downside too such as
> memory usage (unnecessary creation of a new memory block of 4/8k for
> each pool).
> I'm certainly not very happy having APR patched but at the same time
> I realize this is something I should live with.
> http://www.unimrcp.org/dependencies/apr-1.4.6.patch
> Thanks for your attention!
> --
> Arsen Chaloyan
> Author of UniMRCP
> http://www.unimrcp.org
> From: Philip Martin <ph...@codematters.co.uk>
> To: William A. Rowe Jr. <wr...@rowe-clan.net>
> Cc: dev@apr.apache.org; i.galic@brainsware.org
> Sent: Thursday, April 18, 2013 2:57 AM
> Subject: Re: undefined reference to `apr_pool_mutex_set'
> "William A. Rowe Jr." < wrowe@rowe-clan.net > writes:
> > On Wed, 17 Apr 2013 15:14:31 +0000 (UTC)
> > Igor Galić < i.galic@brainsware.org > wrote:
> >>
> >> caused by this projects creative use of APR:
> >> https://code.google.com/p/unimrcp/issues/detail?id=29
> >>
> >> Is there anything I can do other than compile a sepcial version of
> >> APR for this project's requirements?
> >
> > That's what happens when projects don't push hacks upstream :(
> > Sorry we can't provide too much guidance. If there is a submitted
> > patch under the AL lying around somewhere, please flag it to the
> > dev@ list for consideration.
> The patch adds a mutex to apr_pool_t and locks the mutex in calls to
> apr_palloc, apr_pool_clear and apr_pool_destroy. That may make those
> individual calls threadsafe but it doesn't really make pool use as a
> whole threadsafe. If one thread clears a pool every other thread
> using
> the pool is left with dangling references. It looks like a lot of
> locking for no real gain.
> --
> Philip
Re: undefined reference to `apr_pool_mutex_set'
Posted by Arsen Chaloyan <ac...@yahoo.com>.
Hello Igor, William and Philip,
As the author of the piece of software Igor was referring to, I'd add a few comments regarding the use of the APR memory pools in the UniMRCP project.
First of all, when I just started using the APR library I had an impression that operations on memory pools are thread-safe. That was obviously my oversight. Facing this problem, I had no choice but to patch the APR memory pools, since memory allocations are done indirectly inside the APR lib at least in some places. In fact, the patch was initially borrowed from another project, FreeSWITCH, which seemed to encounter the same problem. Later, I came across similar patches in other projects too and now I'm not sure where this patch came from originally. Perhaps this doesn't really matter at this point.
I personally didn't bring this up to the APR group, since the patch didn't address general use, and from what I could see, the APR maintainers seemed to be opposed adding support for thread-safe memory pools. I understand all the concerns regarding concurrent use of memory pools and don't encourage that either, but having such an option seems commonsensical to me.
Now, why the patch makes perfect sense for the UniMRCP project but cannot be considered for general use. I use an event driven architecture with a fixed number of threads/tasks created upon initialization of MRCP client or server stacks. A new memory pool is created for each MRCP session. The majority of other objects created in the scope of that session are allocated from the same session pool. The pool might be concurrently used by sub-tasks/threads. Although the probability of the concurrent use is very low, it still does exist. Eventually, when the session and its associated memory pool are getting destroyed, it's guaranteed that these objects are not referenced from any other place, in other words, there are no dangling references. This routine is implemented internally, out of the APR scope. Theoretically, I could relatively easily avoid the concurrent use of memory pools by creating a sub-pool for each sub-task/thread, but this would have a clear
downside too such as memory usage (unnecessary creation of a new memory block of 4/8k for each pool).
I'm certainly not very happy having APR patched but at the same time I realize this is something I should live with.
http://www.unimrcp.org/dependencies/apr-1.4.6.patch
Thanks for your attention!
--
Arsen Chaloyan
Author of UniMRCP
http://www.unimrcp.org
________________________________
From: Philip Martin <ph...@codematters.co.uk>
To: William A. Rowe Jr. <wr...@rowe-clan.net>
Cc: dev@apr.apache.org; i.galic@brainsware.org
Sent: Thursday, April 18, 2013 2:57 AM
Subject: Re: undefined reference to `apr_pool_mutex_set'
"William A. Rowe Jr." <wr...@rowe-clan.net> writes:
> On Wed, 17 Apr 2013 15:14:31 +0000 (UTC)
> Igor Galić <i....@brainsware.org> wrote:
>>
>> caused by this projects creative use of APR:
>> https://code.google.com/p/unimrcp/issues/detail?id=29
>>
>> Is there anything I can do other than compile a sepcial version of
>> APR for this project's requirements?
>
> That's what happens when projects don't push hacks upstream :(
> Sorry we can't provide too much guidance. If there is a submitted
> patch under the AL lying around somewhere, please flag it to the
> dev@ list for consideration.
The patch adds a mutex to apr_pool_t and locks the mutex in calls to
apr_palloc, apr_pool_clear and apr_pool_destroy. That may make those
individual calls threadsafe but it doesn't really make pool use as a
whole threadsafe. If one thread clears a pool every other thread using
the pool is left with dangling references. It looks like a lot of
locking for no real gain.
--
Philip
Re: undefined reference to `apr_pool_mutex_set'
Posted by Philip Martin <ph...@codematters.co.uk>.
"William A. Rowe Jr." <wr...@rowe-clan.net> writes:
> On Wed, 17 Apr 2013 15:14:31 +0000 (UTC)
> Igor Galić <i....@brainsware.org> wrote:
>>
>> caused by this projects creative use of APR:
>> https://code.google.com/p/unimrcp/issues/detail?id=29
>>
>> Is there anything I can do other than compile a sepcial version of
>> APR for this project's requirements?
>
> That's what happens when projects don't push hacks upstream :(
> Sorry we can't provide too much guidance. If there is a submitted
> patch under the AL lying around somewhere, please flag it to the
> dev@ list for consideration.
The patch adds a mutex to apr_pool_t and locks the mutex in calls to
apr_palloc, apr_pool_clear and apr_pool_destroy. That may make those
individual calls threadsafe but it doesn't really make pool use as a
whole threadsafe. If one thread clears a pool every other thread using
the pool is left with dangling references. It looks like a lot of
locking for no real gain.
--
Philip
Re: undefined reference to `apr_pool_mutex_set'
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Wed, 17 Apr 2013 15:14:31 +0000 (UTC)
Igor Galić <i....@brainsware.org> wrote:
>
> Hi folks,
>
> I'm having issue with a piece of software (unimrcp) failing to build:
>
> Making all in unimrcp-server
> make[2]: Entering directory
> `/build/unimrcp/platforms/unimrcp-server' /bin/bash ../../libtool
> --tag=CC --mode=link gcc -g -O2 -pthread -o unimrcpserver
> main.o uni_cmdline.o
> uni_daemon.o ../../platforms/libunimrcp-server/libunimrcpserver.la
> gcc -g -O2 -pthread -o .libs/unimrcpserver main.o uni_cmdline.o
> uni_daemon.o ../../platforms/libunimrcp-server/.libs/libunimrcpserver.so
> -L/usr/lib /usr/lib/libapr-1.so /usr/lib/libaprutil-1.so
> -lsofia-sip-ua -lm -Wl,--rpath
> -Wl,/usr/lib ../../platforms/libunimrcp-server/.libs/libunimrcpserver.so:
> undefined reference to `apr_pool_mutex_set' collect2: ld returned 1
> exit status
>
>
> The reason, detailed here:
> https://code.google.com/p/unimrcp/issues/detail?id=78 Seems to be
> caused by this projects creative use of APR:
> https://code.google.com/p/unimrcp/issues/detail?id=29
>
> Is there anything I can do other than compile a sepcial version of
> APR for this project's requirements?
That's what happens when projects don't push hacks upstream :(
Sorry we can't provide too much guidance. If there is a submitted
patch under the AL lying around somewhere, please flag it to the
dev@ list for consideration.