Re: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit architectures (was: Early core dump)

2011-10-22 Thread Niko Tyni 
On Wed, Sep 28, 2011 at 02:22:49PM -0700, Marco Walther wrote:
> OK, I think I found one problem.  The following two defines don't
> make it from the Perl make to the CCFLAGS for the mod_perl:-(
> `-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' (They are automatically
> added by the Configure for perl and listed in the perl -V output
> below).
> 
> That causes the my_perl structure to be of different sizes/offsets
> between perl and mod_perl. That works by accident with Perl 5.10.1
> and finally breaks with 5.14.[12]

We're running into this on Debian 32-bit architectures too
(http://bugs.debian.org/636651 [cc'd]), and the issue is one of the
blockers for our transition to Perl 5.14.

> Unfortunately even trying to run
> /opt/kenai/bin/perl Makefile.PL DEFINE='-D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64'
> is not enough:-( The defines still do not make it to the
> src/modules/perl/Makefile:-( But after changing that Makefile by
> hand and rebuilding, things seem to be working fine.

These cpp flags are stripped by lib/Apache2/Build.pm, see
has_large_files_conflict() and strip_lfs().

The mod_perl2 2.0.5 test suite works for me with Perl 5.14 if I hardwire
has_large_files_conflict() to return 0 and apply r1125476 from 2.0.6-dev:
 
http://svn.apache.org/viewvc/perl/modperl/trunk/src/modules/perl/modperl_svptr_table.c?r1=932879&r2=1125476

The elaborate comments about large file issues in lib/Apache2/Build.pm
around strip_lfs() seem to be partly outdated; selectively quoting:

# on Unix systems where by default off_t is a "long", a 32-bit integer,
# there are two different ways to get "large file" support, i.e. the
# ability to manipulate files bigger than 2Gb:
#
# 1) you compile using -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64.
[...]
# 2) you compile using -D_LARGEFILE64_SOURCE
[...]
# The problem that mod_perl has to work around is when you take a
# package built with approach (1), i.e. Perl, and any package which was
# *not* built with (1), i.e. APR, and want to interface between
# them. [1]
[...]
# Perl built with -Duselargefiles uses approach (1).
#
# APR HEAD uses (2) by default.
[...]
# [1]: In some cases, it may be OK to interface between packages which
# use (1) and packages which use (2).  APR HEAD is currently not such a
# case, since the size of apr_ino_t is still changing when
# _FILE_OFFSET_BITS is defined.

The last paragraph dates back to 2004, and the apr changelogs read:

> Changes for APR 1.2.12
>   *) Define apr_ino_t in such a way that it doesn't change definition
>   based on the library consumer's -D'efines to the filesystem.
>   [Lucian Adrian Grijincu ]

> Changes for APR 1.4.3
>   *) configure: Make definition of apr_ino_t independent of
>  _FILE_OFFSET_BITS even on platforms where ino_t is 'unsigned int'.
>  [Stefan Fritsch]

To summarize, it looks like Apache2::Build::strip_lfs() breaks with Perl
5.14 with -Duselargefiles on 32-bit architectures, and is not necessary
since at least apr 1.4.3, possibly earlier.

I'd like input on whether we should expect further pitfalls if we
build mod_perl2 with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 on
Debian, i.e. stop stripping those flags in Apache2::Build.

Obviously, a more portable solution is needed for mod_perl 2.0.6.
Perhaps an explicit probe for sizeof(apr_ino_t) with different
_FILE_OFFSET_BITS definitions?

Cheers,
-- 
Niko Tyni   nt...@debian.org

Re: mod_perl 2.0.5 -> Attempt to free unreferenced scalar on startup

2012-01-06 Thread Niko Tyni 
[I sent earlier versions of these to d...@perl.apache.org on Dec 14th and 17th,
 Message-ID: <20111214213054.GA11814@madeleine.local.invalid> and
 Message-ID: <20111217072816.GA25763@madeleine.local.invalid>,
 but they never made it through to the list for some reason. Retrying on the
 modperl list, apologies for any duplicates.]
 
On Sat, Aug 06, 2011 at 08:02:20PM +0200, rich...@ecos.de wrote:
 
> while trying to get Embperl ready with Perl 5.14.1, I found an the
> following message in the error log:

> Attempt to free unreferenced scalar: SV 0x7fc218, Perl interpreter:
> 0x7cfdb0 during global destruction.

We're also seeing this in Debian now that we've switched to Perl 5.14,
(see http://bugs.debian.org/650675 [cc'd.])

I managed to cut the problem down to the small attached program,
which embeds perl and mimics modperl_perl_core_global_init() for the
essential part of

GV *gv = gv_fetchpv("myglob", TRUE, SVt_PVCV);
GvCV_set(gv, get_cv("myfunc", TRUE));

The warnings only seem to happen with -Dusethreads, and I've bisected that
they started with 5.13.6 - specifically

 
http://perl5.git.perl.org/perl.git/commit/ca556bcdca736b2f85c11650c70b2371169c0225

commit ca556bcdca736b2f85c11650c70b2371169c0225
Author: David Mitchell 
Date:   Sun Sep 19 12:33:04 2010 +0100

[perl #40389] perl_destruct() leaks PL_defstash

With PERL_DESTRUCT_LEVEL >= 1, PL_defstash is explicitly freed,
but doesn't actually get freed at that point due to a reference loop
between %:: and *::. Break that loop to ensure that PL_defstash gets freed
at that point. Actually, its not as serious as it sounds, as it would get
freed a bit later anyway by sv_clean_all(), but this new way has these
benefits:

* it gets freed where you expect it to be
* it gets freed cleanly, rather than by the more brutal sv_clean_all()
  (which can leave dangling pointers to freed SVs)
* since its freed while *not* under the influence of
  PL_in_clean_all = TRUE, it's more likely to flag up bugs related to
  double-freeing etc. Indeed, the two previous commits to this are a
  result of that.

My limited understanding is that the CV pointer needs its refcount
incremented along with the GvCV_set() call. See the attached proposed
patches which fix all the dozens of such warnings in t/logs/error_log
after running the whole test suite.

Feel free to tell me if I got it all wrong, though :)

Cheers,
-- 
Niko Tyni   nt...@debian.org
#include/* from the Perl distribution */
#include  /* from the Perl distribution */

/* compatibility for perl <= 5.12 */
#ifndef GvCV_set
#define GvCV_set(gv, cv) (GvCV(gv)=(cv))
#endif

static PerlInterpreter *my_perl;  /***The Perl interpreter***/

int main(int argc, char **argv, char **env)
{
	PERL_SYS_INIT3(&argc,&argv,&env);
	my_perl = perl_alloc();
	perl_construct(my_perl);
	
	perl_parse(my_perl, NULL, argc, argv, (char **)NULL);
	GV *gv = gv_fetchpv("myglob", TRUE, SVt_PVCV);
	GvCV_set(gv, get_cv("myfunc", TRUE));
	
	perl_run(my_perl);
	perl_destruct(my_perl);
	perl_free(my_perl);
	PERL_SYS_TERM();
}

>From 2099956795016f3bd08768dda195aeec7dc2267b Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Wed, 14 Dec 2011 22:51:27 +0200
Subject: [PATCH] Fix a reference counting bug uncovered by Perl 5.13.6

As seen in
 http://bugs.debian.org/650675
 http://article.gmane.org/gmane.comp.apache.mod-perl.devel/9928

perl since 5.13.6 with -Dusethreads makes mod_perl2 issue warnings like

 Attempt to free unreferenced scalar: SV 0x7f9c0c347490, Perl interpreter: 0x7f9c0c1a2dd0 during global destruction.

on startup regardless of the Perl code executed.

The double-freed scalar is the CV pointer for ModPerl::Util::exit()
whose reference count wasn't increased properly.
---
 src/modules/perl/modperl_perl.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/modules/perl/modperl_perl.c b/src/modules/perl/modperl_perl.c
index e992df4..1a2b3ce 100644
--- a/src/modules/perl/modperl_perl.c
+++ b/src/modules/perl/modperl_perl.c
@@ -55,7 +55,9 @@ void modperl_perl_core_global_init(pTHX)
 
 while (cglobals->name) {
 GV *gv = gv_fetchpv(cglobals->core_name, TRUE, SVt_PVCV);
-GvCV_set(gv, get_cv(cglobals->sub_name, TRUE));
+CV *cv = get_cv(cglobals->sub_name, TRUE);
+GvCV_set(gv, cv);
+SvREFCNT_inc(cv);
 GvIMPORTED_CV_on(gv);
 cglobals++;
 }
-- 
1.7.7.3

>From cbf08a2de6f967863d764eb0bc620178c4ed43fe Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sat, 17 Dec 2011 09:16:22 +0200
Subject: [PATCH 2/2] Fix another reference counting bug uncovered by Perl
 5.13.6

As seen in
 http://bugs.debian.org/650675
 http://article.gmane.org/gmane.comp.apache.mod-perl.devel/9928

perl since 5.13.6 with -Dusethread

Re: perl 5.14 ExtUtils::MakeMaker bug affecting libapreq?

2012-03-01 Thread Niko Tyni 
On Thu, Mar 01, 2012 at 10:38:49AM -0600, Jason Aubrey wrote:

> I recently used perlbrew to install perl 5.14.2, and then I compiled apache
> 2.2.22, mod_perl-2.0.5, and libapreq2-2.13.  But then I think I'm getting a
> binary incompatibility problem:
> 
> jason@plato:~$ perl -MAPR::Request -e 1
> Not a CODE reference at
> /home/jason/perl5/perlbrew/perls/perl-5.14.2/lib/5.14.2/i686-linux-thread-multi/DynaLoader.pm
> line 213.

> I found this describing a possible bug in ExtUtils::MakeMaker that gives a
> similar error for other modules:
> 
> http://lists.fedoraproject.org/pipermail/perl-devel/2011-June/037523.html
> 
> However, I could find no bug report about this on cpan (against libapreq2,
> there are unattended bug reports about the general issue for
> ExtUtils::MakeMaker).  Also, I tried adding CCFLAGS =>
> "$Config::Config{ccflags}", to the Makefile.PL in glue/perl, but maybe
> that's not the right way to do it because I get the same error.  Do you
> think this is the cause of the error? If so, any suggestions for making it
> work?

I doubt libapreq2 needs fixing, your call trace looks like it's loading
APR.so which is built from mod_perl2 itself.

See the thread around
 http://www.mail-archive.com/modperl@perl.apache.org/msg26248.html
for some past discussion on that.

The patch we're currently applying in Debian is
 
http://patch-tracker.debian.org/patch/series/view/libapache2-mod-perl2/2.0.5-5/250-lfs-perl-5.14.patch

HTH,
-- 
Niko Tyni   nt...@debian.org

Re: perl/hash_attack.t fails with 5.10.1 + CVE-2013-1667 fix

2013-03-13 Thread Niko Tyni 
On Wed, Mar 13, 2013 at 09:13:15AM -, Steve Hay wrote:
> Dominic Hargreaves wrote on 2013-03-12:

> > When trying to fix this issue in Debian stable, I found that the patch
> at
> > 
> > http://svn.apache.org/viewvc?view=revision&revision=1455340
> > 
> > does not stop the test failing when applied to 2.0.4 (as currently
> > found in Debian stable) and built against the current perl package in
> > Debian stable (5.10 + the rehashing fix). 

> I haven't looked at the Debian package, or tried anything with
> mod_perl-2.0.4, but I've just checked out origin/maint-5.10 from the
> Perl git repo (in fact, I took the snapshot at
> http://perl5.git.perl.org/perl.git/snapshot/f14269908e5f8b4cab4b55643d7d
> d9de577e7918.tar.gz) and tried that with Apache 2.2.22 and mod_perl from
> trunk and the tests all pass for me... (This is on Windows 7 x64 with
> VC++ 2010.)

Thanks for checking.

FWIW, I can reproduce the failure with the Debian perl 5.10.1 package and
mod_perl2 2.0.7 with just the above test fix. So it doesn't seem to be
a Debian change that breaks it. Maybe -Dusethreads or something like that.

I'll keep looking and send an update when I know more.
-- 
Niko Tyni   nt...@debian.org

Re: mod_perl 2.0.9 make test dumped core

2016-05-10 Thread Niko Tyni 
On Tue, May 10, 2016 at 07:45:45PM +, Xinhuan Zheng wrote:
 
> Today I used mod_perl 2.0.9, apache httpd 2.4.20 and perl 5.10.1 to try 
> compiling mod_perl DSO object on centos 6 (x86_64) machine. It passed 
> configure and make but failed ‘make test’.

> [  error] oh dangit, server dumped core
> [  error] for stacktrace, run: gdb 
> /usr/local/apache-2.4.20-catalyst/bin/httpd -core 
> /tmp/mod_perl-2.0.9/t/core.2184

There's a known issue with t/protocol/pseudo_http.t crashing Apache
2.4.20, see

http://www.mail-archive.com/dev%40perl.apache.org/msg13696.html

-- 
Niko Tyni   nt...@debian.org

[mp2] Perl 5.10 fixes from SVN cause SIGBUS on sparc

2008-03-07 Thread Niko Tyni 
e=8, Off_t='off_t', 
lseeksize=8
alignbytes=8, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.6.1.so, so=so, useshrplib=true, libperl=libperl.so.5.8.8
gnulibc_version='2.6.1'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT
PERL_MALLOC_WRAP THREADS_HAVE_PIDS USE_ITHREADS
USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API
  Built under linux
  Compiled at Nov  8 2007 10:57:52
  %ENV:
PERL_LWP_USE_HTTP_10="1"
  @INC:
/etc/perl
/usr/local/lib/perl/5.8.8
/usr/local/share/perl/5.8.8
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
.

*** Packages of interest status:

Apache2: -
Apache2::Request   : -
CGI: 3.15
ExtUtils::MakeMaker: 6.30_01
LWP: 5.808
mod_perl   : -
mod_perl2  : -


3. This is the core dump trace:

Core was generated by `/usr/sbin/apache2 -d 
/home/buildd/mod-perl2/ModPerl-Registry/t -f /home/buildd/'.
Program terminated with signal 10, Bus error.
#0  0x70c16914 in Perl_pop_scope (my_perl=0x13ecb0) at scope.c:143
143 const I32 oldsave = PL_scopestack[--PL_scopestack_ix];
(gdb) bt
#0  0x70c16914 in Perl_pop_scope (my_perl=0x13ecb0) at scope.c:143
#1  0x70bc5798 in Perl_pp_entersub (my_perl=0x13ecb0) at pp_hot.c:2888
#2  0x70b8d87c in Perl_runops_debug (my_perl=0x13ecb0) at dump.c:1459
#3  0x70af9278 in S_call_body (my_perl=0x13ecb0, myop=0xff8ad490, is_eval=1 
'\001') at perl.c:2731
#4  0x70af9650 in Perl_eval_sv (my_perl=0x13ecb0, sv=0x140358, flags=2) at 
perl.c:2793
#5  0x70af9ea8 in Perl_require_pv (my_perl=0x13ecb0, 
pv=0xfcec8 
"/home/buildd/mod-perl2/ModPerl-Registry/t/conf/modperl_extra_startup.pl") at 
perl.c:2887
#6  0x70a7d6a8 in modperl_require_file (my_perl=0x13ecb0, 
pv=0xfcec8 
"/home/buildd/mod-perl2/ModPerl-Registry/t/conf/modperl_extra_startup.pl", 
logfailure=1)
at modperl_util.c:48
#7  0x70a72d14 in modperl_config_apply_PerlRequire (s=0x84640, scfg=0xc8bc8, 
perl=0x13ecb0, p=0x7e0c8)
at modperl_config.c:427
#8  0x70a69e74 in modperl_startup (s=0x84640, p=0x7e0c8) at mod_perl.c:327
#9  0x70a6983c in modperl_startup (s=0x84640, p=0x7e0c8) at mod_perl.c:207
#10 0x70a6ba9c in modperl_init (base_server=0x84640, p=0x7e0c8) at 
mod_perl.c:458
#11 0x70a6c3c4 in modperl_hook_init (pconf=0x7e0c8, plog=0xb0190, 
ptemp=0xb2198, s=0x84640)
at mod_perl.c:631
#12 0x0003f620 in ap_run_open_logs ()
#13 0x0002ce8c in main ()

