You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Chris Darroch <ch...@pearsoncmg.com> on 2010/10/05 04:08:18 UTC
mod_authn_file + low ThreadStackSize = oops
Hi --
It's been ages since I wrote to the list; as always, my apologies.
I hope to get back to some actual programming soon, unless life gets
in the way again.
In the meantime, a quick note for anyone who might at some point
stumble over the same thing and go to Google for help. I set up a
simple Apache httpd with mod_authn_file and mod_authn_basic, and
the darn thing was crashing while trying to authenticate the user.
A trace revealed it was crashing in apr_password_validate() on a memset()
on a crypt_data struct buffer from for use with crypt_r(). Huh?
I stared at the definition of crypt_data in crypt.h, poked
around at various things, then gave up and went for quick bike ride.
The answer immediately popped to mind: I'd set my ThreadStackSize really
low, to 64 KB, and while that usually lets you run without trouble
on a Linux box, crypt_data contains about 256 KB worth of arrays
and it was overflowing the per-thread stack. Live and learn.
Chris.
--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
Re: mod_authn_file + low ThreadStackSize = oops
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Stefan:
> This is PR 49437.
>
> crypt_data is a bit more than 128K on my Linux box.
Yup, mine too, my bad -- typing while tired.
> Any opinions how this could be improved?
>
> - use malloc/free instead. This may be bad for performance (e.g.
> glibc's malloc will use mmap/munmap by default for blocks > 128K,
> which is expensive)
> - create and destroy a temporary pool from the global pool
> - add a function apr_password_validate_ex that accepts a temp pool.
> This is only possible in apr-util 1.4.x
> - leave the current behaviour and document that ThreadStackSizes lower
> than 256K are problematic on Unix.
>
> I am leaning towards just fixing the documentation, even if that may
> mean that something like 60-100K per thread are used just for doing
> crypt().
I'd agree with that, and maybe also the apr-util fix for APR 1.4
and httpd trunk.
Chris.
--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
Re: mod_authn_file + low ThreadStackSize = oops
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 05 October 2010, Chris Darroch wrote:
> I stared at the definition of crypt_data in crypt.h, poked
> around at various things, then gave up and went for quick bike
> ride. The answer immediately popped to mind: I'd set my
> ThreadStackSize really low, to 64 KB, and while that usually lets
> you run without trouble on a Linux box, crypt_data contains about
> 256 KB worth of arrays and it was overflowing the per-thread
> stack. Live and learn.
This is PR 49437.
crypt_data is a bit more than 128K on my Linux box.
Any opinions how this could be improved?
- use malloc/free instead. This may be bad for performance (e.g.
glibc's malloc will use mmap/munmap by default for blocks > 128K,
which is expensive)
- create and destroy a temporary pool from the global pool
- add a function apr_password_validate_ex that accepts a temp pool.
This is only possible in apr-util 1.4.x
- leave the current behaviour and document that ThreadStackSizes lower
than 256K are problematic on Unix.
I am leaning towards just fixing the documentation, even if that may
mean that something like 60-100K per thread are used just for doing
crypt().
Re: mod_authn_file + low ThreadStackSize = oops
Posted by Chris Darroch <ch...@pearsoncmg.com>.
Eric Covener wrote:
>> I'd set my ThreadStackSize really low, to 64 KB, and while that usually
>> lets you run without trouble
>
> I was just about to document that _lowering_ the stack size with
> ThreadStackSize is unreliable since the underlying call used only sets
> a _minimum_ stack size, not an actual one.
>
> Did you have any extenuating circumstances (old linux, alternate
> thread library, ulimit -s already set below 128?)
Just a number of old Linux (but still NPTL) 32-bit boxes; that's the main
reason. I'd seen this and some similar postings over the years and found
we could squeeze more threads in if we used, say, 128 KB in production
and 64 KB in dev for ThreadStackSize:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200904.mbox/%3cPine.GSO.4.64.0904021650190.28858@hatchepsut.acc.umu.se%3e
However ... I would certainly in interested in a clear accounting
of what, precisely, recent NPTL versions are doing with the
pthread_attr_setstacksize() setting and if changes from the (relatively
large) default value are useful or not.
Chris.
--
GPG Key ID: 088335A9
GPG Key Fingerprint: 86CD 3297 7493 75BC F820 6715 F54F E648 0883 35A9
Re: mod_authn_file + low ThreadStackSize = oops
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 10/27/2010 12:53 PM, Eric Covener wrote:
>> I'd set my ThreadStackSize really low, to 64 KB, and while that usually lets you run without trouble
>
> I was just about to document that _lowering_ the stack size with
> ThreadStackSize is unreliable since the underlying call used only sets
> a _minimum_ stack size, not an actual one.
It's not a pre-allocation, AIUI. It is the ceiling to which the stack may
grow, at which point it's probably bumping up against the next thread's
own stack. Especially with 32-bit execution, this becomes critical for
worker/event etc, because 1024mb reservations would allow only 1024 stacks
(or threads) to sit within a typical 1GB window of potential stack allocations.
Dropping it to 64kb (which probably would not work!) provides 16k stacks.
> Did you have any extenuating circumstances (old linux, alternate
> thread library, ulimit -s already set below 128?)
Always a good question.
Re: mod_authn_file + low ThreadStackSize = oops
Posted by Eric Covener <co...@gmail.com>.
> I'd set my ThreadStackSize really low, to 64 KB, and while that usually lets you run without trouble
I was just about to document that _lowering_ the stack size with
ThreadStackSize is unreliable since the underlying call used only sets
a _minimum_ stack size, not an actual one.
Did you have any extenuating circumstances (old linux, alternate
thread library, ulimit -s already set below 128?)
--
Eric Covener
covener@gmail.com