Re: Experimental C unit test suite available for hacking

[Jacob Champion]

On 05/23/2018 10:32 AM, Marion et Christophe JAILLET wrote:
> '--with-test-suite=...' is for the Perl test framework, not for the
> 'test/httpdunit'.

Ah, yes! Thanks for the reminder; --with-test-suite only enables the 
`make check` functionality. Sorry, it's been too long.


On 05/23/2018 01:21 PM, Christophe Jaillet wrote:
I can reproduce the issue if I don't pass any --enable-mpms-shared 
paramater to ./configure.


Me too. The problem, I think, is that the $(MPM_LIB) depends on symbols 
in server/libmain.la, but comes after it in the $(PROGRAM_DEPENDENCIES). 
That won't work. Moving $(MPM_LIB) up above server/libmain.la in the 
top-level Makefile.in seems to solve the problem for me, but I'm not 
able to sufficiently test tonight to make sure it doesn't break 
something else. HTH?


--Jacob

Re: Experimental C unit test suite available for hacking

[Christophe Jaillet]

Le 23/05/2018 à 20:52, Micha Lenk a écrit :

Am 23.05.2018 um 20:18 schrieb Marion et Christophe JAILLET:

Could you please try to 'make clean' and 'make' to see if you still have
the build issue?


No change. :(

Regards,
Micha

I can reproduce the issue if I don't pass any --enable-mpms-shared 
paramater to ./configure.

Having --with-mpm=xx only also triggers the building issue.

What is your ./configure command line?
Can you try to add --enable-mpms-shared=event (or =all) and re-configure 
and build?


CJ

Re: Experimental C unit test suite available for hacking

[Micha Lenk]

Am 23.05.2018 um 20:18 schrieb Marion et Christophe JAILLET:
> Could you please try to 'make clean' and 'make' to see if you still have
> the build issue?

No change. :(

Regards,
Micha

Re: Experimental C unit test suite available for hacking

[Marion et Christophe JAILLET]

Le 23/05/2018 à 14:48, Micha Lenk a écrit :

On 05/25/2017 11:44 PM, Jacob Champion wrote (almost a year ago):
Last week I had a personal hackathon since I couldn't make it out to 
ApacheCon. As a result there is now a C-language unit test suite 
available in branches/httpdunit (based on trunk). I've tested it with 
a Windows+CMake toolchain as well as an Ubuntu+autoconf toolchain.


The suite itself is based on Check, which is a testing library I've 
had some success with in the past. It's supported on a wide variety 
of platforms and has a nice feature of running each test in a 
separate process space, so a crash doesn't derail the entire suite. 
(Note: Check is LGPL.) The build system has been augmented slightly 
to generate some of the more tedious boilerplate code.


If you want to give it a try, just install Check (and, if using the 
configure scripts, make sure Check is visible via pkg-config). The 
test suite will then automatically be added to the default targets. 
Once everything builds you just run the suite directly with


 $ ./test/httpdunit

As a Check binary, it has multiple knobs to control which tests run 
and how the reporting is done, but by default it just runs all the 
tests and prints TAP to stdout.


The example tests that are currently running are testing a new API 
for strict Base64 decoding. Right now it's a feature without a 
client; I included it here because it was a good showcase of the test 
suite (see test/unit/base64.c for the test case code).


Let me know what you think!


I totally like the idea of having unit tests for httpd, so thanks a 
lot for adding them!


I recently struggled compiling trunk locally on Debian 9.4 because of 
these unit tests. Apparently it fails to link test/httpdunit because 
of undefined references to ap_queue_info_push_pool and other symbols. 
See the attached build log for more details.


Does anybody have an idea what went wrong? Am I missing something?
How does buildbot build?

Best regards,
Micha

Hi,
did you try to make a 'make clean'?
As explained in another message, 'test/httpdunit' is built if the 
'check' library is found on the system. However, the .o files don't seem 
to be updated when the code of httpd is updated. So the (previous) .o 
files could have references to some functions that do not exists any more.


Could you please try to 'make clean' and 'make' to see if you still have 
the build issue?


CJ

Re: Experimental C unit test suite available for hacking

[Marion et Christophe JAILLET]

Le 23/05/2018 à 16:14, Micha Lenk a écrit :

Hi Eric,

On 05/23/2018 02:59 PM, Eric Covener wrote:
I guess the CI setup needs to be updated to at least build the unit 
tests?


I did not configure the build explicitly to run the unit tests, so it 
is just the plain "make" that causes this target to get build. I would 
expect the CI setup to implicitly build it as well. Yes, no?!


Does the target 'test/httpdunit' not get build in your local builds?

Cheers,
Micha Lenk


'test/httpdunit' is always built in my dev machine.

This is added automatically to the 'other_target' if the 'check' library 
(>= version 0.9.12) is found on the system at configuration time.

CJ

Re: Experimental C unit test suite available for hacking

[Marion et Christophe JAILLET]

Le 23/05/2018 à 16:21, Joe Orton a écrit :

On Wed, May 23, 2018 at 04:14:39PM +0200, Micha Lenk wrote:

Hi Eric,

On 05/23/2018 02:59 PM, Eric Covener wrote:

I guess the CI setup needs to be updated to at least build the unit tests?

I did not configure the build explicitly to run the unit tests, so it is
just the plain "make" that causes this target to get build. I would expect
the CI setup to implicitly build it as well. Yes, no?!

Does the target 'test/httpdunit' not get build in your local builds?

It should only get built if you configure --with-test-suite=... and
specify the path to a perl-framework wc.  It builds for me in trunk.

Regards, Joe


Hi,

'--with-test-suite=...' is for the Perl test framework, not for the 
'test/httpdunit'.
'test/httpdunit' is designed for unit tests, written in C, and is included in 
trunk.

Up to now, there is not that much in it, but at least a framework is available.

CJ

Re: Experimental C unit test suite available for hacking

[Jacob Champion]

On Wed, May 23, 2018, 7:35 AM Micha Lenk  wrote:

> > It should only get built if you configure --with-test-suite=... and
> > specify the path to a perl-framework wc.  It builds for me in trunk.
>
> Hmm, no difference. It seems to get built independent from whether you
> specify --with-test-suite or not. As a cross check I've just added
> "--with-test-suite=../httpd-test" to the configure flags, but I still
> get the same build failure.
>

Hi Micha, thanks for your interest! I won't be able to debug into this
until later in the day, but I'll try to take a look.

You asked about buildbot -- IIRC, several pieces of the test suite don't
run there, but it's been months since I last looked.

--Jacob

>

Re: Experimental C unit test suite available for hacking

[Micha Lenk]

Hi Joe,

On 05/23/2018 04:21 PM, Joe Orton wrote:

On Wed, May 23, 2018 at 04:14:39PM +0200, Micha Lenk wrote:

Hi Eric,

On 05/23/2018 02:59 PM, Eric Covener wrote:

I guess the CI setup needs to be updated to at least build the unit tests?


I did not configure the build explicitly to run the unit tests, so it is
just the plain "make" that causes this target to get build. I would expect
the CI setup to implicitly build it as well. Yes, no?!

Does the target 'test/httpdunit' not get build in your local builds?


It should only get built if you configure --with-test-suite=... and
specify the path to a perl-framework wc.  It builds for me in trunk.


Hmm, no difference. It seems to get built independent from whether you 
specify --with-test-suite or not. As a cross check I've just added 
"--with-test-suite=../httpd-test" to the configure flags, but I still 
get the same build failure.


Regards,
Micha

Re: Experimental C unit test suite available for hacking

[Joe Orton]

On Wed, May 23, 2018 at 04:14:39PM +0200, Micha Lenk wrote:
> Hi Eric,
> 
> On 05/23/2018 02:59 PM, Eric Covener wrote:
> > I guess the CI setup needs to be updated to at least build the unit tests?
> 
> I did not configure the build explicitly to run the unit tests, so it is
> just the plain "make" that causes this target to get build. I would expect
> the CI setup to implicitly build it as well. Yes, no?!
> 
> Does the target 'test/httpdunit' not get build in your local builds?

It should only get built if you configure --with-test-suite=... and 
specify the path to a perl-framework wc.  It builds for me in trunk.

Regards, Joe

Re: Experimental C unit test suite available for hacking

[Micha Lenk]

Hi Eric,

On 05/23/2018 02:59 PM, Eric Covener wrote:

I guess the CI setup needs to be updated to at least build the unit tests?


I did not configure the build explicitly to run the unit tests, so it is 
just the plain "make" that causes this target to get build. I would 
expect the CI setup to implicitly build it as well. Yes, no?!


Does the target 'test/httpdunit' not get build in your local builds?

Cheers,
Micha Lenk

Re: Experimental C unit test suite available for hacking

[Eric Covener]

On Wed, May 23, 2018 at 8:48 AM, Micha Lenk  wrote:
> On 05/25/2017 11:44 PM, Jacob Champion wrote (almost a year ago):
>>
>> Last week I had a personal hackathon since I couldn't make it out to
>> ApacheCon. As a result there is now a C-language unit test suite available
>> in branches/httpdunit (based on trunk). I've tested it with a Windows+CMake
>> toolchain as well as an Ubuntu+autoconf toolchain.
>>
>> The suite itself is based on Check, which is a testing library I've had
>> some success with in the past. It's supported on a wide variety of platforms
>> and has a nice feature of running each test in a separate process space, so
>> a crash doesn't derail the entire suite. (Note: Check is LGPL.) The build
>> system has been augmented slightly to generate some of the more tedious
>> boilerplate code.
>>
>> If you want to give it a try, just install Check (and, if using the
>> configure scripts, make sure Check is visible via pkg-config). The test
>> suite will then automatically be added to the default targets. Once
>> everything builds you just run the suite directly with
>>
>>  $ ./test/httpdunit
>>
>> As a Check binary, it has multiple knobs to control which tests run and
>> how the reporting is done, but by default it just runs all the tests and
>> prints TAP to stdout.
>>
>> The example tests that are currently running are testing a new API for
>> strict Base64 decoding. Right now it's a feature without a client; I
>> included it here because it was a good showcase of the test suite (see
>> test/unit/base64.c for the test case code).
>>
>> Let me know what you think!
>
>
> I totally like the idea of having unit tests for httpd, so thanks a lot for
> adding them!
>
> I recently struggled compiling trunk locally on Debian 9.4 because of these
> unit tests. Apparently it fails to link test/httpdunit because of undefined
> references to ap_queue_info_push_pool and other symbols. See the attached
> build log for more details.
>
> Does anybody have an idea what went wrong? Am I missing something?
> How does buildbot build?

I think there was a subsequent change to factor some of the shared
queue stuff out of event/worker, probably missing just a few
additional targets now.

I guess the CI setup needs to be updated to at least build the unit tests?

Re: Experimental C unit test suite available for hacking

[Graham Leggett]

On 25 May 2017, at 11:44 PM, Jacob Champion  wrote:

> Last week I had a personal hackathon since I couldn't make it out to 
> ApacheCon. As a result there is now a C-language unit test suite available in 
> branches/httpdunit (based on trunk). I've tested it with a Windows+CMake 
> toolchain as well as an Ubuntu+autoconf toolchain.
> 
> The suite itself is based on Check, which is a testing library I've had some 
> success with in the past. It's supported on a wide variety of platforms and 
> has a nice feature of running each test in a separate process space, so a 
> crash doesn't derail the entire suite. (Note: Check is LGPL.) The build 
> system has been augmented slightly to generate some of the more tedious 
> boilerplate code.
> 
> If you want to give it a try, just install Check (and, if using the configure 
> scripts, make sure Check is visible via pkg-config). The test suite will then 
> automatically be added to the default targets. Once everything builds you 
> just run the suite directly with
> 
>$ ./test/httpdunit
> 
> As a Check binary, it has multiple knobs to control which tests run and how 
> the reporting is done, but by default it just runs all the tests and prints 
> TAP to stdout.
> 
> The example tests that are currently running are testing a new API for strict 
> Base64 decoding. Right now it's a feature without a client; I included it 
> here because it was a good showcase of the test suite (see test/unit/base64.c 
> for the test case code).
> 
> Let me know what you think!

Love the idea of a test suite written in the same language as the server itself.

It means that anyone who updates the server can use the same skills to update 
the tests.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: slotmem + balancer

[Jim Jagielski]

> On May 20, 2018, at 4:59 PM, Yann Ylavic  wrote:
> 
> 
> Now we are back to 2.4.29 code, r1822341 is in again, and I committed
> additional changes (minimal hopefully) to address the issues reported
> in PR 62308 (and PR 62044 still). My own testing, based on the tests
> run by the OP (his on Windows, mine on Linux), all passes right now.
> So I'm waiting for the OP's latest results to propose a backport.
> 
> WDYT of this approach (and patches), do it sound better?
> 

It does and I appreciate you taking the time and effort not only on the code 
but also with this most excellent email!

Sorry I was such a "stickler" about all this... most of it is due to the 
resistance in large scale code changes being done which try to address separate 
issues in one large chunk. Past history w/i the project have shown that, in 
general, these cause more harm than good because too much is changed in one go, 
making it difficult to more realistically assess the impacts. So when I see 
these big refactors, I tend to recall the risk and have a semi-immediate 
knee-jerk about them.