This report was generated by t/REPORT on Sat Mar  1 11:55:17 2008 GMT.

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]

Re: [mp2] Perl 5.10 fixes from SVN cause SIGBUS on sparc

2008-03-10 Thread Niko Tyni 
On Mon, Mar 10, 2008 at 12:06:54AM -0700, Philippe M. Chiasson wrote:

> Niko Tyni wrote:
> >We're switching to Perl 5.10 in Debian soon, and I'm trying to update the
> >mod_perl2 package to keep it working. Unfortunately the ModPerl-Registry
> >test suite is failing on the Sparc architecture because apache2 is killed
> >by a bus error (SIGBUS).

> Does this patch make the problem go away? (untested)

> -handler->attrs = *modperl_code_attrs(aTHX_ cv);
> +memcpy(&(handler->attrs),modperl_code_attrs(aTHX_ cv), 
> sizeof(handler->attrs));

No, unfortunately I can't see any change at all with this patch.
The backtrace looks just the same.
-- 
Niko Tyni   [EMAIL PROTECTED]

Re: [mp2] Perl 5.10 fixes from SVN cause SIGBUS on sparc

2008-03-12 Thread Niko Tyni 
On Mon, Mar 10, 2008 at 10:53:54PM -0700, Philippe M. Chiasson wrote:

