You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Stas Bekman <st...@stason.org> on 2003/09/25 00:09:12 UTC
segfault in apr_atomic_cas
When using apr built with --enable-pool-debug=all I get this segfault on the
httpd server startup:
#0 0x4026cbe4 in apr_atomic_cas ()
from /home/stas/httpd/prefork/lib/libapr-0.so.0
(gdb) where
#0 0x4026cbe4 in apr_atomic_cas ()
from /home/stas/httpd/prefork/lib/libapr-0.so.0
#1 0x40268b2d in apr_thread_mutex_lock ()
from /home/stas/httpd/prefork/lib/libapr-0.so.0
#2 0x4026b77e in apr_pool_create_ex_debug ()
from /home/stas/httpd/prefork/lib/libapr-0.so.0
#3 0x40267685 in apr_initialize ()
from /home/stas/httpd/prefork/lib/libapr-0.so.0
#4 0x40267618 in apr_app_initialize ()
from /home/stas/httpd/prefork/lib/libapr-0.so.0
#5 0x080c6fb8 in main (argc=2, argv=0xbffff4e4) at main.c:426
#6 0x40352c57 in __libc_start_main () from /lib/i686/libc.so.6
This happens because hash_mutex[] is not initialized when apr_pool_create is
called.
The apr_atomic_init that initializes that variable is running too late:
if (apr_pool_create(&pool, NULL) != APR_SUCCESS) {
return APR_ENOPOOL;
}
apr_pool_tag(pool, "apr_initialize");
if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
return status;
}
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in apr_atomic_cas
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
[...]
> I have a dirty workaround, setting global_pool->mutex to NULL, at least
> I can do some debugging.
If anybody needs it to work now here is a dirty workaround that works for me.
notice that it disables the mutex on the global pool, so you may have problems
in the threaded environment.
Index: memory/unix/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.197
diff -u -r1.197 apr_pools.c
--- memory/unix/apr_pools.c 18 Jul 2003 23:10:04 -0000 1.197
+++ memory/unix/apr_pools.c 25 Sep 2003 07:30:01 -0000
@@ -1505,8 +1505,14 @@
{
apr_pool_t *pool;
+ if (allocator == (apr_allocator_t *)0xdeadbeaf) {
+ allocator = NULL;
+ global_pool->mutex = NULL;
+
+ }
+
*newpool = NULL;
-
+
if (!parent) {
parent = global_pool;
}
Index: misc/unix/start.c
===================================================================
RCS file: /home/cvs/apr/misc/unix/start.c,v
retrieving revision 1.70
diff -u -r1.70 start.c
--- misc/unix/start.c 6 Jan 2003 23:44:32 -0000 1.70
+++ misc/unix/start.c 25 Sep 2003 07:30:01 -0000
@@ -93,6 +93,24 @@
if ((status = apr_pool_initialize()) != APR_SUCCESS)
return status;
+#if APR_POOL_DEBUG
+ {
+ apr_pool_t *pool = NULL;
+ apr_status_t rv;
+
+ if ((rv = apr_pool_create_ex(&pool, NULL, NULL,
+ (apr_allocator_t *)0xdeadbeaf)
+ ) != APR_SUCCESS) {
+ return rv;
+ }
+
+ if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
+ return status;
+ }
+ }
+#endif
+
+
if (apr_pool_create(&pool, NULL) != APR_SUCCESS) {
return APR_ENOPOOL;
}
@@ -102,7 +120,7 @@
if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
return status;
}
-
+
apr_signal_init(pool);
return APR_SUCCESS;
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in apr_atomic_cas
Posted by Stas Bekman <st...@stason.org>.
Blair Zajac wrote:
> Stas Bekman wrote:
>
>>When using apr built with --enable-pool-debug=all I get this segfault on the
>>httpd server startup:
>>
>>#0 0x4026cbe4 in apr_atomic_cas ()
>> from /home/stas/httpd/prefork/lib/libapr-0.so.0
>>(gdb) where
>>#0 0x4026cbe4 in apr_atomic_cas ()
>> from /home/stas/httpd/prefork/lib/libapr-0.so.0
>>#1 0x40268b2d in apr_thread_mutex_lock ()
>> from /home/stas/httpd/prefork/lib/libapr-0.so.0
>>#2 0x4026b77e in apr_pool_create_ex_debug ()
>> from /home/stas/httpd/prefork/lib/libapr-0.so.0
>>#3 0x40267685 in apr_initialize ()
>> from /home/stas/httpd/prefork/lib/libapr-0.so.0
>>#4 0x40267618 in apr_app_initialize ()
>> from /home/stas/httpd/prefork/lib/libapr-0.so.0
>>#5 0x080c6fb8 in main (argc=2, argv=0xbffff4e4) at main.c:426
>>#6 0x40352c57 in __libc_start_main () from /lib/i686/libc.so.6
>>
>>This happens because hash_mutex[] is not initialized when apr_pool_create is
>>called.
>>
>>The apr_atomic_init that initializes that variable is running too late:
>>
>> if (apr_pool_create(&pool, NULL) != APR_SUCCESS) {
>> return APR_ENOPOOL;
>> }
>>
>> apr_pool_tag(pool, "apr_initialize");
>>
>> if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
>> return status;
>> }
>
>
> Yes, I brought this up a month ago.
>
> See the thread with the subject
>
> "unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump"
>
> Sander responded there, but there's been no work on it yet.
I hoped that I'll never need to do that, so I was ignoring any threads on that
subject. Now we have several problems with pools that I need to debug before I
can report them.
I have a dirty workaround, setting global_pool->mutex to NULL, at least I can
do some debugging.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: nested mutexes (was Re: segfault in apr_atomic_cas)
Posted by Sander Striker <st...@apache.org>.
> From: Aaron Bannert [mailto:aaron@clove.org]
> Sent: Sunday, September 28, 2003 2:15 AM
> On Wed, Sep 24, 2003 at 10:22:39PM -0500, William A. Rowe, Jr. wrote:
> > Others responded, "lets ditch nested locks". I'm -0.5 on that suggestion.
>
> Are there reasons we should keep it around? I didn't see any comment
> from you for or against the proposal, and frankly I didn't get enough
> positive or negative feedback to move ahead.
If you intend to remove it, please ensure there is no fallout in the pools
debug code. It uses the nested mutexes.
Sander
nested mutexes (was Re: segfault in apr_atomic_cas)
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Sep 24, 2003 at 10:22:39PM -0500, William A. Rowe, Jr. wrote:
> Others responded, "lets ditch nested locks". I'm -0.5 on that suggestion.
Are there reasons we should keep it around? I didn't see any comment
from you for or against the proposal, and frankly I didn't get enough
positive or negative feedback to move ahead.
-aaron
RE: segfault in apr_atomic_cas
Posted by Sander Striker <st...@apache.org>.
> From: William A. Rowe, Jr. [mailto:wrowe@apache.org]
> Sent: Thursday, September 25, 2003 5:23 AM
> At 07:06 PM 9/24/2003, Blair Zajac wrote:
> >Yes, I brought this up a month ago.
> >
> >See the thread with the subject
> >
> >"unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump"
> >
> >Sander responded there, but there's been no work on it yet.
>
>
> I responded - prove that my changes no longer require any mutex/interlocs
> such as atomics. Can we reduce this back to simple math?
>
> If we can, let's keep the good changes and back out the atomics.
>
> Others responded, "lets ditch nested locks". I'm -0.5 on that suggestion.
This isn't even hitting nested locks. It's hitting the mutex prior
to the atomics being initialized, which is where the problem lies.
This (not so nice) patch will solve it. It's either this or back out
the atomics change.
Sander
Index: memory/unix/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.198
diff -u -r1.198 apr_pools.c
--- memory/unix/apr_pools.c 3 Sep 2003 17:12:18 -0000 1.198
+++ memory/unix/apr_pools.c 25 Sep 2003 15:14:24 -0000
@@ -555,6 +555,13 @@
apr_pool_tag(global_pool, "apr_global_pool");
+ /* strikerXXX: This has to happen here because mutexes might be backed by
+ * strikerXXX: atomics. It used to be snug and safe in apr_initialize().
+ */
+ if ((rv = apr_atomic_init(global_pool)) != APR_SUCCESS) {
+ return rv;
+ }
+
#if APR_HAS_THREADS
{
apr_thread_mutex_t *mutex;
Index: misc/unix/start.c
===================================================================
RCS file: /home/cvs/apr/misc/unix/start.c,v
retrieving revision 1.70
diff -u -r1.70 start.c
--- misc/unix/start.c 6 Jan 2003 23:44:32 -0000 1.70
+++ misc/unix/start.c 25 Sep 2003 15:14:24 -0000
@@ -99,9 +99,12 @@
apr_pool_tag(pool, "apr_initialize");
- if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
- return status;
- }
+ /* strikerXXX: apr_atomic_init() used to be called from here aswell.
+ * strikerXXX: Pools rely on mutexes though, which can be backed by
+ * strikerXXX: atomics. Due to this circular dependency
+ * strikerXXX: apr_pool_initialize() is taking care of calling
+ * strikerXXX: apr_atomic_init() at the correct time.
+ */
apr_signal_init(pool);
Re: segfault in apr_atomic_cas
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 07:06 PM 9/24/2003, Blair Zajac wrote:
>Yes, I brought this up a month ago.
>
>See the thread with the subject
>
>"unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump"
>
>Sander responded there, but there's been no work on it yet.
I responded - prove that my changes no longer require any mutex/interlocs
such as atomics. Can we reduce this back to simple math?
If we can, let's keep the good changes and back out the atomics.
Others responded, "lets ditch nested locks". I'm -0.5 on that suggestion.
Bill
Re: segfault in apr_atomic_cas
Posted by Blair Zajac <bl...@orcaware.com>.
Stas Bekman wrote:
>
> When using apr built with --enable-pool-debug=all I get this segfault on the
> httpd server startup:
>
> #0 0x4026cbe4 in apr_atomic_cas ()
> from /home/stas/httpd/prefork/lib/libapr-0.so.0
> (gdb) where
> #0 0x4026cbe4 in apr_atomic_cas ()
> from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #1 0x40268b2d in apr_thread_mutex_lock ()
> from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #2 0x4026b77e in apr_pool_create_ex_debug ()
> from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #3 0x40267685 in apr_initialize ()
> from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #4 0x40267618 in apr_app_initialize ()
> from /home/stas/httpd/prefork/lib/libapr-0.so.0
> #5 0x080c6fb8 in main (argc=2, argv=0xbffff4e4) at main.c:426
> #6 0x40352c57 in __libc_start_main () from /lib/i686/libc.so.6
>
> This happens because hash_mutex[] is not initialized when apr_pool_create is
> called.
>
> The apr_atomic_init that initializes that variable is running too late:
>
> if (apr_pool_create(&pool, NULL) != APR_SUCCESS) {
> return APR_ENOPOOL;
> }
>
> apr_pool_tag(pool, "apr_initialize");
>
> if ((status = apr_atomic_init(pool)) != APR_SUCCESS) {
> return status;
> }
Yes, I brought this up a month ago.
See the thread with the subject
"unix/thread_mutex.c 1.19 and --enable-pool-debug=yes core dump"
Sander responded there, but there's been no work on it yet.
Best,
Blair
--
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/