perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: need sanity check on my mod_perl + 2.4.6 on Windows attempt
Date Tue, 05 Nov 2013 19:01:14 GMT
On Tue, Nov 5, 2013 at 1:29 PM, Steve Hay <steve.m.hay@googlemail.com>wrote:

> On 5 November 2013 16:53, Jeff Trawick <trawick@gmail.com> wrote:
> > * Have existing 64-bit debug build of httpd/apr/etc. with VS 2012
> > * Checked out httpd24threading branch of mod_perl
> > * Have ActiveState 64-bit build of Perl 5.16.3 in PATH
> >
> > From a VS 2012 64-bit command prompt:
> >
> >> set MP_USE_MY_EXTUTILS_EMBED=1
> > (ActiveState ppm doesn't show the exact version requested as available.)
> >
> >> perl Makefile.PL MP_AP_PREFIX=%HOME%\PREFIXES\241
> > (and let it download apxs.bat et al)
> >> nmake
> >> nmake install
> >> nmake test
> >
> > ==> crash at httpd startup
> >
> > If I believe the Visual Studio debugger, it fails with a very basic
> linkage
> > issue -- mod_authz_core.so!add_authz_provider has non-NULL cmd_parms; it
> > calls perl_parse_require_line(), which the debugger believes has a NULL
> > cmd_parms.  And indeed it crashes at a place in
> modperl_interp_pool_select()
> > where a NULL pointer would be used, after making a bad decision based on
> the
> > NULL cmd_parms.
> >
> > Any guess on what to change first?
> >
>
> Using the 2.4.6 debug build which I just made (and currently working
> with a 5.18.1 debug perl build) I now have a working system! The
> KeepAliveTimeout problem has gone away, and so has my earlier problem
> of the api/add_config.t test crashing httpd.exe.
>
> Your build notes look fine. The crash you have sounds like the same as
> the call stack posted by Jan Kaluza (on Linux), but I'm not seeing
> that myself right now.
>
> The function your crash is in was new in the httpd24 branch, and it's
> one of things that I had to sort out when merging the threading branch
> into it. The threading branch changes the way that perl interpreters
> are managed in mod_perl, and I've tried to apply those changes to the
> functions since added in the httpd24 branch, but I've quite possibly
> not got it all right.
>
> What happens if you try the httpd24 branch? That worked (bar a few
> test failures) for Jan on Linux, but for me on Windows it crashed
> httpd.exe in api/add_config.t, with an error relating to interpreters
> and memory pools -- which is why I went down the road of merging the
> threading branch with the httpd24 branch, in the hope that it would
> fix my problem.
>

I get a lot further with the httpd24 branch.  Some tests run before a crash
during t\api\add_config.t.  (repeatable)

modperl_cleanup_pnotes() crashes on "*pnotes = NULL" when the pool for a
subrequest is destroyed.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Mime
View raw message