Siege segfaulting

[Ivan Voras]

Hi!

I was asked to send details about a problem I found with siege on 
5.2-current. Here is my original post from current at freebsd.org:

There are problems (segfault) running siege (web benchmark program) on a 
recent FreeBSD 5.2-current (a few days ago). When I switch it to libc_r 
via libmap.conf, everything works ok. Since the software is ported to a 
large number of platforms and works ok, it's likely a libpthread bug

Siege uses threading to make simultaneous HTTP requests. I tried with a 
recent release (2.59) and beta (2.60) version if siege, with same behaviour.

This does not happend with small number of threads (2-3), but if I 
specify a larger number (usually 8+), it crashes in the middle of work.


In the faulting instances, siege was started as:
siege -c20 -v -f list -t5m -d1

Thats: 20 threads, verbose output (writes status of each request to the 
console), "list" is the file that contains URLs, 5m is the duration of 
the test, d1 stands for: insert a random delay between 0 and 1 seconds 
before each request. The web application tested is made in PHP and 
requests take from about 0.02sec to 1.5sec to serve.

Changing the duration (-t), random delay (-d) did not have any effect.

Kernel is "mostly" GENERIC, with support for older processors, ipv6 and 
unneeded drivers removed (as well as witness and other debugging 
options), and with ULE scheduler.

-- 
C isn't that hard: void (*(*f[])())() defines f as an array of
unspecified size, of pointers to functions that return pointers to
functions that return void.