site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com We developed a small NKE and a sequence of steps that may make this NKE to crash even under Tiger 10.4.1 (it crashes in more stable manner under 10.4). However, even if this NKE doesn't crash (doesn't cause the system to panic), the number of the sockets it is attached to grows uncontrollably and this seems to be a Darwin issue. The problem of sockets concerns with the uncontrollable grow of the number os sockets that were created in response to incoming connections but that were not accept'ed. Problem description =================== The very basic socket-filter NKE crashes on unload (kextunload). If it doesn't crash, the number of sockets the socket-filter is attached to grows uncontrollably. Prerequisites ============= 1. Mac OS 10.4.1 2. test_nke NKE (see the attach) test_nke is a basic socket-filter global NKE that simply counts the number of sockets it is attached to. test_nke outputs this number to the system log (sock_count). 3. isockcnt utility. The utility does the following - creates a listening TCP socket (server-side) in a separate process, The second argument of listen() is some large number (256). The listened port is some arbitrary port_number_1 - from a separate process (client-side) connects to the listening socket 100 times, - at the server side accepts the first connection from the client side and then does sleep(2), but the server-side process is killed in one second by alarm. - closes the connection from the client-side (exit(0)). All these steps are repeated several times for the port_number_1 = port_number_1 + 1 with the interval of 3 seconds. This results in a large number of sockets that the test_nke is attached to but is not detached from during reasonable amount of time (about 2 minutes). Remark. From our point of view, the sockets that the filter is not detached from are the sockets from the accept queue. These sockets are created in response to incoming connections. Apparently, for them the kernel structures are allocated but these sockets are not initialized completely. We believe that this happens because accept() was not called for these sockets and meanwhile the client closed the connection (e.g. was terminated) for some reason. How to reproduce ================ 1. Login with administrative account. 3. Load the test_nke NKE (sudo kextload test_nke.kext). 4. Start the insockcnt utility (sudo ./insockcnt). 5. Wait about 30 seconds. 6. Stop the insockcnt utility by pressing 'Control+C'. 7. The number of sockets the test_nke is attached is dumped to the system log. This number may be considerably more than 0, but it should be equal to 0, because all the sockets the NKE had been attached to were closed. If the dumped socket_count is not equal 0, then the subsequent kextunload may result in a system crash. Remark. Even if the insockcnt utility is started without sudo (becoming super-user), and is terminated in about 2-3 minutes (instead of 30 seconds), the kernel starts lacking the resources and goes into panic. Thanks, alexklg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com testnke-20050606-03.tgz