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