You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Cliff Woolley <jw...@virginia.edu> on 2003/01/22 05:10:03 UTC
Multiple MMapFile causes Segmentation fault (fwd)
ARRRRGGGHHHHH!!!!!!! Guess I need to look into this. :(
--Cliff
---------- Forwarded message ----------
Date: 22 Jan 2003 03:13:45 -0000
From: bugzilla@apache.org
Reply-To: Apache HTTPD Bugs Notification List <bu...@httpd.apache.org>
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 16313] New: - Multiple MMapFile causes
Segmentation fault
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16313>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16313
Multiple MMapFile causes Segmentation fault
Summary: Multiple MMapFile causes Segmentation fault
Product: Apache httpd-2.0
Version: 2.0.44
Platform: All
OS/Version: Linux
Status: NEW
Severity: Major
Priority: Other
Component: mod_file_cache
AssignedTo: bugs@httpd.apache.org
ReportedBy: drew@damnimp.com
Specifying more than one file with the MMapFile configuration command causes
httpd to core dump with a Segmentation fault. Problem did not happen in 2.0.43.
Some debug of the code with gdb shows that mmap_cleanup (mmap.c) is called with
a *themap with it's next and prev pointers set to NULL, causing APR_RING_REMOVE
to fail.
Tested with MMapFile commands:
MMapFile /usr/local/apache/htdocs/apache_pb2.gif
MMapFile /usr/local/apache/htdocs/apache_pb2.png
(also segfaults if both files specified with one MMapFile command)
Here is the gdb dump:
(gdb) r -DONE_PROCESS
Starting program: /usr/local/apache/bin/httpd -DONE_PROCESS
[New Thread 1024 (LWP 19351)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 19351)]
0x400fca8d in mmap_cleanup (themmap=0x80e6340) at mmap.c:90
90 APR_RING_REMOVE(mm,link);
(gdb) where
#0 0x400fca8d in mmap_cleanup (themmap=0x80e6340) at mmap.c:90
#1 0x400fe986 in apr_pool_cleanup_run (p=0x80a8ef0, data=0x80e6340,
cleanup_fn=0x400fca58 <mmap_cleanup>) at apr_pools.c:1967
#2 0x400fccee in apr_mmap_delete (mm=0x80e6340) at mmap.c:195
#3 0x402ce2a2 in cleanup_file_cache (sconfv=0x80d7870) at mod_file_cache.c:177
#4 0x400fe9c7 in run_cleanups (cref=0x80a8f00) at apr_pools.c:1976
#5 0x400fde3f in apr_pool_clear (pool=0x80a8ef0) at apr_pools.c:718
#6 0x08071d08 in main (argc=2, argv=0xbffffb04) at main.c:608
#7 0x401a0657 in __libc_start_main (main=0x80715fc <main>, argc=2,
ubp_av=0xbffffb04, init=0x80609c4 <_init>,
fini=0x80917a0 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>,
stack_end=0xbffffafc) at ../sysdeps/generic/libc-start.c:129
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
Re: Multiple MMapFile causes Segmentation fault (fwd)
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 22 Jan 2003, Cliff Woolley wrote:
> It's unlikely that this problem has anything to do with APR; it's quite
> likely just a (newly uncovered) bug in mod_file_cache.
Looks that way. mod_file_cache keeps a hash table in the cmd->pool and
puts an entry in that hash table for each of its files and mmaps, all of
which are opened into cmd->pool. But it registered a cleanup on cmd->pool
that would walk the hash table and close each file and delete each mmap,
even though by the time that happened those things would have been done
already anyway by the files' and mmaps' own cleanups on cmd->pool. So it
was deleting mmaps that were already cleaned up and closing files that
were already cleaned up in all cases. This has never been valid... amazed
it ever worked. :-/
The attached patch *should* fix it, though it's tested only to compile at
this point. I'm mainly looking for another set of eyes to help verify
that I haven't missed anything... wouldn't want to introduce any memory or
fd leaks.
--Cliff
Re: Multiple MMapFile causes Segmentation fault (fwd)
Posted by Cliff Woolley <jw...@virginia.edu>.
On Tue, 21 Jan 2003, Cliff Woolley wrote:
> #0 0x400fca8d in mmap_cleanup (themmap=0x80e6340) at mmap.c:90
> #1 0x400fe986 in apr_pool_cleanup_run (p=0x80a8ef0, data=0x80e6340,
> cleanup_fn=0x400fca58 <mmap_cleanup>) at apr_pools.c:1967
> #2 0x400fccee in apr_mmap_delete (mm=0x80e6340) at mmap.c:195
> #3 0x402ce2a2 in cleanup_file_cache (sconfv=0x80d7870) at mod_file_cache.c:177
> #4 0x400fe9c7 in run_cleanups (cref=0x80a8f00) at apr_pools.c:1976
> #5 0x400fde3f in apr_pool_clear (pool=0x80a8ef0) at apr_pools.c:718
> #6 0x08071d08 in main (argc=2, argv=0xbffffb04) at main.c:608
> #7 0x401a0657 in __libc_start_main (main=0x80715fc <main>, argc=2,
I bet I know what's causing this. Ten to one that it's another stupid
case where the pool cleanups running in reverse order is biting us in the
ass. It's unlikely that this problem has anything to do with APR; it's
quite likely just a (newly uncovered) bug in mod_file_cache.
--Cliff