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

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

Thread Previous
From:
bulk 88 via RT
Date:
September 4, 2012 20:37
Subject:
[perl #33096] win32_msgwait runs forever with non-infinite timeout
Message ID:
rt-3.6.HEAD-11172-1346816220-239.33096-15-0@perl.org
On Mon Aug 20 23:30:05 2012, bulk88 wrote:
> On Mon Aug 20 23:21:46 2012, bulk88 wrote:
> > 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.
> 
> 5. If timeout is > 50% of 2^32 ms or 90% or 99% of 2^32 ms, croak as
> invalid timeout. Since posix sleep has no errors, $! = EINVAL is not
> needed right? I dont like this idea.

I wrote a C level hooker that hooked GetTickCount from perl517.dll to
kernel32.dll. I created an algorithm where the offset from hooked
GetTickCount to real GetTickCount grows/compounds by 10 seconds every
call to hooked GetTickCount. The sleep time in perl is 5 seconds.
Without Visual Studio debugger, it never deadlocked and was always
accurate to less then +/- 1 second. So, creating an overflow and a
deadlock by "(int)(timeout-ticks) < (int)0" I couldn't reproduce, on
practical terms. The theoretical deadlock I described above might still
be possible though.

With Visual Studio debugger, something interesting happens. The deadlock
occurs because the message queue is being spammed (I'm not sure if I am
seeing the same message over and over, or is each time a new message)
with a random per per system but not random per process (kindda) message
number. The message number is in the Windows allocated range, using
RegisterWindowMessage. Getting the string name on the message number
(see google for the GetClipboardFormatName hack) reveals
"MSUIM.Msg.Private". 1st page of Google hasn't been very useful in
describing what this message is. Callstack for where this
MSUIM.Msg.Private message is being fetched over and over is
___________________________________________________________
>	perl517.dll!win32_async_check(interpreter * my_perl=0x003842a4) 
Line 2142	C
 	perl517.dll!win32_msgwait(interpreter * my_perl=0x003842a4, unsigned
long count=0x00000000, void * * handles=0x00000000, unsigned long
timeout=0x76ade726, unsigned long * resultp=0x00000000)  Line 2177 + 0x9	C
 	perl517.dll!win32_sleep(unsigned int t=0x0000000a)  Line 2342 + 0x19	C
 	perl517.dll!PerlProcSleep(IPerlProc * piPerl=0x00344510, unsigned int
s=0x0000000a)  Line 1659 + 0x9	C++
 	perl517.dll!Perl_pp_sleep(interpreter * my_perl=0x003842a4)  Line
4618 + 0x1a	C
 	perl517.dll!Perl_runops_debug(interpreter * my_perl=0x003842a4)  Line
2126 + 0xd	C
 	perl517.dll!S_run_body(interpreter * my_perl=0x003842a4, long
oldscope=0x00000001)  Line 2392 + 0xd	C
 	perl517.dll!perl_run(interpreter * my_perl=0x003842a4)  Line 2309 + 0xd	C
 	perl517.dll!RunPerl(int argc=0x00000002, char * * argv=0x00342478,
char * * env=0x00345258)  Line 270 + 0x9	C++
 	perl.exe!main(int argc=0x00000002, char * * argv=0x00342478, char * *
env=0x00342de0)  Line 23 + 0x12	C
 	perl.exe!mainCRTStartup()  Line 398 + 0xe	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23	
_______________________________________________________

I'm not sure how well I will be able to diagnose this since my knowledge
with Win32's GUI system is very low. Maybe the actual bug here is, how
does Perl handle getting its Win32 message queue spammed with random
messages from the Perl process or other processes that Perl itself
doesn't handle since the Perl interp is not a GUI program.

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

Thread Previous


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