Re: [perl-win32-gui-hackers] User32 error in script

[Robert M. <rm...@po...>]

Robert May wrote:
> I can see the problem clearly.  It's because you're 
> destroying a window while in the middle of processing an event sent to 
> it, and the code isn't expecting that, and so ends up trying to access 
> some of the window's properties after they have been freed.  I've got a 
> solution to most of it, but there are a couple of areas where I'm not 
> sure how to resolve it ... some more thought required, but I'll try to 
> get a fix into the next release.
> 
> For the record, here's the shortest example I can come up with that 
> exhibits the problem:
> 
> #!perl -w
> use strict;
> use warnings;
> 
> use Win32::GUI();
> 
> my $mw;
> 
> $mw = Win32::GUI::Window->new(
>      -onKeyDown => sub { undef $mw; return -1; },
> );
> 
> $mw->Show();
> Win32::GUI::Dialog();
> __END__

Hackers,

Would you expect the above sample to exit cleanly?

The problem is that if we destroy a window during a callback, perlud 
gets freed before the callback returns;  the code then has a non-NULL 
perlud pointer, that points into freed memory.  The fact that this only 
exhibits a crash on Win98 is, I think, just luck.

I've now got checks in place in all the places that I can see that we 
attempt to access perlud after a callback, and the crash appears to be 
fixed, but I'm left with one issue:

return -1 results in us trying to exit the Dialog() loop using
   PostMessage(hwnd, WM_EXITLOOP, (WPARAM) -1, 0);

but hwnd has already been destroyed, so the message never gets 
delivered.  In the above example pressing a key causes the window to 
disappear, but leaves Dialog() spinning, and the script never finishes.

I can change the PostMessage(..) to
   PostThreadMessage(GetCurrentThreadId(), WM_EXITLOOOP, (WPARAM) -1, 0);

and all tests pass, and I haven't (yet) found a problem with it, but it 
feels like quite a fundamental change to me.  Can anyone see a problem 
with it, or propose a better solution?  Or should I not worry?

Regards,
Rob.