You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dave Hill <dd...@zk3.dec.com> on 2002/09/09 20:44:13 UTC
alloca() issue on tru64
Hi all,
While digging into that mysterious hang of Apache 2 on Tru64,
I found that it seemed to be hanging under apr_poll in alloca()
While I found that the problem seems to go away when not using a
prerelease version of the OS, it did bring something to my attention.
According to "Those Who Know", in a threaded environment on Tru64, we
should be including alloca.h which causes the alloca() function to
become a builtin (which They say is the one true way of avoiding
threaded issues). This affects one (yes 1) file in the pool,
srclib/apr/poll/unix/poll.c. Attached is a suggested change to include
alloca.h if HAVE_ALLOCA is set. If my assumption is wrong that alloca
is a universal include file (for machines that have alloca), then this
could be restricted to Tru64, or maybe another conditional in
configure :-p
regards,
Dave Hill
--- srclib/apr/poll/unix/poll.c.orig 2002-09-09 11:01:27.000000000 -0400
+++ srclib/apr/poll/unix/poll.c 2002-09-09 11:02:25.000000000 -0400
@@ -64,6 +64,10 @@
#if HAVE_SYS_POLL_H
#include <sys/poll.h>
#endif
+#if HAVE_ALLOCA
+#include <alloca.h>
+#endif
+
#ifdef NETWARE
#define HAS_SOCKETS(dt) (dt == APR_POLL_SOCKET) ? 1 : 0
Re: alloca() issue on tru64
Posted by Brian Pane <br...@apache.org>.
David Hill wrote:
>For Tru64, the compiler defines two things, __alpha and __osf__ , either can
>be used, the __osf__ tends to be used more.
>So:
>
>#if HAVE_ALLOCA && defined(__osf__)
>
Thanks. I'll commit in a minute.
Brian
Re: alloca() issue on tru64
Posted by David Hill <dd...@zk3.dec.com>.
----- Original Message -----
From: "Brian Pane" <br...@apache.org>
To: <de...@httpd.apache.org>
Sent: Monday, September 09, 2002 3:02 PM
Subject: Re: alloca() issue on tru64
> Dave Hill wrote:
>
> >Hi all,
> > While digging into that mysterious hang of Apache 2 on Tru64,
> >I found that it seemed to be hanging under apr_poll in alloca()
> >While I found that the problem seems to go away when not using a
> >prerelease version of the OS, it did bring something to my attention.
> >
> >According to "Those Who Know", in a threaded environment on Tru64, we
> >should be including alloca.h which causes the alloca() function to
> >become a builtin (which They say is the one true way of avoiding
> >threaded issues). This affects one (yes 1) file in the pool,
> >srclib/apr/poll/unix/poll.c. Attached is a suggested change to include
> >alloca.h if HAVE_ALLOCA is set. If my assumption is wrong that alloca
> >is a universal include file (for machines that have alloca), then this
> >could be restricted to Tru64, or maybe another conditional in
> >configure :-p
> >
>
> I like the idea of restricting the change to Tru64 for now, just
> to eliminate the possibility of breaking something unexpected on
> some other system this close to the 2.0.41 launch. Is there a
> standard preprocessor macro that compilers on Tru64 define, so
> that we can do something like "#if HAVE_ALLOCA && __TRU64__"?
For Tru64, the compiler defines two things, __alpha and __osf__ , either can
be used, the __osf__ tends to be used more.
So:
#if HAVE_ALLOCA && defined(__osf__)
regards,
Dave Hill
Re: alloca() issue on tru64
Posted by Jeff Trawick <tr...@attglobal.net>.
Jeff Trawick <tr...@attglobal.net> writes:
> Do we agree that once 2.0.41 is launched it should be converted to a
> configure-time check for alloca.h, with the code changed to include
> the header if it exists, irrespective of Tru64?
change just committed to APR
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Some mod_cache + mod_proxy problems
Posted by Estrade Matthieu <es...@ifrance.com>.
Hi,
I'am trying to use the cache module with reverse proxy, and i have few
problems.
When i'am using a browser with data in cache, like the file test.gif.
If the picture is in my browser cache before my first try with the
reverse proxy,
mod_cache is unable to cache the data, because on the first connection
on the backend server,
it send a 304 to the reverse proxy, and mod_cache is not accepting to
cache 304.(headers only).
Not really a problem because when i clean the browser cache, it's
working well after.
but is it possible to think sending request to the backend server,
telling it to send a 200 and not a 304.(maybe with force headers).
The second problem is with mod_mem_cache and mod_proxy.
When mem_cache is trying to find the length of the data requested, it's
not working, so length is = -1
And when it do the test with the CacheMaxStreamBuffer, it's always
failed because the length must be upper to 0.
Maybe because the backend server send back a 304 too.
I will try to debug more, because my informations are not very good :)
Best regards,
Estrade Matthieu
Re: alloca() issue on tru64
Posted by David Reid <dr...@jetnet.co.uk>.
> Do we agree that once 2.0.41 is launched it should be converted to a
> configure-time check for alloca.h, with the code changed to include
> the header if it exists, irrespective of Tru64?
+1
david
Re: alloca() issue on tru64
Posted by Brian Pane <br...@apache.org>.
On Tue, 2002-09-10 at 04:12, Jeff Trawick wrote:
> Brian Pane <br...@apache.org> writes:
>
> > I like the idea of restricting the change to Tru64 for now, just
> > to eliminate the possibility of breaking something unexpected on
> > some other system this close to the 2.0.41 launch. Is there a
> > standard preprocessor macro that compilers on Tru64 define, so
> > that we can do something like "#if HAVE_ALLOCA && __TRU64__"?
>
> Do we agree that once 2.0.41 is launched it should be converted to a
> configure-time check for alloca.h, with the code changed to include
> the header if it exists, irrespective of Tru64?
+1
Brian
Re: alloca() issue on tru64
Posted by David Hill <dd...@zk3.dec.com>.
> Do we agree that once 2.0.41 is launched it should be converted to a
> configure-time check for alloca.h, with the code changed to include
> the header if it exists, irrespective of Tru64?
I like a configure time check myself, finding headers is one things the
configure program does well.
Dave Hill
Re: alloca() issue on tru64
Posted by Jeff Trawick <tr...@attglobal.net>.
Brian Pane <br...@apache.org> writes:
> I like the idea of restricting the change to Tru64 for now, just
> to eliminate the possibility of breaking something unexpected on
> some other system this close to the 2.0.41 launch. Is there a
> standard preprocessor macro that compilers on Tru64 define, so
> that we can do something like "#if HAVE_ALLOCA && __TRU64__"?
Do we agree that once 2.0.41 is launched it should be converted to a
configure-time check for alloca.h, with the code changed to include
the header if it exists, irrespective of Tru64?
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
LDAP Authentication Issue
Posted by "Jess M. Holle" <je...@ptc.com>.
I recently ran into an issue with non-ASCII user names in LDAP-based
authentication -- both via the Apache 1.3.x auth_ldap module from
www.rudedog.org and with the httpd-ldap sub-project for Apache 2.0.x.
This issue is rather nicely documented in:
http://www.rudedog.org/pipermail/auth_ldap/2002-July/011188.html
Does anyone have a patch to auth_ldap or the httpd-ldap project sources
to address this issue? [European and Asian users are less than excited
by the current behavior.]
--
Jess Holle
Re: alloca() issue on tru64
Posted by Albert Chin <ne...@thewrittenword.com>.
On Mon, Sep 09, 2002 at 12:02:02PM -0700, Brian Pane wrote:
> Dave Hill wrote:
>
> >Hi all,
> > While digging into that mysterious hang of Apache 2 on Tru64,
> >I found that it seemed to be hanging under apr_poll in alloca()
> >While I found that the problem seems to go away when not using a
> >prerelease version of the OS, it did bring something to my attention.
> >
> >According to "Those Who Know", in a threaded environment on Tru64, we
> >should be including alloca.h which causes the alloca() function to
> >become a builtin (which They say is the one true way of avoiding
> >threaded issues). This affects one (yes 1) file in the pool,
> >srclib/apr/poll/unix/poll.c. Attached is a suggested change to include
> >alloca.h if HAVE_ALLOCA is set. If my assumption is wrong that alloca
> >is a universal include file (for machines that have alloca), then this
> >could be restricted to Tru64, or maybe another conditional in
> >configure :-p
> >
>
> I like the idea of restricting the change to Tru64 for now, just
> to eliminate the possibility of breaking something unexpected on
> some other system this close to the 2.0.41 launch. Is there a
> standard preprocessor macro that compilers on Tru64 define, so
> that we can do something like "#if HAVE_ALLOCA && __TRU64__"?
Bison does something similar to:
#if defined _AIX && !defined __GNUC__
#pragma alloca
#endif
#include <config.h>
/* Make alloca work the best possible way. */
#ifdef __GNUC__
#define alloca __builtin_alloca
#else /* not __GNUC__ */
#if HAVE_ALLOCA_H
#include <alloca.h>
#else /* not __GNUC__ or HAVE_ALLOCA_H */
#ifndef _AIX /* Already did AIX, up at the top. */
char *alloca ();
#endif /* not _AIX */
#endif /* not HAVE_ALLOCA_H */
#endif /* not __GNUC__ */
This seems quite robust.
--
albert chin (china@thewrittenword.com)
Re: alloca() issue on tru64
Posted by Brian Pane <br...@apache.org>.
Dave Hill wrote:
>Hi all,
> While digging into that mysterious hang of Apache 2 on Tru64,
>I found that it seemed to be hanging under apr_poll in alloca()
>While I found that the problem seems to go away when not using a
>prerelease version of the OS, it did bring something to my attention.
>
>According to "Those Who Know", in a threaded environment on Tru64, we
>should be including alloca.h which causes the alloca() function to
>become a builtin (which They say is the one true way of avoiding
>threaded issues). This affects one (yes 1) file in the pool,
>srclib/apr/poll/unix/poll.c. Attached is a suggested change to include
>alloca.h if HAVE_ALLOCA is set. If my assumption is wrong that alloca
>is a universal include file (for machines that have alloca), then this
>could be restricted to Tru64, or maybe another conditional in
>configure :-p
>
I like the idea of restricting the change to Tru64 for now, just
to eliminate the possibility of breaking something unexpected on
some other system this close to the 2.0.41 launch. Is there a
standard preprocessor macro that compilers on Tru64 define, so
that we can do something like "#if HAVE_ALLOCA && __TRU64__"?
Thanks,
Brian