Tracking down Access Violations

[Daniel Keep]

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

-- 

v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D
a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP    http://hackerkey.com/