[Ace-users] Race condition between handle_input() & handle_timeout() in ACE_Svc_Handler ?
Shawn.Chain at gmail.com
Fri Nov 16 01:49:49 CST 2007
To respect the rule, here is the FPR
ACE VERSION: 5.4
HOST MACHINE and OPERATING SYSTEM:
Windows XP sp2
COMPILER NAME AND VERSION (AND PATCHLEVEL):
CONTENTS OF $ACE_ROOT/ace/config.h:
DOES THE PROBLEM AFFECT:
Application crashes randomly if a handler is handling the
request and at the same time it's expired by timer.
Hi all ACE experts,
I'm newbie to ACE. Now I'm struggle with a nasty crash in my
application, and it's seems caused by race condition between the
handle_timout() and handle_input()
This is a service application, using ACE5.4, running under windows XP
I used TPReactor, and extended ACE_Svc_Handler to handle incoming tcp
In order to recycle/close idle connections, we also registered a timer
and in our Svc_Handler::handle_timeout(), if detected that handler is
idle, then we'll return -1 to release the handle.
But I found an interesting problem by this *timeout* mechanism, that
is, if a request come in at the *exact* time when *timeout* is fired,
ACE might crash.
To reproduce this problem, I changed the server idle timeout interval
to 5s, and write a client app to send request to server every 5s, soon
the service application crashed.
By analysising the log and call stack trace and the thread states, I
found that there seems to be a race condition.
Request -> come in -> Handler ctor called and timer is registered ->
back to the ACE -> OS Switch to another thread -> ACE trigger the
timer and spawn a new thread to call the handle_timeout on this newly
created handler -> handle_timeout return -1(detected the busy/active
state, but got idle information) -> back to ACE -> handler destructor
called -> OS switch back to the first thread -> crash...
Any ideas ? or Could anyone give me some advice about how to close the
handler gracefully & thread-safely when idle timeout is triggered ?
More information about the Ace-users