> >>Niko Tyni wrote:
> >>>We're switching to Perl 5.10 in Debian soon, and I'm trying to update the
> >>>mod_perl2 package to keep it working. Unfortunately the ModPerl-Registry
> >>>test suite is failing on the Sparc architecture because apache2 is killed
> >>>by a bus error (SIGBUS).

> How about this s/U16/U32/ diff, basically keeping the flag type at U32,
> since it was not an essential part of the fix itself.

No, that doesn't help either.

It turns out the U16/U32 thing was a bad guess on my part. After
some code staring and debugging, I found the real bug. It's not
architecture-specific really, it just happens to bite worst on Sparc.

The non-void function modperl_thx_interp_get() function is doing a
plain 'return;' when it means to 'return NULL;'. The result is that the
MP_APR_POOL_SV_TAKES_OWNERSHIP() macro increments a more or less random
memory location, in this case my_perl->tScopestack aka. PL_scopestack,
making it non-aligned as a side effect.

Patch attached; this fixes the bus error for me.

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]
Index: src/modules/perl/modperl_interp.c
===
--- src/modules/perl/modperl_interp.c	(revision 635485)
+++ src/modules/perl/modperl_interp.c	(working copy)
@@ -581,7 +581,7 @@
 modperl_interp_t *interp;
 dTHXa(thx);
 SV **svp = hv_fetch(PL_modglobal, MP_THX_INTERP_KEY, strlen(MP_THX_INTERP_KEY), 0);
