GPF on keypress

[Erwin van de Wiel]

I have a problem with a pb dll that I'm using with vb.
The dll is a simple dll that read/sort/arrange some data from
a text file. What the program does is:

- first read/sort/arrange data from a flat text file (pb dll)
- create a file with all the sorted data (from here all the work is
done for the dll and all text files are closed)
- second vb takes over and starts reading from the text file to input
the data in a database.

The problem happens when vb is reading the text file. When the
enter key is being pressed a GPF is occuring on the pb dll.

I don't have any idea why this is happening.

gpf: The instruction at "0x01e755d8" referenced memory at "0x0028ed48".
The memory could not be "read".




[This message has been edited by Erwin van de Wiel (edited November 11, 2000).]

[Lance Edmonds]

It sounds like your code could be reading beyond the boundary of an array, or one of the other usual suspects (invalid pointer usage such as passing a pointer to local storage that expires when the sub/function terminates, or just plainly passing/using a wrong pointer; poor inline assembler, etc).

However, your description infers that your DLL has finished running, yet the GPF occurs in the DLL. This imples that something quite unanticipated is occuring.

In this situation, you need to find the point where the GPF is occuring before deciding how to solve it. Assuming that you are not doing a callback into VB (that is, your VB code is simply calling a sub/function in the DLL and then continuing on), I would add code into your DLL to write into a LOG file, say, ever 5 lines of code. That way you can analyse the log file after a trial run, and see the approximate point that the crash occurs.

From there, you can use the same strategy to narrow the problematic line of code right down.

However, since there is a possibility that you are dealing with a memory-corruption issue, the cause of the corruption could be elsewhere in your code, but only becoming evident when the corrupted memory is referenced. If this is the case, debugging could be a little more tricky.

I hope this helps. If you need additional help, then I suggest that you post the code, and maybe we can spot something obvious.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Erwin vande Wiel]

Thanks Lance. I will try the things you suggested maybe there is
something I'm doing wrong. If it doesn't solve anything I will post
some pieces of the code. There is no inline assembly, but I use a lot
redim (preserve) of arrays. I can't just figure out why a gpf could
occur on a keypress. I simply call a function in a pb dll that creates
the file for vb to read. Vb only starts reading the file when the function
is returning 1 (file is created without errors).
Is it possible that a gpf occurs when there are almost no resources left ??

Erwin van de Wiel

------------------

[Lance Edmonds]

"Is it possible that a gpf occurs when there are almost no resources left ?? "

Depending on what happens, then yes. For example, if you expect an API to return a valid pointer and it returns NUL (zero) because the API failed, then attempting to reach the target of the pointer will cause a GPF.

There are obviously many more possible causes too. In Windows, it is the responsibility of the programmer to write code that traps and tests for errors that may cause the app to fail under extreme circumstances (like running on a clients computer! )



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>