1. Help! GPF

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 ++++++++++

new topic     » topic index » view message » categorize

2. Re: Help! GPF

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: Help! GPF

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

new topic     » goto parent     » topic index » view message » categorize

4. Re: Help! GPF

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: Help! GPF

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 ++++++++++

new topic     » goto parent     » topic index » view message » categorize

6. Re: Help! GPF

----- 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

new topic     » goto parent     » topic index » view message » categorize

7. Re: Help! GPF

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 ++++++++++

new topic     » goto parent     » topic index » view message » categorize

8. Re: Help! GPF

------=_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

new topic     » goto parent     » topic index » view message » categorize

9. Re: Help! GPF

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. sad

-- David Cuny

new topic     » goto parent     » topic index » view message » categorize

10. Re: Help! GPF

If you are calling the window's API with the wrong TYPE of parameters,
  that will generate GPF's.

new topic     » goto parent     » topic index » view message » categorize

11. Re: Help! GPF

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

new topic     » goto parent     » topic index » view message » categorize

12. Re: Help! GPF

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

new topic     » goto parent     » topic index » view message » categorize

13. Re: Help! GPF

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

new topic     » goto parent     » topic index » view message » categorize

14. Re: Help! GPF

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

new topic     » goto parent     » topic index » view message » categorize

15. Re: Help! GPF

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.

new topic     » goto parent     » topic index » view message » categorize

16. Re: Help! GPF

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/

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu