Mailing List Archive

----- Original Message -----
> I haven't finished with the other thread ("[httpd24 branch] merge with
> trunk?") yet, but I thought I'd start new threads for discussing specific
> test failures...
>
> The apr-ext tests are crashing perl.exe for me. I've looked more 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?

[1] http://apr.apache.org/docs/apr/1.4/group__apr__pools.html#ga918adf3026c894efeae254a0446aed3b

> Any suggestions where the problem might lie would be very welcome while I
> scratch my head over it...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
>

Regards,
Jan Kaluza

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

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

B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™P\›˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[\›˜\XÚK›Ü™ÃB

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

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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

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
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

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
> > >
> > >
> >
ТÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÒÐÐ¥FòVç7V'67&–&RÂRÖÖ–âFWb×Vç7V'67&–&TW&Âæ6†Ræ÷&pФf÷"FF—F–öæÂ6öÖÖæG2ÂRÖÖ–âFWbÖ†VÇW&Âæ6†Ræ÷&pÐ

Ok, I've found the problem: Apache2::Build::apr_generation() is now returning 2 instead of 1, but the apxs scripts on Windows are still called ap[ru]-1-config.bat.

I could easily tweak apr_generation() to account for that, but I guess the correct fix is to change apxs on Windows?

Where does apxs come from on *nix? On Windows I've long used the one at
http://perl.apache.org/dist/win32-bin/apxs_win32-0.6.tar.gz
with a minor (local) change to line 107 of apxs_win32. Really I'd like to put out a 0.7, but I've no idea how to create
http://perl.apache.org/dist/win32-bin/apxs_win32-0.7.tar.gz

Shall I make a 0.7 and put it in, say, http://people.apache.org/~stevehay/, for now, and then look at updating the perl.apache.org location later if someone knows how to?


> -----Original Message-----
> From: Steve Hay [mailto:Steve.Hay@verosoftware.com]
> Sent: 26 July 2013 08:55
> To: Jan Kaluza
> Cc: dev@perl.apache.org
> Subject: RE: [httpd24 branch] apr-ext crashes
>
> 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
> > > >
> > > >
> > >
>
> -----------------------
> ssi,-i vnbree.aer
> rdtn mn,-i ve@rac.g
B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™P\›˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[\›˜\XÚK›Ü™ÃB

On 07/29/2013 10:54 AM, Steve Hay wrote:
> Ok, I've found the problem: Apache2::Build::apr_generation() is now returning 2 instead of 1, but the apxs scripts on Windows are still called ap[ru]-1-config.bat.
>
> I could easily tweak apr_generation() to account for that, but I guess the correct fix is to change apxs on Windows?

Hm, I build it with following options on Linux, so I presume it skips
this check:
MP_APXS=/usr/bin/apxs \
MP_APR_CONFIG=%{_bindir}/apr-1-config

After discussion with Joe Orton I think it would be better to use APR
generation 1 even for httpd-2.4, so the proper fix would be to change
apr_generation() method to return 1. Httpd-2.4 is still intended to be
compiled with APR-1.x. Maybe in the past it was not like that and
therefore we have that code there, but current state is like I said.

> Where does apxs come from on *nix? On Windows I've long used the one at
> http://perl.apache.org/dist/win32-bin/apxs_win32-0.6.tar.gz
> with a minor (local) change to line 107 of apxs_win32. Really I'd like to put out a 0.7, but I've no idea how to create
> http://perl.apache.org/dist/win32-bin/apxs_win32-0.7.tar.gz

It's normally built together with httpd (since 'apxs' is part of httpd
source code) and then include in Linux (Fedora/Debian/...) binary package.

> Shall I make a 0.7 and put it in, say, http://people.apache.org/~stevehay/, for now, and then look at updating the perl.apache.org location later if someone knows how to?
>
>

I don't know what changed in apxs between 2.2 and 2.4. I would just try
if it compiles with apr_generation() returning 1 and if it does, then
you probably don't have to do anything.

Regards,
Jan Kaluza



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Jan Kaluža wrote on 2013-07-29:
> On 07/29/2013 10:54 AM, Steve Hay wrote:
>> Ok, I've found the problem: Apache2::Build::apr_generation() is now
> returning 2 instead of 1, but the apxs scripts on Windows are still
> called ap[ru]-1-config.bat.
>>
>> I could easily tweak apr_generation() to account for that, but I
> guess the correct fix is to change apxs on Windows?
>
> Hm, I build it with following options on Linux, so I presume it skips
> this check:
> MP_APXS=/usr/bin/apxs \
> MP_APR_CONFIG=%{_bindir}/apr-1-config
> After discussion with Joe Orton I think it would be better to use APR
> generation 1 even for httpd-2.4, so the proper fix would be to change
> apr_generation() method to return 1. Httpd-2.4 is still intended to be
> compiled with APR-1.x. Maybe in the past it was not like that and
> therefore we have that code there, but current state is like I said.
>

Ok, with revs 1222775 (apr_generation() change), 1448043 and 1503135 (aprutil-1 changes) all reverted the build now works for me and the apr-ext tests no longer crash. The attached patch effects these three reverts.

Does this work for you? It reverts the "FIXME" for finding aprutil-1 which you added in rev 1448043, but I wonder if that was unnecessary?:- Maybe if you don't pass MP_APR_CONFIG then it will work fine for you, given that apr_generation() now does the right thing? Or failing that, passing MP_APU_CONFIG as well should locate aprutil-1?

If these changes are ok then I will commit them and continue looking at what else is wrong here on Windows...

I still have the problem of needing to put the httpd bin and mod_perl.so paths in my PATH, plus I need to pull in the latest Apache-Test changes (specifically, rev 1504090) for the httpd.conf generation to work correctly. How do I pull that into modperl?

Otherwise, my test failure list is now down to:

Test Summary Report
-------------------
t\apache\subprocess.t (Wstat: 0 Tests: 1 Failed: 0)
Parse errors: Bad plan. You planned 5 tests but ran 1.
t\api\access2_24.t (Wstat: 0 Tests: 6 Failed: 3)
Failed tests: 2, 5-6
t\api\err_headers_out.t (Wstat: 0 Tests: 6 Failed: 3)
Failed tests: 2-3, 5
t\compat\conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
Parse errors: Bad plan. You planned 4 tests but ran 2.
t\hooks\authen_digest.t (Wstat: 0 Tests: 7 Failed: 4)
Failed tests: 4-7
t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 6
t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
Failed tests: 3, 6, 9
t\modperl\merge2.t (Wstat: 0 Tests: 10 Failed: 3)
Failed tests: 3, 6, 9
t\modperl\merge3.t (Wstat: 0 Tests: 10 Failed: 3)
Failed tests: 3, 6, 9
t\modperl\setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
Failed tests: 17-23
t\modules\cgi.t (Wstat: 0 Tests: 5 Failed: 5)
Failed tests: 1-5
t\modules\cgi2.t (Wstat: 0 Tests: 5 Failed: 5)
Failed tests: 1-5
t\modules\cgipost.t (Wstat: 0 Tests: 6 Failed: 5)
Failed tests: 2-6
t\modules\cgipost2.t (Wstat: 0 Tests: 6 Failed: 5)
Failed tests: 2-6
t\modules\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
Failed tests: 1-2
t\modules\cgiupload2.t (Wstat: 0 Tests: 2 Failed: 2)
Failed tests: 1-2
t\protocol\echo_block.t (Wstat: 0 Tests: 3 Failed: 2)
Failed tests: 2-3
t\protocol\echo_nonblock.t (Wstat: 0 Tests: 3 Failed: 1)
Failed test: 2
t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
Failed tests: 2-5
t\protocol\pseudo_http.t (Wstat: 0 Tests: 13 Failed: 9)
Failed tests: 3-8, 11-13
Files=249, Tests=2468, 801 wallclock secs ( 2.15 usr + 0.28 sys = 2.43 CPU)
Result: FAIL
Failed 20/249 test programs. 67/2468 subtests failed.

On 07/29/2013 04:59 PM, Steve Hay wrote:
> Jan Kaluža wrote on 2013-07-29:
>> On 07/29/2013 10:54 AM, Steve Hay wrote:
>>> Ok, I've found the problem: Apache2::Build::apr_generation() is now
>> returning 2 instead of 1, but the apxs scripts on Windows are still
>> called ap[ru]-1-config.bat.
>>>
>>> I could easily tweak apr_generation() to account for that, but I
>> guess the correct fix is to change apxs on Windows?
>>
>> Hm, I build it with following options on Linux, so I presume it skips
>> this check:
>> MP_APXS=/usr/bin/apxs \
>> MP_APR_CONFIG=%{_bindir}/apr-1-config
>> After discussion with Joe Orton I think it would be better to use APR
>> generation 1 even for httpd-2.4, so the proper fix would be to change
>> apr_generation() method to return 1. Httpd-2.4 is still intended to be
>> compiled with APR-1.x. Maybe in the past it was not like that and
>> therefore we have that code there, but current state is like I said.
>>
>
> Ok, with revs 1222775 (apr_generation() change), 1448043 and 1503135 (aprutil-1 changes) all reverted the build now works for me and the apr-ext tests no longer crash. The attached patch effects these three reverts.
>
> Does this work for you? It reverts the "FIXME" for finding aprutil-1 which you added in rev 1448043, but I wonder if that was unnecessary?:- Maybe if you don't pass MP_APR_CONFIG then it will work fine for you, given that apr_generation() now does the right thing? Or failing that, passing MP_APU_CONFIG as well should locate aprutil-1?

With this patch everything works for me as expected, so you can commit
it :).

> If these changes are ok then I will commit them and continue looking at what else is wrong here on Windows...
>
> I still have the problem of needing to put the httpd bin and mod_perl.so paths in my PATH, plus I need to pull in the latest Apache-Test changes (specifically, rev 1504090) for the httpd.conf generation to work correctly. How do I pull that into modperl?

I have done that in r1508317. If you would like to change it again in
the future, it can be changed by "svn propedit svn:externals ."

> Otherwise, my test failure list is now down to:
>
> Test Summary Report
> -------------------
> t\apache\subprocess.t (Wstat: 0 Tests: 1 Failed: 0)
> Parse errors: Bad plan. You planned 5 tests but ran 1.
> t\api\access2_24.t (Wstat: 0 Tests: 6 Failed: 3)
> Failed tests: 2, 5-6
> t\api\err_headers_out.t (Wstat: 0 Tests: 6 Failed: 3)
> Failed tests: 2-3, 5
> t\compat\conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
> Parse errors: Bad plan. You planned 4 tests but ran 2.
> t\hooks\authen_digest.t (Wstat: 0 Tests: 7 Failed: 4)
> Failed tests: 4-7
> t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
> Failed test: 6
> t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
> Failed tests: 3, 6, 9
> t\modperl\merge2.t (Wstat: 0 Tests: 10 Failed: 3)
> Failed tests: 3, 6, 9
> t\modperl\merge3.t (Wstat: 0 Tests: 10 Failed: 3)
> Failed tests: 3, 6, 9
> t\modperl\setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
> Failed tests: 17-23
> t\modules\cgi.t (Wstat: 0 Tests: 5 Failed: 5)
> Failed tests: 1-5
> t\modules\cgi2.t (Wstat: 0 Tests: 5 Failed: 5)
> Failed tests: 1-5
> t\modules\cgipost.t (Wstat: 0 Tests: 6 Failed: 5)
> Failed tests: 2-6
> t\modules\cgipost2.t (Wstat: 0 Tests: 6 Failed: 5)
> Failed tests: 2-6
> t\modules\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
> Failed tests: 1-2
> t\modules\cgiupload2.t (Wstat: 0 Tests: 2 Failed: 2)
> Failed tests: 1-2
> t\protocol\echo_block.t (Wstat: 0 Tests: 3 Failed: 2)
> Failed tests: 2-3
> t\protocol\echo_nonblock.t (Wstat: 0 Tests: 3 Failed: 1)
> Failed test: 2
> t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
> Failed tests: 2-5
> t\protocol\pseudo_http.t (Wstat: 0 Tests: 13 Failed: 9)
> Failed tests: 3-8, 11-13
> Files=249, Tests=2468, 801 wallclock secs ( 2.15 usr + 0.28 sys = 2.43 CPU)
> Result: FAIL
> Failed 20/249 test programs. 67/2468 subtests failed.
>

I still have only the expected subset with your apr.patch:

t/compat/conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
Parse errors: Bad plan. You planned 4 tests but ran 2.
t/modules/cgi.t (Wstat: 0 Tests: 5 Failed: 2)
Failed tests: 2, 5
t/modules/cgi2.t (Wstat: 0 Tests: 5 Failed: 1)
Failed test: 3
t/modules/cgipost.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 4
t/modules/cgipost2.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test: 1
t/modules/cgiupload2.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test: 2


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

Jan Kaluža wrote on 2013-07-30:
> On 07/29/2013 04:59 PM, Steve Hay wrote:
>> Jan Kaluža wrote on 2013-07-29:
>>> On 07/29/2013 10:54 AM, Steve Hay wrote:
>>>> Ok, I've found the problem: Apache2::Build::apr_generation() is
>>>> now
>>> returning 2 instead of 1, but the apxs scripts on Windows are still
>>> called ap[ru]-1-config.bat.
>>>>
>>>> I could easily tweak apr_generation() to account for that, but I
>>> guess the correct fix is to change apxs on Windows?
>>>
>>> Hm, I build it with following options on Linux, so I presume it skips
>>> this check:
>>> MP_APXS=/usr/bin/apxs \
>>> MP_APR_CONFIG=%{_bindir}/apr-1-config
>>> After discussion with Joe Orton I think it would be better to use APR
>>> generation 1 even for httpd-2.4, so the proper fix would be to change
>>> apr_generation() method to return 1. Httpd-2.4 is still intended to be
>>> compiled with APR-1.x. Maybe in the past it was not like that and
>>> therefore we have that code there, but current state is like I said.
>>>
>>
>> Ok, with revs 1222775 (apr_generation() change), 1448043 and 1503135
> (aprutil-1 changes) all reverted the build now works for me and the
> apr-ext tests no longer crash. The attached patch effects these three
> reverts.
>>
>> Does this work for you? It reverts the "FIXME" for finding aprutil-1
> which you added in rev 1448043, but I wonder if that was
> unnecessary?:- Maybe if you don't pass MP_APR_CONFIG then it will work
> fine for you, given that apr_generation() now does the right thing? Or
> failing that, passing MP_APU_CONFIG as well should locate aprutil-1?
>
> With this patch everything works for me as expected, so you can commit
> it :).


Thanks for testing. Committed in rev. 1508326.


>
>> If these changes are ok then I will commit them and continue looking at
>> what else is wrong here on Windows...
>>
>> I still have the problem of needing to put the httpd bin and
> mod_perl.so paths in my PATH, plus I need to pull in the latest
> Apache- Test changes (specifically, rev 1504090) for the httpd.conf
> generation to work correctly. How do I pull that into modperl?
>
> I have done that in r1508317. If you would like to change it again in
> the future, it can be changed by "svn propedit svn:externals ."


Great! Thanks.

It's actually only the path to mod_perl.so that I need to add to the PATH, which I'd determined previously was due to the new dependency (now in ModPerl/Const/Const.dll) on mod_perl.so for the perl_module symbol.

I'll look at that again, or else just work around it for now by adding to the PATH in the top-level Makefile.PL's MY::test().

Then I can get on to looking at the tests which fail on Windows but pass for you...


>
>> Otherwise, my test failure list is now down to:
>>
>> Test Summary Report
>> -------------------
>> t\apache\subprocess.t (Wstat: 0 Tests: 1 Failed: 0)
>> Parse errors: Bad plan. You planned 5 tests but ran 1.
>> t\api\access2_24.t (Wstat: 0 Tests: 6 Failed: 3)
>> Failed tests: 2, 5-6 t\api\err_headers_out.t (Wstat:
>> 0 Tests: 6 Failed: 3) Failed tests: 2-3, 5 t\compat\conn_rec.t
>> (Wstat: 0 Tests: 2 Failed: 0) Parse errors: Bad plan.
>> You planned 4 tests but ran 2. t\hooks\authen_digest.t
>> (Wstat: 0 Tests: 7 Failed: 4) Failed tests: 4-7
>> t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
>> Failed test: 6 t\modperl\merge.t (Wstat: 0
>> Tests: 10 Failed: 3) Failed tests: 3, 6, 9 t\modperl\merge2.t
>> (Wstat: 0 Tests: 10 Failed: 3) Failed tests: 3, 6, 9
>> t\modperl\merge3.t (Wstat: 0 Tests: 10 Failed: 3)
>> Failed tests: 3, 6, 9 t\modperl\setupenv2.t (Wstat:
>> 0 Tests: 23 Failed: 7) Failed tests: 17-23 t\modules\cgi.t
>> (Wstat: 0 Tests: 5 Failed: 5) Failed tests: 1-5
>> t\modules\cgi2.t (Wstat: 0 Tests: 5 Failed: 5)
>> Failed tests: 1-5 t\modules\cgipost.t (Wstat: 0
>> Tests: 6 Failed: 5) Failed tests: 2-6 t\modules\cgipost2.t
>> (Wstat: 0 Tests: 6 Failed: 5) Failed tests: 2-6
>> t\modules\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
>> Failed tests: 1-2 t\modules\cgiupload2.t (Wstat: 0
>> Tests: 2 Failed: 2) Failed tests: 1-2 t\protocol\echo_block.t
>> (Wstat: 0 Tests: 3 Failed: 2) Failed tests: 2-3
>> t\protocol\echo_nonblock.t (Wstat: 0 Tests: 3 Failed: 1)
>> Failed test: 2 t\protocol\echo_timeout.t (Wstat: 0
>> Tests: 5 Failed: 4) Failed tests: 2-5 t\protocol\pseudo_http.t
>> (Wstat: 0 Tests: 13 Failed: 9) Failed tests: 3-8, 11-13
>> Files=249, Tests=2468, 801 wallclock secs ( 2.15 usr + 0.28 sys =
>> 2.43 CPU)
>> Result: FAIL
>> Failed 20/249 test programs. 67/2468 subtests failed.
>>
>
> I still have only the expected subset with your apr.patch:
>
> t/compat/conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
> Parse errors: Bad plan. You planned 4 tests but ran 2.
> t/modules/cgi.t (Wstat: 0 Tests: 5 Failed: 2)
> Failed tests: 2, 5 t/modules/cgi2.t (Wstat: 0
> Tests: 5 Failed: 1) Failed test: 3 t/modules/cgipost.t
> (Wstat: 0 Tests: 6 Failed: 1) Failed test: 4
> t/modules/cgipost2.t (Wstat: 0 Tests: 6 Failed: 1)
> Failed test: 4 t/modules/cgiupload.t (Wstat: 0
> Tests: 2 Failed: 1) Failed test: 1 t/modules/cgiupload2.t
> (Wstat: 0 Tests: 2 Failed: 1) Failed test: 2



