Hi friends

I'm happy to announce that I just now had all 191 test cases run through the
torture tests OK!

The torture test first runs the test case once to count the number of
allocations made. Then it runs the test case repeatedly over and over again
forcing each alloc to fail until all allocs for that test case have been made
to fail once each. Then it proceeds to the next test case.

Between each individual invoke, 'memanalyze' scans for memory leaks and other
memory-related problems and if anything is found, it stops the testing and and
displays data about the problem.

When James Bursa made the torture testing work on regular test cases (it was
present already before, but used only special tests), it died already on the
very first test case! I've spent the last week fixing code that leaked or
crashed on this.

I view this as a significant milestone in libcurl reliability.

Caveats: the leaks tested for are those that the memdebug system tracks. There
might still be some leaks involving OpenSSL and similar.

If you try this at home, and get a failure, this is how I usually proceed to
debug and find a fix for the situation:

1. run a single torture test (presumably one that fails):

  $ cd tests
  $ ./runtests.pl -t [testnum]

  or to make a specific alloc call fail, specify that number at the -t
  option, like this:

  $ ./runtests.pl -t[allocnum] [testnum]

2. If it died with a core dump and you built libcurl staticly, you can then
  investigate the core quite easily:

  $ gdb ../src/curl core

   or if the test case was >= 500:

  $ gdb libtest/lib[num] core

3. If it stopped with a leak, the output on the screen tells you exactly what
   alloc number, what lines that allocated the memory that was never freed and
   what code line that "hit the limit". If that info isn't enough to figure
   out a good way to tighten the leak, you can run the specific test using
   gdb. For example, on test case 13 we make alloc number 7 fail:

  $ ./runtests -t7 -g 13

  when gdb starts up we enter:

  $ b memdebug.c:98 (which is a line that is executed when the alloc-limit
                       is reached)
  $ run (the test script sets up the args properly by itself)

  when gdb hits the break-point, single-step forward and you'll soon figure
  out exactly which alloc-funtion that now returns NULL.

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html