develooper Front page | perl.perl5.porters | Postings from August 2012

[perl #33096] win32_msgwait runs forever with non-infinite timeout

Thread Previous | Thread Next
From:
bulk 88 via RT
Date:
August 20, 2012 23:21
Subject:
[perl #33096] win32_msgwait runs forever with non-infinite timeout
Message ID:
rt-3.6.HEAD-11172-1345530106-1009.33096-15-0@perl.org
On Fri Dec 17 19:11:29 2004, cbecker wrote:
> This is a bug report for perl from chris@fatorange.com,
> generated with the help of perlbug 1.35 running under perl v5.8.5.
> 
> 
> -----------------------------------------------------------------
> win32_msgwait will loop forever under the condition that none of the
handles
> becomes ready, while MsgWaitForMultipleObjects keeps on returning events
> before the timeout (non-infinite) is ever hit.
> Just ran into this (timeout: 1 second) and had a debugger handy -
looking at
> the source, this should be fairly easy to understand & recreate. The
> solution would be to decrease the timeout by the amount waited with every
> run - watch out for DWORD overflows!
Looking at
http://perl5.git.perl.org/perl.git/blob/eb92badec069d2041ebf51c3654ed7e62e7309e9:/win32/win32.c#l2154
. There is a wall time check and the timer is decreased (actually
increased towards expire time) correctly but there is a race with a
deadlock (near infinity timeout) if the delay from
MsgWaitForMultipleObjects to GetTickCount exceeds 1 ms causing var ticks
to go > var timeout. For "while MsgWaitForMultipleObjects keeps on
returning events before the timeout (non-infinite) is ever hit", if the
Perl process is getting a denial-of-service attack through the Windows
Message queue from a a different abusive process, there is nothing Perl
can do about it. The PC will be 100% cpu usage anyway from the abusive
process. If the messages won't be processed in win32_msgwait they will
be processed anyway in assorted perl opcodes in PERL_ASYNC_CHECK()s.

I was able to create a deadlock with a C debugger by doing a Perl "sleep
3;" and creating the delay with breakpoints with a C debugger. Windows
running in VM or with a very badly coded driver could cause a context
switch that would cause the >= 1 ms delay.

I have a patch nearly complete to prevent the race condition above, but
I realized a different race condition, the 49.7 day overflow, see
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724408%28v=vs.85%29.aspx
. The only bug the 49.7 day overflow I see creating is, if you sleep for
more than 50 days, sleep() will return ~ < 1 day of sleep seconds
instead of > 49 days of sleep seconds. So I have 4 choices.

1. Keep GetTickCount and put the 49.7 days of sleep actual seconds slept
bug in perlwin32/BUGS AND CAVEATS section as a wont fix. Microsoft
considers a likely enough scenario they test apps for the bug, see
http://msdn.microsoft.com/en-us/subscriptions/aa480483.aspx and search
the page for GetTickCount.

2. Replace GetTickCount with QueryPerformanceCounter
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644904%28v=vs.85%29.aspx
. The difficulty with this is, in what psuedo global or real global
struct do I keep the frequency (
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644905%28v=vs.85%29.aspx
) in? It needs to be stored once per Perl DLL loading (non static
build), or once per perl process startup (static build, no perl library
dll), not queried on every ithread interp creation and stored in a
my_perl member (duplicate calls to QueryPerformanceFrequency, I am
probably microoptimizing here). Is there a way of storing truly process
global (not interp global) data that doesn't have a const initializer or
just put it in struct interp_intern and refetch it with
QueryPerformanceFrequency as needed, the more efficient way is simply
too difficult with perl's architecture?

3. Replace GetTickCount with GetSystemTimeAsFileTime
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397%28v=vs.85%29.aspx
. I dont know what GetSystemTimeAsFileTime's leap second behavior is.

4. If sleep delta > (49.7 days to seconds/2) assume we overflowed and
panic/croak. This doesn't seem like a good idea.

The Perl community's input is needed and appreciated.

---
via perlbug:  queue: perl5 status: new
https://rt.perl.org:443/rt3/Ticket/Display.html?id=33096

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About