I won't profess to be an expert on the guts of the GUI module either, 
but
what I can tell you is that 9 times out of 10, when I have a segmentation
fault being generated somewhere in my code that mysteriously goes away in a
debugger, it's an uninitialized pointer (some debuggers -notably gdb,
conveniently set them all to null values initially).  Guess that probably
doesn't help you much though. :(


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Piske, Harald
Sent: Thursday, June 20, 2002 6:53 PM
To: perl-win32-gui-users@lists.sourceforge.net
Subject: [perl-win32-gui-users] DoEvents can crash


OK, this is killing me. I need help from someone with GUI.xs eyes ... Aldo?
In a very busy loop, I keep calling
    return -1 if Win32::GUI::DoEvents () < 0;
To be able to click and have the program react (especially to Abort_Click or
Alt+F4)

Every once in a blue moon, I get the infamous "the memory could not be read"
fatal crash, terminating my program and making me really happy because I can
start all over. Debugging the phenomenon is not possible because in the
debugger the problem mysteriously vanishes. Examining variable values after
the crash in the END sub is not possible because the program crashes too
hard, bypassing END. Periodically displaying a counter so that I know when
exactly it occurs is not helping because "print" is enough to avoid the
crash.

I don't have a real solution, just an even more mysterious work-around that
I hope and pray, will actually avoid the crash and not just make it less
frequent. Here's what I found:

- The crash did happen in a sub that got a hash ref as 1st and a string as
2nd parameter. That's not the only spot where it hit me, but the one where I
could at least reproduce it.
- When I added a dummy parameter as #3, it did not crash
- When I changed one of the other parameter's types, it did not crash (even
though my program did not work anymore, obviously)
- When I preceded the DoEvents() call with any of the following, the crash
still occured:
0;
42;
$dummy;
- When I preceded the DoEvents() call with any of the following, the crash
did NOT occur:
0 + 42;
$dummy = 0;
print "rats";
/dummy/;
local $_ = $_[0];

My dirty approach to not crashing my script is now to actually have
/pleasedonotcrash/;
before every DoEvents() call which is much like digital superstition :-s

Now, I know it's not gonna work, because after making some additions
elsewhere in the program and then trying again, I noticed that now some of
the previously operative remedies (namely 0+42 and $_=$_[0]) do NO LONGER
prevent the crash at this point in my script. It appears that DoEvent really
does what the error message suggests, read from memory that does not belong
to it. Does anybody have an idea where to look? All I can see in the
DoEvents function in GUI.xs is
        PeekMessage(&msg, hwnd, 0, 0, PM_REMOVE);
        TranslateMessage(&msg);
        DispatchMessage(&msg);
With some scary things in between, like if(SvMAGICAL(self)) mg_get(*tempsv);
I know there has been an issue with PeekMessage if it was passed the message
parameter, but that is the public method PeekMessage (i.e. perl), not the
Windows funtion call ... that's it, I give up. I'm at a loss.



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users


Reply via email to