| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
far
|
|
|
|
|
|
|
|
|
|
auth
|
|
An attempt to repeat a reported auth problem. Works for me!
|
|
|
|
|
|
Pointed out by Chris Gaukroger.
|
|
|
|
|
|
|
|
|
|
not be used both in one request. Fixed it and added test case 172 to verify.
|
|
set to the domain .a.b.c (that is with a dot prefix). This is now fixed and
test case 171 verifies it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is necessary in case the client never connects or somehow fails to do
it timely. The timeout used now is only 2 seconds, which might cause problems
on really slow hosts but longer times are painful when doing torture testing
on FTP test cases.
I'm not sure how this 'alarm' functionality works on Windows or other systems
that don't actually have the alarm() function.
|
|
|
|
memory leak detection
|
|
|
|
|
|
|
|
Also made -t imply -n to disable valgrind, it runs sloooow otherwise.
This now manages to run all tests OK up to test case 100 (the first FTP one)
for me.
|
|
|
|
memory.h is included everywhere for this.
|
|
The -t is the "torture" test that first runs the test and counts the number
of allocations performed during it, then it runs the test repeatedly over and
over again and makes alloc number N fail to verify that we detect and return
properly from error cases everywhere.
|
|
|
|
|
|
|
|
|
|
|
|
warnings
|
|
|
|
assume that the curl file is a proper binary, it is often a script file
produced by libtool.
|
|
for a reason I don't know
|
|
|
|
|
|
initial basic valgrind-log scan for memory leaks it could detect.
|
