Tracking down Access Violations

[John Demme]

Daniel Keep wrote:

> 
> 
> Jeremy wrote:
>> In article <e4ja9v$cdi$1 at digitaldaemon.com>, David Medlock says...
>>> Jeremy wrote:
>>>> My program is starting to get fairly large, and all seems to be going
>>>> fairly well...
>>>>
>>>> UNTIL this "Error: Access Violation" started popping up. I'm not sure
>>>> where it is coming from, and I've been having a hard time tracking it
>>>> down.
>>>>
>>>> What is the best way to track these down? In some C/C++ applications, I
>>>> could actually get one of those 'Illegal Operation' windows from
>>>> Windows XP, which would tell me the instruction address, and then I
>>>> could do an object dump to see which assembly instruction messed it up:
>>>> but D just says "Error: Access violation" and that's it :(
>>>>
>>>> The "-g" option gives me "forward reference" errors so I cannot run it
>>>> through a debugger and get good results (correct?).
>>>>
>>>> It seems like the only good way to do this is to keep commenting out
>>>> code until it doesn't happen anymore (but the error is hard to
>>>> reproduce, so it's hard to know if it just hasnt happened yet or not).
>>>> Or -- add in debug writefln's everywhere and see when they stop.
>>>>
>>>> There should be a better way I hope?
>>>>
>>>>
>>> Sure.
>>>
>>> 1. Compile your files with -g.
>>> 2. run 'windbg <your-prog>.exe'
>>> 3. In Windbg click File -> open
>>> 4. Type in the name of your source file with main() in it, and click OK
>>> 5. Click Run or Hit F5.
>>>
>>> When the access violation occurs, the source line is highlighted.
>>>
>>> -DavidM
>> 
>> That would be awesome if step 1 worked :)
>> 
>> Under -debug mode, all access violations and data errors etc. should
>> print the module / line number... but fix that "-g" bug first, please!
>> 
>> Is there a linux debugger that works well with D (e.g. does GDB work good
>> enough?)
>> 
> 
> [Disclaimer: my experiences were with GDB and GDC under Cygwin]
> 
> GDB, once patched for D support, works well enough.  You can set
> breakpoints, step around code, etc.  However, there are a few rough edges:
> 
> 1. GDB doesn't mangle D names.  This means that in order to set a
> breakpoint for your "main" function, you need to tell GDB to break on
> "_Dmain".  It only gets worse as the functions get longer.  Thankfully,
> you can always use line numbers :P
> 
> 2. Class member access doesn't seem to work all the time.
> 
> 3. Local variables appear to get "cached" by GDB sometimes after you
> examine them, and then refuse to update to the new value.
> 
> That said, GDB was *very* useful for tracking down segfaults: told me
> exactly where it happened.  Like I said, it's rough, but it works.
> 
> Let me just dig up the patch url...
> http://home.earthlink.net/%7Edvdfrdmn/d/
> 
> Hope this helps.
> 
> -- Daniel
> 

Wrong patch URL-- That one's for the GCC patch.

http://dsource.org/projects/gdb-patches
Is the correct site for the GDB patches.  Expect more of the patch as I get
more free time, but no promises.

~John Demme