Re: mod_perl2 and Perl 5.14 with uselargefiles on 32-bit architectures (was: Early core dump)
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
[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?
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
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
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
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
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
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
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
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)
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) = @_;