From apwww@hyperreal.org Wed Oct 8 02:14:37 1997 Received: (from apwww@localhost) by hyperreal.org (8.8.5/8.8.5) id CAA20418; Wed, 8 Oct 1997 02:14:37 -0700 (PDT) Message-Id: <199710080914.CAA20418@hyperreal.org> Date: Wed, 8 Oct 1997 02:14:37 -0700 (PDT) From: Dean Gaudet Reply-To: dgaudet@apache.org To: apbugs@hyperreal.org Subject: race condition in unblock_alarms() X-Send-Pr-Version: 3.2 >Number: 1211 >Category: general >Synopsis: race condition in unblock_alarms() >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: closed >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Wed Oct 8 02:20:03 1997 >Last-Modified: Mon Nov 3 07:58:22 PST 1997 >Originator: dgaudet@apache.org >Organization: >Release: 1.3b1 >Environment: all >Description: unblock_alarms() still has a race condition even after the "Ouch! Freeing free block!" patch. If a timeout goes off right after the "exit_after_unblock = 0" it won't exit, it'll jump back to the main loop and continue serving. >How-To-Repeat: >Fix: I'm not sure yet, I want to preserve the nice code that the common path through there has right now ... i.e. the common path is just decrement, test and return. There should be a solution involving teaching timeout about exit_after_unblock and doing ++alarms_blocked instead of setting exit_after_unblock to 0 >Audit-Trail: State-Changed-From-To: open-analyzed State-Changed-By: dgaudet State-Changed-When: Sun Nov 2 20:51:55 PST 1997 State-Changed-Why: Patch submitted for consideration. State-Changed-From-To: analyzed-closed State-Changed-By: marc State-Changed-When: Mon Nov 3 07:58:22 PST 1997 State-Changed-Why: Dean has committed a fix for this problem to the 1.3 tree. >Unformatted: