dev.emsdn.com

ignoring DLL exceptions

at [2008-5-4 2:22:48]

---

at [2008-5-4 2:23:51]

---

Ross Levis wrote:
I'm having great success with several of the DLL's but a couple are are
generating access violations like this:
Project Myproject.exe raised exception class C0000005 with message
'access violation at 0x00000000: read of address 0x00000000'.

I can't see any way of debugging this. I don't have access to the 3rd
party DLL source to see what is going on. These same DLL's work when
used with Winamp.

That's a strong indication that you aren't using them quite right.

Is there any way to find out what address offset in
the DLL the error occured? is it more likely that the error occured
in my code?

The message tells you what the address is: 0. What you really want is
the address of the instruction that was executed before that one, and
that isn't available.

If you can't find the problem by analyzing the source code, then you'll
probably have to trace through the code in the CPU window, noting how
far the program gets before crashing.

Perhaps the DLL is attempting to call a function in my program which is
undefined (unassigned pointer address)?

Either your program or the DLL is trying to call a function via a null
pointer.

var
p: procedure;
begin
p := nil;
p;
end;

I've checked all the functions
and procedures that are called from the DLL to my program, and these
appear to all be assigned correctly. I haven't altered the pointers to
the procedures that are called from my program to the DLL (the reverse
situation). I think that is correct. I've never attempted to use DLL's
at all in the past so this is all new to me.

I'm wondering if Winamp has some way to ignore the exceptions caused by
buggy plugins.

Maybe. It could be as simple as this:

try
CallDLL;
except
end;

Trapping exceptions like that is not uncommon when dealing with plug-ins
since you don't usually want a plug-in to be able to crash the host
program. the other hand, the plug-in isn't supposed to be generating
access violations in the first place -- it's not normal behavior for the
DLL.

I can do this while running in the IDE, and one problem
DLL seems to work fine just clicking F9 after an exception occurs. So
is there some way to prevent the exceptions from terminating the app?

There's only one way to prevent an exception from terminating the
program, and that is to catch it.

When the app is run outside the IDE, I don't get any errors at all, the
app just terminates.

That's because you don't have Delphi's debugger there. Debuggers get
first dibs on exceptions that occur in the programs they're debugging.

at [2008-5-4 2:24:50]

---

at [2008-5-4 2:25:55]

---

I don't think it's quite as simple as that. The problem is not occuring
when my app is calling a function in the DLL, it must be occuring when
the DLL is attempting to call a function in my app. My app can be
sitting there basically idle, and the DLL is calling functions in it.
And obviously one or more of them is unassigned.

Is there any way to ignore errors in this situation?

First place to look when getting crashes accessing DLLs written in C is to
check the calling convention of the functions in your code. Are the
functions in your code that the DLL is calling specified correctly? cdecl
or stdcall?

at [2008-5-4 2:26:54]

---