-if (!svp) return;
+if (!svp) return NULL;
 interp = INT2PTR(modperl_interp_t *, SvIV(*svp));
 return interp;
 }

Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1

2008-04-11 Thread Niko Tyni 
Philippe M. Chiasson wrote:

> The mod_perl 2.0.4 release candidate 1 "Works with Perl 5.10" is 
> ready. It can be downloaded here:
>
> http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz

Hi,

I can report that the test suite passes on current Debian unstable with
both Perl 5.8.8 and 5.10.0. 

However, with 5.10.0, the Apache2 server crashes on shutdown after the
test suite with a segmentation fault, which goes unnoticed by the build
system. The crash can be reproduced by running just two tests:

./t/TEST t/api/content_encoding.t t/modules/apache_status.t

This is a bug in Perl itself, it can be reduced to

 #!/usr/bin/perl -w
 use Compress::Zlib;
 use Devel::Symdump;
 print Devel::Symdump->isa_tree;
 __END__

which crashes for me on Perl 5.10.0 but not 5.8.8.

More details can be found at 

 http://rt.perl.org/rt3/Public/Bug/Display.html?id=52740

There's probably nothing mod_perl2 can or should do about this, but
I thought you'd want to know :)

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]

Re: segfault with perl 5.10 + MasonX::Request::WithApacheSession

