You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Walter <je...@404ster.com> on 2005/01/07 15:58:24 UTC
apr_global_mutex_create never returns
I'm writing an Apache HTTPD module which uses apr_global_mutex_create,
only problem is the function never returns. My call looks like this:
rv = apr_global_mutex_create((apr_global_mutex_t **) &strawtable->mutex,
c->lockFile, APR_LOCK_DEFAULT, pconf);
lockFile is set to "/var/lib/mod_straw/mod_straw.lock". I would
appreciate any ideas as I'm completely stumped (that and Google didn't
help much).
Jeff Walter
jeff@404ster.com
Re: apr_global_mutex_create never returns
Posted by Jeff Walter <je...@404ster.com>.
I compiled my module with -g then used gdb. As the none of Apache was
built with -g, the output was somewhat... vague. I'm going to compile
another Apache with -g for everything, which should help yield better
results.
Jeff Walter
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/sbin/apache2 -k start -X
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
Detaching after fork from child process 26204.
Program received signal SIGSEGV, Segmentation fault.
0x4027306e in apr_global_mutex_create () from /usr/lib/libapr-0.so.0
(gdb) bt
#0 0x4027306e in apr_global_mutex_create () from /usr/lib/libapr-0.so.0
#1 0x080a20f0 in ?? ()
#2 0x081affd0 in ?? ()
#3 0x40272f80 in apr_version_string () from /usr/lib/libapr-0.so.0
#4 0x080603b8 in ?? ()
#5 0x408c8974 in __JCR_LIST__ () from /usr/lib/apache2/modules/mod_straw.so
#6 0x080f5ea0 in ?? ()
#7 0x080a3e90 in ?? ()
#8 0x408c6cdb in straw_post_config (pconf=0x80a20f0, plog=0x80cc198,
ptemp=0x80bc158, s=0x80a3e90) at mod_straw.c:344
#9 0x08068549 in ap_run_post_config ()
#10 0x080cc198 in ?? ()
#11 0x080bc158 in ?? ()
#12 0x080a3e90 in ?? ()
#13 0x0809c050 in ?? ()
#14 0x081d8448 in ?? ()
#15 0x08182b78 in ?? ()
#16 0x080a3e90 in ?? ()
#17 0x080a20f0 in ?? ()
#18 0x080a0168 in ?? ()
#19 0xbffffb58 in ?? ()
#20 0x0806e145 in main ()
Re: apr_global_mutex_create never returns
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:47 AM 1/7/2005, Jeff Walter wrote:
>I took a gander at the APR SHM stuff, the only thing happening after the
>file is closed is:
>
>apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner,
> apr_pool_cleanup_null);
>*m = new_m;
>return APR_SUCCESS;
>
>If all it is doing is registering a cleanup handler, what could possibly
>cause it to segfault?
Every time this bites me, I discover the pool cleanup was registered
in a pool that outlived the module's lifetime, and it had been unloaded
before the callback was triggered.
Loadable modules shouldn't register in process or global pools
unless you are extraordinarily careful. Dunno your scope for
new_m->pool but I'm guessing that's what bit you.
Bill
Re: apr_global_mutex_create never returns
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, 07 Jan 2005 08:47:34 -0800, Jeff Walter <je...@404ster.com> wrote:
> Jeff Trawick wrote:
> > what is the backtrace? (attach with debugger)
>
> Funny... I didn't notice it before, my apr_shm_create causes a segfault
> (when I remove the file that actually gets created the run before). A
> trace...
>
> open("/var/lib/mod_straw/mod_straw.shm", O_WRONLY|O_CREAT|O_EXCL, 0666) = 35
> stat64("/var/lib/mod_straw/mod_straw.shm", {st_mode=S_IFREG|0644,
> st_size=0, ...}) = 0
> shmget(17008977, 20800, IPC_CREAT|IPC_EXCL|0600) = 4030469
> shmat(4030469, 0, 0) = 0x411e4000
> shmctl(4030469, IPC_64|IPC_STAT, 0xbffff9d0) = 0
> getuid32() = 0
> getgid32() = 0
> shmctl(4030469, IPC_64|IPC_SET, 0xbffff9d0) = 0
> write(35, "@Q\0\0", 4) = 4
> close(35) = 0
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
please run it from the debugger to see which line of code is crashing...
Re: apr_global_mutex_create never returns
Posted by Jeff Walter <je...@404ster.com>.
Jeff Trawick wrote:
> what is the backtrace? (attach with debugger)
Funny... I didn't notice it before, my apr_shm_create causes a segfault
(when I remove the file that actually gets created the run before). A
trace...
open("/var/lib/mod_straw/mod_straw.shm", O_WRONLY|O_CREAT|O_EXCL, 0666) = 35
stat64("/var/lib/mod_straw/mod_straw.shm", {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0
shmget(17008977, 20800, IPC_CREAT|IPC_EXCL|0600) = 4030469
shmat(4030469, 0, 0) = 0x411e4000
shmctl(4030469, IPC_64|IPC_STAT, 0xbffff9d0) = 0
getuid32() = 0
getgid32() = 0
shmctl(4030469, IPC_64|IPC_SET, 0xbffff9d0) = 0
write(35, "@Q\0\0", 4) = 4
close(35) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
I took a gander at the APR SHM stuff, the only thing happening after the
file is closed is:
apr_pool_cleanup_register(new_m->pool, new_m, shm_cleanup_owner,
apr_pool_cleanup_null);
*m = new_m;
return APR_SUCCESS;
If all it is doing is registering a cleanup handler, what could possibly
cause it to segfault?
Thanks again,
Jeff Walter
Re: apr_global_mutex_create never returns
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, 07 Jan 2005 06:58:24 -0800, Jeff Walter <je...@404ster.com> wrote:
> I'm writing an Apache HTTPD module which uses apr_global_mutex_create,
> only problem is the function never returns. My call looks like this:
>
> rv = apr_global_mutex_create((apr_global_mutex_t **) &strawtable->mutex,
> c->lockFile, APR_LOCK_DEFAULT, pconf);
>
> lockFile is set to "/var/lib/mod_straw/mod_straw.lock". I would
> appreciate any ideas as I'm completely stumped (that and Google didn't
> help much).
what is the backtrace? (attach with debugger)