Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Mar 2007 16:49:40 -0500 (CDT)
From:      Tim Zingelman <zingelman@fnal.gov>
To:        apache@FreeBSD.org
Subject:   Sporadic segfault with mod_layout 3.2.1 (fwd)
Message-ID:  <Pine.GSO.4.58.0703261645040.12216@nova.fnal.gov>

next in thread | raw e-mail | index | archive | help
F.Y.I.  The current mod_layout 3.2.1 in ports suffers from a crash anytime
it attempts to work on a file that has a size that is a multiple of system
pagesize, due to an mmap not having a null at the end (as it does in all
other cases).

As you can see from the thread below, this has been fixed in the now
available 3.3 version by the maintainer.

Thanks,

 - Tim

---------- Forwarded message ----------
Date: Fri, 23 Mar 2007 15:22:48 -0700
From: Brian Aker <brian at tangent.org>
To: Tim Zingelman <zingelman at fnal.gov>
Subject: Re: Sporadical segfault with mod_layout 3.2.1

Hi Tim,

Thank you for the patch. I've modified it a bit, but have applied it
to the 3.0 tree (so it can now be downloaded from the site).

Cheers,
	-Brian

On Mar 23, 2007, at 12:15 PM, Tim Zingelman wrote:

> I have just found and made a patch for an issue that seems to match
> this
> exactly.
>
> The case where a segfault happens is when the file is mmap'd in
> mod_layout.c and the file is EXACTLTY a multiple of the pagesize.
> In this
> case the mmap'd memory has no trailing NULL and ap_ind(), called by
> string_search() steps right off into un-mapped memory.
>
> Find your system page size [getpagesize() is one way] and then make
> a file
> that size exactly and try to serve it via apache with mod_layout
> enabled... it crashes every time.
>
> Here is some cut-n-pasted gdb output to support this idea:
>
> #0  0x806551e in ap_ind (s=0x2822cffa "HTML>\n" <Address 0x2822d000
> out ofbounds>, c=60)
>     at util.c:1980
> 1980        for (x = 0; s[x]; x++)
> (gdb) bt
> #0  0x806551e in ap_ind (s=0x2822cffa "HTML>\n" <Address 0x2822d000
> out of bounds>, c=60)
>     at util.c:1980
> #1  0x281fdc8b in string_search (r=0x80c0034,
>     string=0x2822c000 "<!DOCTYPE HTML PUBLIC"...,
>     delim=0x809bcbc "<nolegal>", init_pos=0, flag=0) at utility.c:210
> #2  0x281fda66 in table_search (r=0x80c0034, t=0x809bccc,
>     string=0x2822c000 "<!DOCTYPE HTML PUBLIC"...) at utility.c:124
> #3  0x281fe525 in is_ignored (r=0x80c0034, cfg=0x80c0cc4,
> info=0x80c1724,
>     body=0x2822c000 "<!DOCTYPE HTML PUBLIC"...) at utility.c:499
> #4  0x281fcada in layout_handler (r=0x80c0034) at mod_layout.c:379
> #5  0x8051fac in ap_invoke_handler (r=0x80c0034) at http_config.c:476
> #6  0x8062065 in process_request_internal (r=0x80c0034) at
> http_request.c:1299
> #7  0x80620c4 in ap_process_request (r=0x80c0034) at http_request.c:
> 1315
> #8  0x805b23e in child_main (child_num_arg=25) at http_main.c:4813
> #9  0x805b455 in make_child (s=0x8085034, slot=25, now=1174506450)
> at http_main.c:4983
> #10 0x805b6c4 in perform_idle_server_maintenance () at http_main.c:
> 5168
> #11 0x805bbd5 in standalone_main (argc=1, argv=0xbfbff008) at
> http_main.c:5431
> #12 0x805c107 in main (argc=1, argv=0xbfbff008) at http_main.c:5684
>
> (gdb) up
> (gdb) print sub_temp
> $5 = 0x814448c "</html>"
> (gdb) print delim_size
> $6 = 9
> (gdb) print delim
> $7 = 0x809bcbc "<nolegal>"
> (gdb) print temp
> $8 = 0x2822cffa "HTML>\n" <Address 0x2822d000 out of bounds>
> (gdb) print init_pos
> $9 = 673370106
> (gdb) print temp
> $10 = 0x2822cffa "HTML>\n" <Address 0x2822d000 out of bounds>
> (gdb) print temp[0]
> $11 = 72 'H'
> (gdb) print temp[5]
> $12 = 10 '\n'
> (gdb) print temp[6]
> Cannot access memory at address 0x2822d000.
> (gdb) up
> (gdb) up
> (gdb) up
> (gdb) print map_data->size
> $16 = 4096
>
> The patch I came up with is attached... note that the alternative of
> trying to mmap a page of zeros directly after the pages the file is
> mapped
> to, which some google searches suggest, blows up apache in the case
> when
> that area is already mmap'd and in use.  (mmap deletes the old
> mapping!)
>
> Hope this helps.
>
>  - Tim
> <mod_layout.patch-aa.public>

--
_______________________________________________________
Brian "Krow" Aker, brian at tangent.org
Seattle, Washington
http://krow.net/
http://tangent.org/
_______________________________________________________
You can't grep a dead tree.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.58.0703261645040.12216>