2008-05-19 Thread Niko Tyni 
On Mon, May 19, 2008 at 11:12:08AM +0200, Louis-David Mitterrand wrote:

> Since I've upgraded to perl 5.10 on my debian unstable/sid box I get a 
> segfault when using MasonX::Request::WithApacheSession:
> 
>   [Sat May 17 16:14:55 2008] [notice] Apache/2.2.8 (Debian) 
> mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 configured -- resuming 
> normal operations
>   [Sat May 17 16:15:03 2008] [notice] child pid 25786 exit signal 
> Segmentation fault (11)
>   [Sat May 17 16:15:11 2008] [notice] child pid 25788 exit signal 
> Segmentation fault (11)
>   [Sat May 17 16:15:12 2008] [notice] child pid 25789 exit signal 
> Segmentation fault (11)

>   ## When commented out perl 5.10 works fine
>   request_class => 'MasonX::Request::WithApacheSession',

This looks very similar to <http://bugs.debian.org/480480>, Cc'd as
[EMAIL PROTECTED] . I just sent a stack backtrace there, no idea
yet if the fault is with perl or mod_perl2.

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]

Re: Bug#509457: [BUG] mod_perl2 test failures (when building Debian package)

2008-12-22 Thread Niko Tyni 
On Mon, Dec 22, 2008 at 10:47:18AM -0600, Gunnar Wolf wrote:

