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:jkal...@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-unsubscr...@perl.apache.org For > > > additional commands, e-mail: dev-h...@perl.apache.org > > > > > > > >
