Hello, running latest CVS head i get an: Assertion failed in threads.c, line 540 After the second request. In debug mode (-X) everything is running fine. Regards Stephan Jaeger -- Mit freundlichen Grüßen i.A. Stephan Jäger Abteilung Dienste Telefon: (0441) 8000-2873 Telefax: (0441) 8000-2799 mailto:stephan.jaeger@ewetel.de ___________________________________ EWE TEL GmbH Cloppenburger Straße 310 26133 Oldenburg Handelsregister Amtsgericht Oldenburg HRB 3723 Vorsitzender des Aufsichtsrates: Heiko Harms Geschäftsführung: Hans-Joachim Iken, Dirk Thole, Jürgen Wehlend Homepage: http://www.ewetel.de ___________________________________
Stephan Jaeger wrote:
running latest CVS head i get an:
Assertion failed in threads.c, line 540
After the second request. In debug mode (-X) everything is running fine.
I don't see that... Also, that code is executed *only* when there are too many threads, and one is being deleted. There's no reason for that to happen after one request... What does debug mode say? (radiusd -fxx) That will run it multi-threaded, but with debugging enabled. Alan DeKok.
On Fri, 2007-08-03 at 13:45 -0400, Alan DeKok wrote:
Assertion failed in threads.c, line 540
After the second request. In debug mode (-X) everything is running fine.
I don't see that...
Also, that code is executed *only* when there are too many threads, and one is being deleted. There's no reason for that to happen after one request...
What does debug mode say? (radiusd -fxx) That will run it multi-threaded, but with debugging enabled.
Here is the output of -fxxx|grep Thread thread settings, just for testing: start_servers = 2 min_spare_servers = 0 max_spare_servers = 0 Some of the test runs look like this: Fri Aug 3 20:59:58 2007 : Debug: Thread spawned new child 1. Total threads in pool: 1 Fri Aug 3 20:59:58 2007 : Debug: Thread spawned new child 2. Total threads in pool: 2 Fri Aug 3 20:59:58 2007 : Debug: Thread pool initialized Fri Aug 3 20:59:58 2007 : Debug: Thread 2 waiting to be assigned a request Fri Aug 3 20:59:58 2007 : Debug: Thread 1 waiting to be assigned a request Fri Aug 3 21:00:06 2007 : Debug: Thread 2 got semaphore Fri Aug 3 21:00:06 2007 : Debug: Threads: total/active/spare threads = 2/0/2 Fri Aug 3 21:00:06 2007 : Debug: Threads: deleting 1 spare out of 2 spares Fri Aug 3 21:00:06 2007 : Debug: Thread 2 handling request 0, (1 handled so far) Fri Aug 3 21:00:06 2007 : Debug: Thread 1 got semaphore Fri Aug 3 21:00:06 2007 : Debug: Thread 1 exiting... Fri Aug 3 21:00:06 2007 : Debug: Thread 2 waiting to be assigned a request Fri Aug 3 21:00:06 2007 : Debug: Threads: total/active/spare threads = 1/0/1 Fri Aug 3 21:00:11 2007 : Debug: Threads: deleting 1 spare out of 1 spares [...] Fri Aug 3 21:07:56 2007 : Debug: Thread 2 got semaphore Fri Aug 3 21:07:56 2007 : Debug: Threads: deleting 1 spare out of 1 spares Fri Aug 3 21:07:56 2007 : Debug: Thread 2 handling request 47, (48 handled so far) Fri Aug 3 21:07:56 2007 : Debug: Thread 2 waiting to be assigned a request Fri Aug 3 21:07:57 2007 : Debug: Threads: deleting 1 spare out of 1 spares Fri Aug 3 21:08:01 2007 : Debug: Threads: deleting 1 spare out of 1 spares Fri Aug 3 21:08:06 2007 : Debug: Threads: deleting 1 spare out of 1 spares Fri Aug 3 21:08:06 2007 : Debug: Thread 2 got semaphore Fri Aug 3 21:08:06 2007 : Debug: Thread 2 handling request 48, (49 handled so far) Fri Aug 3 21:08:06 2007 : Debug: Thread 2 waiting to be assigned a request Fri Aug 3 21:08:07 2007 : Debug: Threads: deleting 1 spare out of 1 spares Fri Aug 3 21:08:11 2007 : Debug: Threads: deleting 1 spare out of 1 spares Fri Aug 3 21:08:16 2007 : Debug: Thread 2 got semaphore Fri Aug 3 21:08:16 2007 : Debug: Threads: deleting 1 spare out of 1 spares Fri Aug 3 21:08:16 2007 : Debug: Thread 2 handling request 49, (50 handled so far) Fri Aug 3 21:08:16 2007 : Debug: Thread 2 waiting to be assigned a request Fri Aug 3 21:08:17 2007 : Debug: Threads: deleting 1 spare out of 1 spares Seems to run forever, although my patience wasn't that long ;) And some are very short: Fri Aug 3 21:12:21 2007 : Debug: Thread spawned new child 1. Total threads in pool: 1 Fri Aug 3 21:12:21 2007 : Debug: Thread spawned new child 2. Total threads in pool: 2 Fri Aug 3 21:12:21 2007 : Debug: Thread pool initialized Fri Aug 3 21:12:21 2007 : Debug: Thread 1 waiting to be assigned a request Fri Aug 3 21:12:21 2007 : Debug: Thread 2 waiting to be assigned a request Fri Aug 3 21:12:26 2007 : Debug: Threads: total/active/spare threads = 2/0/2 Fri Aug 3 21:12:26 2007 : Debug: Threads: deleting 1 spare out of 2 spares Fri Aug 3 21:12:26 2007 : Debug: Thread 1 got semaphore Fri Aug 3 21:12:26 2007 : Debug: Thread 1 handling request 0, (1 handled so far) Fri Aug 3 21:12:26 2007 : Debug: Thread 2 got semaphore Fri Aug 3 21:12:26 2007 : Debug: Thread 2 waiting to be assigned a request Fri Aug 3 21:12:26 2007 : Debug: Thread 1 exiting... Ending after the first request. With the assertion in thread.c, 540. Stephan Jaeger -- Stephan Jaeger <stephan.jaeger@ewetel.de>
Stephan Jaeger wrote:
Here is the output of -fxxx|grep Thread
thread settings, just for testing: start_servers = 2 min_spare_servers = 0 max_spare_servers = 0
Oh. That's a corner case that probably isn't well tested. Setting the minimum spare threads to zero isn't nice. It means that you have *no* threads available when the server is idle. i.e. it tries to delete ALL threads when all threads are idle. Summary: Don't do that. Set min_spare_servers = 1, and max_spare_server = 1. I'll fix the code to complain, and/'or catch this case. Alan DeKok.
On Fri, 2007-08-03 at 15:48 -0400, Alan DeKok wrote:
Stephan Jaeger wrote:
Here is the output of -fxxx|grep Thread
thread settings, just for testing: start_servers = 2 min_spare_servers = 0 max_spare_servers = 0
Oh. That's a corner case that probably isn't well tested. Setting the minimum spare threads to zero isn't nice. It means that you have *no* threads available when the server is idle. i.e. it tries to delete ALL threads when all threads are idle.
That was just for testing, here is output with: start_servers = 15 min_spare_servers = 5 max_spare_servers = 10 Fri Aug 3 22:06:54 2007 : Debug: Thread spawned new child 1. Total threads in pool: 1 [...] Fri Aug 3 22:06:54 2007 : Debug: Thread spawned new child 15. Total threads in pool: 15 Fri Aug 3 22:06:54 2007 : Debug: Thread pool initialized Fri Aug 3 22:06:54 2007 : Debug: Thread 1 waiting to be assigned a request Fri Aug 3 22:06:54 2007 : Debug: Thread 15 waiting to be assigned a request Fri Aug 3 22:06:56 2007 : Debug: Threads: total/active/spare threads = 15/0/15 Fri Aug 3 22:06:56 2007 : Debug: Thread 1 got semaphore Fri Aug 3 22:06:56 2007 : Debug: Thread 1 handling request 0, (1 handled so far) Fri Aug 3 22:06:56 2007 : Debug: Thread 1 waiting to be assigned a request Fri Aug 3 22:07:01 2007 : Debug: Threads: deleting 1 spare out of 5 spares Fri Aug 3 22:07:01 2007 : Debug: Thread 2 got semaphore Fri Aug 3 22:07:01 2007 : Debug: Thread 2 exiting... Fri Aug 3 22:07:06 2007 : Debug: Threads: total/active/spare threads = 14/0/14 Fri Aug 3 22:07:06 2007 : Debug: Threads: deleting 1 spare out of 4 spares Fri Aug 3 22:07:06 2007 : Debug: Thread 3 got semaphore Fri Aug 3 22:07:06 2007 : Debug: Thread 3 handling request 1, (1 handled so far) Fri Aug 3 22:07:06 2007 : Debug: Thread 3 exiting... Fri Aug 3 22:07:06 2007 : Debug: Thread 4 got semaphore Fri Aug 3 22:07:06 2007 : Debug: Thread 4 waiting to be assigned a request Same assertion... Stephan Jaeger -- Stephan Jaeger <stephan.jaeger@ewetel.de>
Stephan Jaeger wrote:
That was just for testing, here is output with:
start_servers = 15 min_spare_servers = 5 max_spare_servers = 10
But that's mostly the same thing... you're telling it to start 15, and *then* telling it to use no more than 10. So as soon as you start the server, it will spawn 15 threads, and immediately kill 5 of them. Why are you configuring that? I just don't understand.
Same assertion...
I've committed another fix. Let's see if it works. Alan DeKok.
Am Freitag, den 03.08.2007, 16:37 -0400 schrieb Alan DeKok:
Why are you configuring that? I just don't understand.
By accident, but segfaults make me nervous ;)
Same assertion...
I've committed another fix. Let's see if it works.
It does, thanks. Stephan Jaeger -- Stephan Jaeger <stephan.jaeger@ewetel.de> EWE TEL GmbH
participants (2)
-
Alan DeKok -
Stephan Jaeger