1. Help! GPF
- Posted by Brent Hugh <bhugh at CSTP.UMKC.EDU> Aug 03, 1999
- 437 views
Hi all, I'm developing a windows midi application in Euphoria and I am having the most vexatious possible GPF happen with some regularity. The GPF happens just after the program starts, before the main window even pops up. It happens occasionally--once every 5 or 10 times the program runs. It does not seem to be associated with any particular program code (it happens when the program is around line 400, but it doesn't make a bit of difference what code you put or don't put around those lines). It is not related to a syntax error or runtime error--you can run the same code again immediately after the GPF, and it runs just fine, with no error. The error happens (sporadically) whether the code is run as a separate file or bound. The program uses win32lib (ver 0.20) and some other libraries. Full include files and details of the GPF error messages are below. Any suggestions? This is driving me crazy! --Brent Error message (this is always the same): --------------- Application Error The instruction at bff64e46 referenced memory at ffffffff The memory could not be read from --------------- The next message box comes up something like this (not always exactly the same): --------------- EXW caused an invalid page fault in module USER32.DLL at 0137:bff64e46. Registers: EAX=00697b80 CS=0137 EIP=bff64e46 EFLGS=00010297 EBX=00697b8c SS=013f ESP=0056f9b8 EBP=0056f9ea ECX=ffffffff DS=013f ESI=02000004 FS=17b7 EDX=00000006 ES=013f EDI=ffffffff GS=0000 Bytes at CS:EIP: 66 81 39 90 68 75 25 66 81 79 06 90 68 75 1d 81 Stack dump: 0040502b ffffffff 00000dd8 000000f1 00000001 00000000 00000200 00000000 0000005d 0040e829 ffff0078 006a7028 000001d2 0056fb04 00000202 00000000 --------------- Includes (I don't think it's specifically caused by any of these--I've gone through and commented each of them out, and before getting any other error, you will still get the GPF): ------------- include win32lib.ew -- David Cuny library include win32ini.ew include msgbox.e include machine.e include dll.e include midi.ew include midierr.ew include get.e include file.e (btw, midi.ew and midierr.ew are from my windows midi toolkit that will soon be available on the Euphoria archive.) ++++++++++++++++++++ Brent Hugh / bhugh at cstp.umkc.edu ++++++++++++++++++++ ++++++++ University of Missouri-Kansas City, Conservatory of Music +++++++ ++ Sheet Music/Recordings: http://www.sunflower.org/~bhugh/pathetic.spm ++ + Internet Piano Concert: http://cctr.umkc.edu/userx/bhugh/recital.html + ++++++++++ Classical Piano MP3s http://www.mp3.com/brent_d_hugh ++++++++++
2. Re: Help! GPF
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Aug 03, 1999
- 403 views
Brent Hugh wrote: > I'm developing a windows midi application in Euphoria > and I am having the most vexatious possible GPF happen > with some regularity. I'd guess that Win32Lib is at fault. Probably in a routine in user32.dll, but that doesn't really narrow down the scope - there are a lot of routines in there. You might consider hacking Win32Lib a bit. Specifically, you could define your own versions of c_func and c_proc, along the lines of: constant traceFile = open("trace.txt", "r") function my_c_func( atom i, sequence s ) printf( traceFile, "function %d %x\n", {i,i} ) return c_func( i, s ) end function procedure my_c_proc( atom i, sequence s ) printf( traceFile, "function %d %x\n", {i,i} ) return c_proc( i, s ) end procedure When the program chokes, you have a trace of all the Win32 calls. From there, you should be able to determine the code that's actually at fault, and have some place to start debugging from. -- David Cuny
3. Re: Help! GPF
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Aug 03, 1999
- 387 views
Oops. I meant: procedure my_c_proc( atom i, sequence s ) printf( traceFile, "function %d %x\n", {i,i} ) c_proc( i, s ) end procedure instead of: procedure my_c_proc( atom i, sequence s ) printf( traceFile, "function %d %x\n", {i,i} ) return c_proc( i, s ) end procedure -- David Cuny
4. Re: Help! GPF
- Posted by Bernie Ryan <bwryan at PCOM.NET> Aug 03, 1999
- 375 views
Brent You might check your soundcard and be sure that you don't have any IRQ or DMA conflicts. Try running the program on another PC with a different soundcard. You did not mention what OS you are using but there are some routines that are in the win32lib.ew that were written for use in WIN32 and are obsolute and may not be compatible with WINNT or WIN98 because these OS's use some newer functions especially in Multimedia functions. Bernie
5. Re: Help! GPF
- Posted by Brent Hugh <bhugh at CSTP.UMKC.EDU> Aug 03, 1999
- 408 views
- Last edited Aug 04, 1999
At 04:19 PM 8/3/99 -0500, you wrote: >Hi all, > >I'm developing a windows midi application in Euphoria and I am having the >most vexatious possible GPF happen with some regularity. > >The GPF happens just after the program starts, before the main window even >pops up. It happens occasionally--once every 5 or 10 times the program runs. I tried David's advice and traced all the c_func calls in win32lib. I got a really nice log file (actually not just one--a lot of really nice big ones). The last part of the log file is always the same, right before the "application error". Here is the last bit (a long stretch of the last bit is quoted at the end of the message, for your entertainment): >function 22 16, params 4080 FF0 10 A 1 1 0 0 window 10 >function 22 16, params 3024 BD0 10 A 1 1 0 0 window 9 >function 22 16, params 3260 CBC 10 A 1 1 0 0 window 8 >function 22 16, params 3840 F00 10 A 1 1 0 0 window 5 >function 22 16, params 3388 D3C 10 A 1 1 0 0 window 1 >function 22 16, params 4080 FF0 28 1C 0 0 4294830363 FFFDE91B window 10 >function 22 16, params 3024 BD0 28 1C 0 0 4294830363 FFFDE91B window 9 >function 22 16, params 3260 CBC 28 1C 0 0 4294830363 FFFDE91B window 8 >function 22 16, params 3840 F00 28 1C 0 0 4294830363 FFFDE91B window 5 >function 22 16, params 3388 D3C 28 1C 0 0 4294830363 FFFDE91B window 1 Each number is given twice (first in dec., then in hex). Function 22 is DefWindowProcA; in these 10 examples it is being called from the last line in win32lib's WndProc(). Windows 1,5,8,9 and 10 are my main windows, created with create(Window, . . . ). iMsg=#A is WM_ENABLE; it is sent with flag=TRUE (1). iMsg=#1C is WM_ACTIVATEAPP; it is sent with flag=FALSE (0). So basically what is happening here is that all my windows are being enabled and then they are all being deactivated because some other app is going to be taking over in the foreground. Then my app crashes with the infamous error message. Having said all that, I'm not sure if these statements are what is crashing it. Perhaps they are just a side effect--something else (say exw?) is opening a window and coming to the foreground; when it does, it crashes--something like that. At any rate, I'm pretty sure it is not these statements specifically that are causing the problem (I trapped the last 5, stopping them completely, and this had absolutely no effect). I think they are either a symptom or a side effect of something else. Any other ideas? I'm plumb out of them . . . --Brent last bit of the log file: function 93 5D, params 1534 5FE 0 0 0 0 0 0 function 94 5E, params 1534 5FE 8 8 function 94 5E, params 1534 5FE 4 4 function 94 5E, params 1534 5FE 10 A function 94 5E, params 1534 5FE 6 6 function 95 5F, params 1534 5FE 5930992 5A7FF0 1 1 function 96 60, params 8074816 7B3640 function 99 63, params 1534 5FE -1 FFFFFFFF function 25 19, params 2944 B80 1534 5FE function 16 10, params 2944 B80 48 30 2728 AA8 -1 FFFFFFFF function 62 3E, params -2144039672 80348D08 2944 B80 48 30 2728 AA8 4294967295 FFFFFFFF function 24 18, params 736 2E0 function 89 59, params 5990 1766 function 90 5A, params 5990 1766 2 2 function 91 5B, params 5990 1766 0 0 1 1 function 92 5C, params 5990 1766 0 0 0 0 0 0 function 93 5D, params 5990 1766 0 0 0 0 0 0 function 94 5E, params 5990 1766 8 8 function 94 5E, params 5990 1766 4 4 function 94 5E, params 5990 1766 10 A function 94 5E, params 5990 1766 6 6 function 95 5F, params 5990 1766 5930992 5A7FF0 1 1 function 96 60, params 8074928 7B36B0 function 99 63, params 5990 1766 -1 FFFFFFFF function 25 19, params 736 2E0 5990 1766 function 16 10, params 736 2E0 48 30 2100 834 -1 FFFFFFFF function 62 3E, params -1 FFFFFFFF 736 2E0 48 30 2100 834 4294967295 FFFFFFFF function 22 16, params 4080 FF0 31 1F 0 0 0 0 function 22 16, params 4080 FF0 10 A 0 0 0 0 function 22 16, params 3024 BD0 31 1F 0 0 0 0 function 22 16, params 3024 BD0 10 A 0 0 0 0 function 22 16, params 3260 CBC 31 1F 0 0 0 0 function 22 16, params 3260 CBC 10 A 0 0 0 0 function 22 16, params 3840 F00 31 1F 0 0 0 0 function 22 16, params 3840 F00 10 A 0 0 0 0 function 22 16, params 3388 D3C 31 1F 0 0 0 0 function 22 16, params 3388 D3C 10 A 0 0 0 0 function 22 16, params 4080 FF0 28 1C 1 1 4294830363 FFFDE91B function 22 16, params 3024 BD0 28 1C 1 1 4294830363 FFFDE91B function 22 16, params 3260 CBC 28 1C 1 1 4294830363 FFFDE91B function 22 16, params 3840 F00 28 1C 1 1 4294830363 FFFDE91B function 22 16, params 3388 D3C 28 1C 1 1 4294830363 FFFDE91B function 62 3E, params -2144040222 80348AE2 3416 D58 5 5 0 0 0 0 function 49 31, params 3388 D3C 0 0 500 1F4 0 0 function 49 31, params 3388 D3C 0 0 500 1F4 0 0 function 49 31, params 3388 D3C 0 0 500 1F4 0 0 function 22 16, params 4080 FF0 10 A 1 1 0 0 window 10 function 22 16, params 3024 BD0 10 A 1 1 0 0 window 9 function 22 16, params 3260 CBC 10 A 1 1 0 0 window 8 function 22 16, params 3840 F00 10 A 1 1 0 0 window 5 function 22 16, params 3388 D3C 10 A 1 1 0 0 window 1 function 22 16, params 4080 FF0 28 1C 0 0 4294830363 FFFDE91B window 10 function 22 16, params 3024 BD0 28 1C 0 0 4294830363 FFFDE91B window 9 function 22 16, params 3260 CBC 28 1C 0 0 4294830363 FFFDE91B window 8 function 22 16, params 3840 F00 28 1C 0 0 4294830363 FFFDE91B window 5 function 22 16, params 3388 D3C 28 1C 0 0 4294830363 FFFDE91B window 1 ++++++++++++++++++++ Brent Hugh / bhugh at cstp.umkc.edu ++++++++++++++++++++ ++++++++ University of Missouri-Kansas City, Conservatory of Music +++++++ ++ Sheet Music/Recordings: http://www.sunflower.org/~bhugh/pathetic.spm ++ + Internet Piano Concert: http://cctr.umkc.edu/userx/bhugh/recital.html + ++++++++++ Classical Piano MP3s http://www.mp3.com/brent_d_hugh ++++++++++
6. Re: Help! GPF
- Posted by Kat <KSMiTH at PELL.NET> Aug 04, 1999
- 385 views
----- Original Message ----- From: Brent Hugh <bhugh at CSTP.UMKC.EDU> To: <EUPHORIA at LISTSERV.MUOHIO.EDU> Sent: Tuesday, August 03, 1999 10:45 PM Subject: Re: Help! GPF <snip> > in win32lib's WndProc(). Windows 1,5,8,9 and 10 are my main windows, <snip> > So basically what is happening here is that all my windows are being > enabled and then they are all being deactivated because some other app is > going to be taking over in the foreground. Then my app crashes with the > infamous error message. This may or may not be relavant to Eu, but in Mirc, if i have enough windows open, and close them all at the same time, i get a GPF too, and win95 will shut down Mirc. This caught my eye because i was thinking long-term of replacing *this* mirc client with some Eu code, looks like i'll have the same windows closing problem. I solved this in mirc with timers, since the windows are closed by a remote command, in a loop, i used the loop var as the time delay to close each window one second apart. Maybe this will help you to gain insight into the actual win95 problem, whatever it is. Kat
7. Re: Help! GPF
- Posted by Brent Hugh <bhugh at CSTP.UMKC.EDU> Aug 04, 1999
- 386 views
At 04:19 PM 8/3/99 -0500, you wrote: >Hi all, > >I'm developing a windows midi application in Euphoria and I am having the >most vexatious possible GPF happen with some regularity. > >The GPF happens just after the program starts, before the main window even >pops up. It happens occasionally--once every 5 or 10 times the program runs. Hi again, Being half pit-bull, I just couldn't let this go. I decided to find the minimum amount of program required to create the error. Soon I was down to just 1. Windows 2. Menu & submenu items 3. Some buttons, checkboxes, EditTexts and groups 4. A few variable declarations and just a bit of adding and multiplying necessary to calculate position of window elements. 5. No includes except win32lib. 6. NO handlers (onClick, etc.), just simple create() statements 7. ALL other parts of the application deleted. Still, the same GPF would appear. I tried deleting all the menu items. Miraculously, the GPF disappeared! Then I put the menu items back in, but deleted the buttons, checkboxes, edittexts, and groups. GPF disappears again! I conclude that the GPF is caused by some subtle bug or interaction between the menu items and the other window elements. Perhaps, some time after the menu elements are created, they cause a message to be sent which interferes with something about the checkboxes etc. I rearrange the program, keeping all the same elements, but putting menus AFTER all the other window elements such as checkboxes, edittexts, buttons, groups. GPF disappears--or at least happens so seldom I haven't noticed it yet. Again, I suspect some subtle bug in the menu/submenu code of win32lib. In the meanwhile, if you get occasional GPFs when creating these window items (ie, just on startup, or just when these windows/window items are created), try create()ing menus/submenus AFTER all the other window elements. --Brent ++++++++++++++++++++ Brent Hugh / bhugh at cstp.umkc.edu ++++++++++++++++++++ ++++++++ University of Missouri-Kansas City, Conservatory of Music +++++++ ++ Sheet Music/Recordings: http://www.sunflower.org/~bhugh/pathetic.spm ++ + Internet Piano Concert: http://cctr.umkc.edu/userx/bhugh/recital.html + ++++++++++ Classical Piano MP3s http://www.mp3.com/brent_d_hugh ++++++++++
8. Re: Help! GPF
- Posted by Robert Craig <rds at ATTCANADA.NET> Aug 04, 1999
- 416 views
------=_NextPart_000_006E_01BEDE94.3AA26580 charset="iso-8859-1" Brent Hugh writes: > I'm developing a windows midi application in Euphoria > and I am having the most vexatious possible GPF happen > with some regularity. When you encounter a crash like this, you should try using safe.e in place of machine.e. Copy euphoria\include\safe.e to your current directory (containing your program) and rename it as machine.e. It will replace peek() and poke() and some other routines with safer versions that do a lot of error checking. Since v2.1 came out, I've enhanced the error checking of safe.e, and I now use a new combination of safe.e and machine.e. They'll be in the next DOS/Windows release. They're already in the Linux pre-alpha release. I've attached them. Regards, Rob Craig Rapid Deployment Software http://members.aol.com/FilesEu/ ------=_NextPart_000_006E_01BEDE94.3AA26580 name="safe.e" Content-Transfer-Encoding: quoted-printable
9. Re: Help! GPF
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Aug 04, 1999
- 409 views
Robert Craig wrote: > When you encounter a crash like this, > you should try using safe.e in place > of machine.e. It GPFed just the same. -- David Cuny
10. Re: Help! GPF
- Posted by Bernie Ryan <bwryan at PCOM.NET> Aug 04, 1999
- 422 views
- Last edited Aug 05, 1999
If you are calling the window's API with the wrong TYPE of parameters, that will generate GPF's.
11. Re: Help! GPF
- Posted by David Cuny <dcuny at LANSET.COM> Aug 04, 1999
- 394 views
I *think* I'm making a bit of progress on the GPF, but I'm not sure. Here's what I know and suspect so far. The event names are approximate; I'm going by memory. Win32Lib is happily chugging along, processing Window events that are associated with painting the controls - WM_ERASEBKGND and WM_COLORCNGSTATIC; that sort of thing. Nothing unusual at all. Controls are popping up in the window as they should. Then one of the menu items gets a WM_PAINT event. Huh? I didn't think menu items got paint events. Besides, the paint event should belong to the next ordinal control, not a menu item. So this looks suspicious. Win32Lib tries to let the menu item's default handler routine take care of the WM_PAINT event, calling the stored default event handler. But I'm not even sure that a menu item *has* a default event handler routine stored - there's probably a zero for a value. Win32Lib never returns from the call to the c_func() - I think this is where it goes off to la-la land. The next event is a WM_CANCELSTATE event. This event is triggered when Windows is about to take away focus from a window, and gives the application or control a chance to gracefully drop the mouse if it's done a modal grab. This is usually issued just before popping up a modal dialog box. This is followed by a WM_LOSTFOCUS as the window loses focus, and at this point, I think that Windows is putting up the dialog box displaying the GPF information. Focus returns to the window with a WM_GOTFOCUS, and from that point on, the only event being processed is the WM_PAINT event, aimed at the same menu item: WM_PAINT WM_PAINT WM_PAINT etc. My guess is that, for some unknown reason, Win32Lib is somehow mis-identifying the control that the handle is associated with, and pointing to the menu item instead. I'm not sure how that could be happening, since it just does a find() on a list of handles. Why is this happening? I don't know. Maybe it has something to do with the events taking place outside the WinMain loop; maybe I've done something really stupid; maybe I'm entirely on the wrong track. Hopefully I'll have better answers later. -- David Cuny
12. Re: Help! GPF
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Aug 05, 1999
- 400 views
Bernie wrote: > Your definition of AppendMenuA is not correct > in win32 library. It should be > AppendMenuA { C_LONG, C_UINT, C_UINT, C_POINTER } C_INT My documentation shows: BOOL AppendMenu( HMENU hMenu, UINT uFlags, UINT uIDNewItem, LPCTSTR lpNewItem ); and I've always assumed that any handle reference gets coded as a C_POINTER instead of C_LONG. Perhaps Rob could clear this up? This doesn't appear to be a C_POINTER/C_LONG problem, because I'm passing the handle to various Windows functions, and they seem to be working properly - attaching the menu item to the menu, and so on. And, of course, I tested it and it was still broken. But I *think* I know what the problem is, although the logic still escapes me. For reasons that still escape me, menu items and controls are ending up sharing the *same* window handle. So when find() attempts to look the handle up, it stops at the menu item, instead of finding the control. There are two possibilities: I'm reading the handle wrong, or there really are duplicate handles. Since code that uses these handles appears to work, my suspicion is that the handles are not unique, and Windows relies on context to make sense of them. If this is incorrect, someone please clue me in on what's really going on. Here's a dump of the window handles in an errant Win32Lib program: window_handle = {2652,2340,2340,2344,2344,2344,2348, 2348,2348,2348,2348,2348,2348,2348,2348,2348,2348, 2348,2348,2348,2352,2352,2352,2352,2352,2352,2356, 2356,2656,2660,2664,2668,2672,2676,2680,2684,2688, 2692,2696,2700,2708,2720,2716,2712,2724,2736,2108, 2744,2728,2752,2748,2704,2732,2760,2740,1816,1888, 1812,1876,1880,1828,1824,1820,1840,1836,1832,1884, 1892,1896,1872,1704,1708,1848,1852,1856,1860,1864, 1868,1844,1900,1808,1744,1736,1740,2764,2768,2400, 2784,2776,2800,2252,2780,2772,2808,2796,2348,2840, 2356,2340,2360,2424,2848,2344,2856,2852,2336,2836, 2864,2868,2872,2876,2880,2884,2888,2892,2896,2900, 2904,2908,2912,2916,2920,2924,2928,2932,2936,2940, 2944,2948,2952,2956,2960,2964,2968,2972,2976,2980, 2984,2988,2992,2996,3000,3004,3008,3012,3016,3020, 3024} There have always been duplicate handles in the window_handle list - for example, the window handle of a MenuItem actually contains the handle of the parent Menu. This doesn't cause problems with find(), since it stops at the first control that it finds, and the window has to be defined before the menu. Controls #2 and #3 show the sharing of a handle between a Menu and a MenuItem. The error is that control #83 is misidentified as #27 - they both share the same value of 2356 as their handle. There are several solutions I can think of: 1. Exclude menus and menu items from the search 2. Create another sequence of window and control handles 3. Store the value in the GWL_USERDATA area I'll probably go with option #3, since that's what Llama uses. -- David Cuny
13. Re: Help! GPF
- Posted by Bernie Ryan <bwryan at PCOM.NET> Aug 05, 1999
- 403 views
C_LONG has the constant #01000004 I interpret this to mean convert a four byte Euphoria value to a SIGNED "C" INTEGER C_POINTER has the constant #02000004 I interpert this to mean convert a four byte Euphoria value to a UNSIGNED "C" INTERGER Therefore if you pass a UNSIGNED INTEGER to "C" and "C" thinks it is a SIGNED value then large integers will be assumed as negative and cause errors. Bernie
14. Re: Help! GPF
- Posted by "Cuny, David" <David.Cuny at DSS.CA.GOV> Aug 05, 1999
- 403 views
Bernie Ryan initially written: >> The first parameter you defined as a >> C_POINTER ( the menu handle ) It should >> be a C_LONG and then: > C_LONG has the constant #01000004 I interpret > this to mean convert a four byte Euphoria value > to a SIGNED "C" INTEGER The Menu handle should be a C_POINTER/C_ULONG/C_UINT, not a C_LONG as you suggest. Casting the handle to C_LONG/C_INT runs into the problems you described with reading it as a negative number. -- David Cuny
15. Re: Help! GPF
- Posted by Bernie Ryan <bwryan at PCOM.NET> Aug 05, 1999
- 402 views
Then ROB has to tell us exactly what he is doing in his code to convert the C_xxxxx values into "C" values because we do not know the meaning of his CONSTANTs especially the upper digit in the constant.
16. Re: Help! GPF
- Posted by Robert Craig <rds at ATTCANADA.NET> Aug 05, 1999
- 398 views
Bernie Ryan writes: > It should be AppendMenuA > { C_LONG, C_UINT, C_UINT,C_POINTER } C_INT > > The first parameter you defined as a C_POINTER > ( the menu handle ) It should be a C_LONG because > Rob handles a C_POINTER different than a C_LONG > internally. It may cause a problem if the handle is a certain > value and this maybe what is causing the GPF's. As far as passing values to a C routine is concerned, C_LONG, C_POINTER and all other integer types are *all equivalent*. It *doesn't matter* how you declare the parameters in your define_c_proc() or define_c_func() statement. In WIN32, all C integer types, from 1 byte to 4 bytes in size are pushed onto the call stack as a generic 4-byte quantity. It's up to receiver of the value to interpret it as a signed or unsigned value, a pointer, or whatever. (C_DOUBLE is different - Euphoria will push an 8-byte floating-point number onto the stack.) There *is* a difference between signed and unsigned integers, but only when you declare the *return-type* in define_c_func(). It can affect whether you get a negative integer or a large positive integer returned from c_func(). Why have so many different C types when they are mostly all equivalent? 1. Maybe some extra warnings could be added in the compiler, or in safe.e to flag obvious cases where you are passing a value that is not consistent with the C parameter type. e.g. you declared a parameter as C_UINT, but you are passing a negative value. 2. On other platforms, things might be passed differently, e.g. chars might be passed differently from longs, or maybe pointers are 8 bytes, not 4. The interpreter would need to know the exact type. Regards, Rob Craig Rapid Deployment Software http://members.aol.com/FilesEu/