www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Techniques on debugging runtime errors?

reply Andrej Mitrovic <none none.none> writes:
I have this sort of runtime error in a fairly involved project:
---------------------------
main.exe - Application Error
---------------------------
The instruction at "0x0411b00e" referenced memory at "0x00000020". The memory
could not be "read".
---------------------------

Background info:
Its a realtime app, and I can't really run a debugger since there's a
high-priority thread being started by a device driver, and stepping through
code would immediately break the app. 

The app loads a DLL that processes some audio in real-time. Loading a DLL from
one vendor runs perfectly, audio gets processed and I can hear back the result.
But loading a DLL from a different vendor gives me this  runtime error. Another
thing is I can show the GUI (if its available) of either DLLs, (generally audio
plugins do come with GUI's). Both plugins show the GUI and I can interact with
it with no issues. But trying to process audio on one of the DLLs fails.

I've tried it with over a dozen vendor DLLs. So far there's only one that
fails. Its not so uncommon for an audio processing plugin to fail, but I'd like
to know _why_. There are many plugin hosts on the market, and I've tried this
specific DLL with a few of them, it seems to work. So something with my piece
of the code might be wrong.

My real question is: how do I even begin to debug code that needs to run in
realtime? There's no memory debugger for D2 that I know of (maybe Vlad will
port his Diamond to D2 one day :) ), I've tried using a stacktrace but its not
of much help, all I get back is this:

00 D:\dev\projects\sequencer\src\.\stacktrace\stacktrace.d::57(0)
_D10stacktrace10stacktrace10StackTrace32UnhandeledExceptionFilterHandlerWPvZi
01 UnhandledExceptionFilter
02 ValidateLocale

Wrapping my main() inside a try{}catch{} doesn't help either, even if I try to
catch Throwable's. So it might be an exception thrown from within a DLL. Or
not. :)

I'm a complete newbie when it comes to runtime bugs like these. Any good
resources, something to read, or techniques, to figure this out? Something
tells me I'll just have to dive in neck-deep into the disassembly..
Mar 27 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Actually it looks like I can recreate this bug in non-realtime mode as
well. I forgot that I can actually process audio at whatever timing I
want to (I haven't touched this project in a while..). Oddly enough I
can call various DLL functions but it fails the second I try to pass
some audio data to it. Other plugins work fine. I wonder what I'm
missing here..
Mar 27 2011
parent reply Daniel Green <venix1 gmail.com> writes:
On 3/27/2011 7:58 PM, Andrej Mitrovic wrote:

 Actually it looks like I can recreate this bug in non-realtime mode as
 well. I forgot that I can actually process audio at whatever timing I
 want to (I haven't touched this project in a while..). Oddly enough I
 can call various DLL functions but it fails the second I try to pass
 some audio data to it. Other plugins work fine. I wonder what I'm
 missing here..


Are you passing D data to a C or C++ dll?

It may be related to size and alignment of any data passed.  When I 
wrote wrappers for freetype2 I used long for my dll calls forgetting 
that long and int are the same size for C.

It could also be Structured Exception Handling used by Windows.
Mar 27 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I've found the problem and the solution, see this post:


I completely forgot that the VST standard has at least two different
implementations, v2.3 and v2.4. And I've also forgot that I need to
ask the DLL if it supports calling one of two different function
implementations. The problem was I was calling a function that's only
defined in the v2.4 standard, but this vendor-specific DLL conforms to
v2.3 and didn't have it.

So luckily this wasn't such a big problem at all. Yay! :)
Mar 27 2011