> I am a member of the Debian pkg-perl group [1]. I stumbled upon a test
> failure when rebuilding - For further information on my build
> environment, please refer to the bug report in the Debian BTS [2].
> 
> The test failure appears on hooks/authz.t:
> 
> Test Summary Report
> ---
> t/hooks/authz   (Wstat: 0 Tests: 4 Failed: 1)
> Failed test:  4

This broke when libwww-perl was upgraded from 5.813 to 5.820.
It still happens with the current version, 5.822.

This changelog entry seems relevant:

 2008-09-24  Release 5.815
 [...]
 Also thanks to contributions by Bron Gondwana LWP's Basic/Digest
 authenticate modules now registers handlers which allow them to
 automatically fill in the Authorization headers without first taking
 the round-trip of a 401 response when LWP knows the credentials for a
 given realm.

My limited understanding of this is that it's a bug in LWP: the
new handler installed by LWP::Authen::Basic::authenticate() uses
$ua->credentials() instead of $ua->get_basic_credentials(). However,
the LWP::UserAgent documentation recommends that subclasses override
just get_basic_credentials(), and that's what Apache::TestRequest
currently does.

The attached patch works around the problem by providing a credentials()
wrapper too. It's probably not quite correct, but the tests pass with
this on both libwww-perl 5.813 and 5.822.
-- 
Niko Tyni   nt...@debian.org
Index: Apache-Test/lib/Apache/TestRequest.pm
===
--- Apache-Test/lib/Apache/TestRequest.pm	(revision 28483)
+++ Apache-Test/lib/Apache/TestRequest.pm	(working copy)
@@ -256,6 +256,11 @@
 $self;
 }
 
+sub credentials {
+my $self = shift;
+return $self->get_basic_credentials(@_);
+}
+
 sub get_basic_credentials {
 my($self, $realm, $uri, $proxy) = @_;