Hi All,
Is there any way to prevent Apache::Test from setting ulimit during
`make test`? Mine is a Pure Perl module, and I don't really need to
worry about core files. I'd like to gain the extra time taken to set
and unset it repeatedly.
TIA,
David
--
David Wheeler
David Wheeler wrote:
Hi All,
Is there any way to prevent Apache::Test from setting ulimit during
`make test`? Mine is a Pure Perl module, and I don't really need to
worry about core files. I'd like to gain the extra time taken to set and
unset it repeatedly.
looks like setting
On Tuesday, July 1, 2003, at 06:19 PM, Geoffrey Young wrote:
looks like setting $ENV{APACHE_TEST_ULIMIT_SET}=1 should do the trick.
optionally, you could locally override set_ulimit() from your TEST.PL
use Apache::TestRun;
local *Apache::TestRun::set_ulimit = sub {1};
Ah, well, I don't have a
On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote:
jwoolley2003/07/01 22:25:44
Modified:buckets apr_buckets_alloc.c
include apr_buckets.h
Log:
an addition to the api to allow httpd mpm's to share an apr_allocator_t
between a thread pool and the thread's bucket
On Tue, 1 Jul 2003, Cliff Woolley wrote:
don't use it. We intentionally do not check for OOM conditions because,
though we've had many heated debates about this, we've always arrived at
the consensus that if you hit OOM, your box is hosed anyway and virtually
any effort you make to correct
On Wed, Jul 02, 2003 at 02:03:39AM -0400, Cliff Woolley wrote:
On Wed, 2 Jul 2003 [EMAIL PROTECTED] wrote:
jwoolley2003/07/01 22:25:44
Modified:buckets apr_buckets_alloc.c
include apr_buckets.h
Log:
an addition to the api to allow httpd mpm's to share
On Tue, 1 Jul 2003, Greg Stein wrote:
Eh? Why the flag? What is that for... doesn't the caller know when and if he
should clean up? So there shouldn't be a need for a flag...
The caller knows. But right now apr_buckets_alloc.c:alloc_cleanup() calls
apr_allocator_destroy(allocator) regardless
Hi,
a couple of weeks ago I upgraded our servers from 2.0.43 to 2.0.46.
Since then, child processes on our internal server either exit with a
segmentation fault or keep running but take all CPU power. Hanging
processes occur at a rate of about 5 per hour. As far as I can see the
URLs they are
On Tuesday, July 1, 2003, at 04:16 PM, André Malo wrote:
* Jim Jagielski wrote:
Noted in Apache 1.3's STATUS file... There is also
a question (MMN bump)
Hmm, in 2.x we decided that core_server_conf isn't public so we don't
need
such a bump. Perhaps for the ap_is_recursion_limit_exceeded
On Tue, Jul 01, 2003 at 03:01:43PM +0200, Estrade Matthieu wrote:
...
#if APR_HAS_SHARED_MEMORY
-if (util_ldap_shm) {
-return (void *)apr_rmm_addr_get(util_ldap_rmm,
apr_rmm_calloc(util_ldap_rmm, size));
+if (st-util_ldap_shm) {
+return (void
Graham Leggett wrote:
Am I correct in understanding that commits to the v2.1 branch are commit
then review?
yes
Hi joe,
First, thanks for the answer.
I based my code on two examples:
First the broken util_ldap_cache_mgr.c and i just changed util_ldap_rmm
by st-util_ldap_rmm.
Then on ssl_scache_shmht.c uring rmm to see if i have to check what
return apr_rmm_malloc and calloc. (it's not done)
After this,
APACHE 1.3 STATUS: -*-text-*-
Last modified at [$Date: 2003/07/01 12:29:12 $]
Release:
1.3.28-dev: In development. Jim proposes a TAG on July 1, 2003
with a RELEASE on July 4, 2003 and offers to be
RM.
1.3.27:
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2003/07/01 01:25:04 $]
Release:
2.0.47 : in development
2.0.46 : released May 28, 2003 as GA.
2.0.45 : released April 1, 2003 as GA.
2.0.44 : released January 20, 2003 as GA.
APACHE 2.1 STATUS: -*-text-*-
Last modified at [$Date: 2003/05/29 15:07:11 $]
Release [NOTE that only Alpha/Beta releases occur in 2.1 development]:
2.1.0 : in development
Please consult the following STATUS files for information
on related
15 matches
Mail list logo
