We always encounter "Access Violation" error when work with D. Especially, when port C++/Java to D. The application just crash and says "Access Violation" error in the console, but doesen't tell you where the error occurs.

For a small file, a "Access Violation" can be checked line by line.
Where != or !== mismatched, where we access members of a null Object and
etc.
But for a large project with hundreds files, you can't do it easily.

You may say place breakpoints and debug it step by step. But for a GUI app, you don't known where to place the breakpoints. Debug with keyboard and mouse messege proccessing will prevent you enter some situation. It is like that when debug with bp, app never crash. when run freely, app collapsed.

My questions :

1) What causes a "Access Violation", null Object, !=/!== and ...??
2) Can dmd printf where a "Access Violation" occurs. __FILE__, __LINE__ is
okay

BTW,
1) DMD doesn't check whether all path of a function return a value just like
C++/Java compiler does at compile time. Assert error at runtime when a
return absent for a function.
2) App crash when a default absent in a switch block. DMD can't detect it at
compile time. Runtime error with message "switch default".

Shawn

Shawn Liu schrieb am Tue, 19 Apr 2005 19:01:10 +0800:
> BTW,
> 1) DMD doesn't check whether all path of a function return a value just like
> C++/Java compiler does at compile time. Assert error at runtime when a
> return absent for a function.
> 2) App crash when a default absent in a switch block. DMD can't detect it at
> compile time. Runtime error with message "switch default".

use "dmd -w source.d"

Thanks. This is help.

"Thomas Kuehne" <thomas-dloop@kuehne.thisisspam.cn> дÈëÏûÏ¢ÐÂÎÅ:s65fj2-nj3.ln1@lnews.kuehne.cn...
>
> Shawn Liu schrieb am Tue, 19 Apr 2005 19:01:10 +0800:
>> BTW,
>> 1) DMD doesn't check whether all path of a function return a value just
>> like
>> C++/Java compiler does at compile time. Assert error at runtime when a
>> return absent for a function.
>> 2) App crash when a default absent in a switch block. DMD can't detect it
>> at
>> compile time. Runtime error with message "switch default".
>
> use "dmd -w source.d"
> 

I use WinDbg for tracking down memory-related crashes. Open the executable, and run it. When it crashes, run the '!analyze -v' command to get a (very) detailed analysis. BTW, compile with -g to add symbolic debugging info.

In article <d435rj$s3l$1@digitaldaemon.com>, aleko says...
>
>I use WinDbg for tracking down memory-related crashes. Open the executable, and run it. When it crashes, run the '!analyze -v' command to get a (very) detailed analysis. BTW, compile with -g to add symbolic debugging info.

Have you gotten WinDbg to display the contents of variables, or do you just inspect memory directly?


Sean

>Have you gotten WinDbg to display the contents of variables, or do you just inspect memory directly?

Unfortunately, no. The DMD compiler doesn't generate the .PDB files that WinDbg needs to in order to do that. I have heard that Visual Studio can debug D executables, and inspect symbols, but I haven't done this myself. Maybe someone else can comment on this?

-Aleko

On Wed, 20 Apr 2005 03:39:26 +0000 (UTC), aleko <aleko_member@pathlink.com> wrote:
>> Have you gotten WinDbg to display the contents of variables, or do you just inspect memory directly?
>
> Unfortunately, no. The DMD compiler doesn't generate the .PDB files that WinDbg
> needs to in order to do that. I have heard that Visual Studio can debug D
> executables, and inspect symbols, but I haven't done this myself. Maybe someone
> else can comment on this?

http://www.prowiki.org/wiki4d/wiki.cgi?DebugEnvironments#MSDEVMSVisualStudio

Same problem, it does not "know" about D's arrays. So the best you can do is inspect the memory directly. Thanks to Arcane Jill for this quote...

<AJ>
First, you have to get your numbers displayed in hex, not in decimal. In this case 35518073867862116 happens to be 0x7E2F800000000064. So the high half - 0x7E2F8000 - is the address of the array in memory, and the low half - 0x00000064 - is the number of elements in the array.
</AJ>

Regan

Yes, you can build and debug D source files in Visual Studio.

And here I have written a tool to simplify the build job.

http://www.dnaic.com/d/en/bldtool.htm


Shawn Liu


"aleko" <aleko_member@pathlink.com> says : d44ite$26mr$1@digitaldaemon.com...
>
>>Have you gotten WinDbg to display the contents of variables, or do you
>>just
>>inspect memory directly?
>
> Unfortunately, no. The DMD compiler doesn't generate the .PDB files that
> WinDbg
> needs to in order to do that. I have heard that Visual Studio can debug D
> executables, and inspect symbols, but I haven't done this myself. Maybe
> someone
> else can comment on this?
>
> -Aleko
>
>