B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È[œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™P\›˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ]‹Z[\›˜\XÚK›Ü™ÃB

Steve Hay wrote on 2013-07-30:
> It's actually only the path to mod_perl.so that I need to add to the
> PATH, which I'd determined previously was due to the new dependency (now
> in ModPerl/Const/Const.dll) on mod_perl.so for the perl_module symbol.
>
> I'll look at that again, or else just work around it for now by adding
> to the PATH in the top-level Makefile.PL's MY::test().
>

For the record, I have now committed that "workaround" in rev. 1509781 after deciding that it's fine, not just a nasty hack. The commit message hopefully describes my reasoning adequately:

"Add the path to mod_perl.so to the PATH when running the test suite on Windows

Httpd.exe is able to find mod_perl.so because the test httpd.conf contains a LoadModule line with the fully qualified path to mod_perl.so in it. However, before httpd.exe is started the test framework must create that httpd.conf file. In the case of mod_perl it uses perl.exe and goes into Apache/TestConfigPerl.pm's run_apache_test_configure(), which runs APACHE_TEST_CONFIGURE() in various modules in t/response/TestApache (e.g. subprocess.pm). Those modules all use Apache2::Const, but Apache2/Const/Const.dll and ModPerl/Const/Const.dll now depend on mod_perl.so for the 'perl_module' symbol. Therefore, perl.exe must be able to find mod_perl.so when running the tests, and this is the easiest way to achieve that.

There is no problem with Apache2::Const and ModPerl::Const depending on mod_perl.so because they are normally only used within a mod_perl application, which will (obviously) have mod_perl.so loaded already. (It is only the APR::* modules which we are at pains (elsewhere) to avoid having a dependency on mod_perl.so because they are of use outside of mod_perl applications.)"

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org

On 08/02/2013 07:10 PM, Steve Hay wrote:
> Steve Hay wrote on 2013-07-30:
>> It's actually only the path to mod_perl.so that I need to add to the
>> PATH, which I'd determined previously was due to the new dependency (now
>> in ModPerl/Const/Const.dll) on mod_perl.so for the perl_module symbol.
>>
>> I'll look at that again, or else just work around it for now by adding
>> to the PATH in the top-level Makefile.PL's MY::test().
>>
>
> For the record, I have now committed that "workaround" in rev. 1509781 after deciding that it's fine, not just a nasty hack. The commit message hopefully describes my reasoning adequately:
>
> "Add the path to mod_perl.so to the PATH when running the test suite on Windows
>
> Httpd.exe is able to find mod_perl.so because the test httpd.conf contains a LoadModule line with the fully qualified path to mod_perl.so in it. However, before httpd.exe is started the test framework must create that httpd.conf file. In the case of mod_perl it uses perl.exe and goes into Apache/TestConfigPerl.pm's run_apache_test_configure(), which runs APACHE_TEST_CONFIGURE() in various modules in t/response/TestApache (e.g. subprocess.pm). Those modules all use Apache2::Const, but Apache2/Const/Const.dll and ModPerl/Const/Const.dll now depend on mod_perl.so for the 'perl_module' symbol. Therefore, perl.exe must be able to find mod_perl.so when running the tests, and this is the easiest way to achieve that.
>
> There is no problem with Apache2::Const and ModPerl::Const depending on mod_perl.so because they are normally only used within a mod_perl application, which will (obviously) have mod_perl.so loaded already. (It is only the APR::* modules which we are at pains (elsewhere) to avoid having a dependency on mod_perl.so because they are of use outside of mod_perl applications.)"
>

That makes sense. I have also tested httpd24 branch again and it's still
working as expected for me.

Jan Kaluza


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org