perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <Steve....@verosoftware.com>
Subject RE: [httpd24 branch] apr-ext crashes
Date Fri, 26 Jul 2013 07:55:05 GMT
APR.dll is indeed loaded and the boot function called, but APR_initialize() is a no-op because
MP_HAVE_APR_LIBS is oddly not defined.

That's set by get_DEFINE() in the top-level Makefile.PL and goes wrong because $build->apru_link_flags
is returning nothing. In a build of trunk against httpd-2.2 it returns " -L"C:\apache\lib"
-llibaprutil-1     -L"C:\apache\lib" -llibapr-1" as expected.

Knowing this now, I also realize that my changes to xs/APR/APR/Makefile.PL to use $build->apache_libs
instead of $build->apru_link_flags have been wrong. The real problem there was that apru_link_flags
is blank when it shouldn't be, and is also the problem here.

I will revert those other changes when I've worked out why apru_link_flags is coming out blank,
but right now I can't see why it works in trunk but not in httpd24. I will stare harder and
surely find it sooner or later...


> -----Original Message-----
> From: Jan Kaluza [mailto:jkaluza@redhat.com]
> Sent: 22 July 2013 14:01
> To: Steve Hay
> Cc: dev@perl.apache.org
> Subject: Re: [httpd24 branch] apr-ext crashes
> 
> Isn't APR.so loaded dynamically and boot_APR called after that?
> If it's like that, maybe APR.so is not loaded correctly on Windows?
> 
> ----- Original Message -----
> > apr_initialize is called in boot_APR in xs/APR/APR/APR.c, but I'm not
> > able to find out from where it is called...
> >
> > ----- Original Message -----
> > > Hm, maybe it's caused by the fact that apr_app_initialize is not
> > > called anywhere in the tests which don't run as part of mod_perl.
> > >
> > > I think it's not needed to call apr_app_initialize() in the tests
> > > which call apr_* methods on httpd's side (like in httpd handlers),
> > > but it's needed to call that method in the tests which run without
> > > httpd (like brigade.t).
> > >
> > > Jan Kaluza
> > >
> > > ----- Original Message -----
> > > > Jan Kaluza wrote on 2013-07-22:
> > > >  haven't finished with the other thread ( wrote on but I thought
> > > > I'd  start  new threads for discussing:
> > > > >> closely at apr-ext/brigade.t in a debug build. With the trunk
> > > > >> and
> > > > >> httpd-2.2 the script can be run at the command-line as
> > > > >>
> > > > >>   perl.exe -T -Iblib\arch -Iblib\lib -It\lib t\apr-ext
> > > > >> t\brigade.t but with the httpd24 branch and httpd-2.4 it
> > > > >> crashes in the
> > > > >> APR::Pool->new() call right at the start of test().
> > > > >>
> > > > >> In mpxs_apr_pool_create() I have a non-NULL parent_pool_obj
> but
> > > > >> the first line of the function,
> > > > >>
> > > > >>   apr_pool_t *parent_pool =
> mpxs_sv_object_deref(parent_pool_obj,
> > > > >>   apr_pool_t);
> > > > >> sets parent_pool to NULL, whence apr_pool_create() crashes
> > > > >> because it tries to dereference parent_pool.
> > > > >
> > > > > I think this is not true. In the test you mentioned, there's
> "my
> > > > > $p = APR::Pool->new();". parent_pool_obj in
> mpxs_apr_pool_create
> > > > > is not Perl object and that's the reason why
> > > > > mpxs_sv_object_deref returns NULL.
> > > > > However, this is still valid, because if you call
> > > > > apr_pool_create() with NULL parent, it creates new "root" pool
> (see [1]).
> > > > >
> > > > > Could you try to get full backtrace from this crash?
> > > > >
> > > >
> > > > See below. In fact, apr_pool_create_ex() contains this:
> > > >
> > > >     if (!parent)
> > > >         parent = global_pool;
> > > >
> > > > but global_pool is also NULL, so it still crashes when it
> reaches:
> > > >
> > > >     if (allocator == NULL)
> > > >         allocator = parent->allocator;
> > > >
> > > > Setting a breakpoint in apr_pool_initialize() shows it is not
> > > > getting called, which is presumably why global_pool is NULL.
> > > >
> > > >
> > > > >	libapr-1.dll!apr_pool_create_ex(apr_pool_t * * newpool,
> apr_pool_t *
> > > > >	parent, int (int)* abort_fn, apr_allocator_t * allocator)
> Line 889 +
> > > > >	0x3
> > > > >	bytes	C
> > > >  	Pool.dll!mpxs_apr_pool_create(interpreter * my_perl, sv *
> > > >  	parent_pool_obj)
> > > >  	Line 170	C
> > > >  	Pool.dll!XS_APR__Pool_new(interpreter * my_perl, cv * cv)
> Line 123 +
> > > >  	0xd
> > > >  	bytes	C
> > > >  	perl518.dll!Perl_pp_entersub(interpreter * my_perl)  Line
> 2875 + 0x12
> > > >  	bytes
> > > >  		C
> > > >  	perl518.dll!Perl_runops_debug(interpreter * my_perl)  Line
> 2213 + 0xf
> > > >  	bytes
> > > >  		C
> > > >  	perl518.dll!S_run_body(interpreter * my_perl, long
> oldscope)  Line 2467
> > > >  	+
> > > >  	0xf bytes	C
> > > >  	perl518.dll!perl_run(interpreter * my_perl)  Line 2386
> 	C
> > > >  	perl518.dll!RunPerl(int argc, char * * argv, char * * env)
> Line 270 +
> > > >  	0x9
> > > >  	bytes	C
> > > >  	perl.exe!main(int argc, char * * argv, char * * env)  Line
> 23 + 0x12
> > > >  	bytes
> > > >  		C
> > > >  	perl.exe!__tmainCRTStartup()  Line 555 + 0x17 bytes	C
> > > >  	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes
> > > >  	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes
> > > >  	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes
> > > >
> > > >
> > >
> > > -------------------------------------------------------------------
> -
> > > - To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org For
> > > additional commands, e-mail: dev-help@perl.apache.org
> > >
> > >
> >
Mime
View raw message