From owner-freebsd-threads@FreeBSD.ORG Sun Apr 18 09:10:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 790A916A4CE for ; Sun, 18 Apr 2004 09:10:59 -0700 (PDT) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD58D43D1D for ; Sun, 18 Apr 2004 09:10:58 -0700 (PDT) (envelope-from ivoras@geri.cc.fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.107]) by geri.cc.fer.hr (8.12.9p2/8.12.8) with ESMTP id i3IGAa1m094976 for ; Sun, 18 Apr 2004 18:10:36 +0200 (CEST) (envelope-from ivoras@geri.cc.fer.hr) Message-ID: <4082A88E.5060605@geri.cc.fer.hr> Date: Sun, 18 Apr 2004 18:10:54 +0200 From: Ivan Voras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-threads@freebsd.org X-Enigmail-Version: 0.83.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Siege segfaulting X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2004 16:10:59 -0000 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.