Date: Sun, 18 Apr 2004 18:10:54 +0200 From: Ivan Voras <ivoras@geri.cc.fer.hr> To: freebsd-threads@freebsd.org Subject: Siege segfaulting Message-ID: <4082A88E.5060605@geri.cc.fer.hr>
next in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4082A88E.5060605>