From: Piske, H. <Har...@bo...> - 2002-06-20 22:57:00
|
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. |
From: Morbus I. <mo...@di...> - 2002-06-20 23:24:42
|
>In a very busy loop, I keep calling > return -1 if Win32::GUI::DoEvents () < 0; Harald, I profess to know nothing, but I use a tight, infinite while loop that calls "gui_listen" each iteration. gui_listen is just: sub gui_listen { # anyone there? Win32::GUI::PeekMessage(0,0,0); Win32::GUI::DoEvents(); return 1; } I also have gui_listen's sprinkled throughout various other timely-ish functions so, ultimately, gui_listen is called at the minimum of once per iteration, with a max of about three or four times. I've yet to see crashes like you're having. I doubt this helps, but :) ... -- Morbus Iff ( strive for mediocrity ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Tech: http://www.oreillynet.com/pub/au/779 - articles and weblog icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus |
From: Chris I. <ch...@sp...> - 2002-06-21 12:53:48
|
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: per...@li... [mailto:per...@li...]On Behalf Of Piske, Harald Sent: Thursday, June 20, 2002 6:53 PM To: per...@li... 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 Per...@li... https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users |