Daniel Keep wrote:

> 
> 
> Jeremy wrote:
>> In article <e4ja9v$cdi$1@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

John Demme wrote:
> Daniel Keep wrote:
>> [snip]
>> 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
> 

Oops.  Thanks for the correction :)

	-- Daniel Keep

-- 

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

IIRC their is a version of Phobos that does stack traces.

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?
> 
> 

In article <e4l2dk$2uhd$1@digitaldaemon.com>, BCS says...
>
>IIRC their is a version of Phobos that does stack traces.
>

Really? Where? :-O

Jeremy wrote:
> In article <e4l2dk$2uhd$1@digitaldaemon.com>, BCS says...
> 
>>IIRC their is a version of Phobos that does stack traces.
> 
> Really? Where? :-O

http://shinh.skr.jp/d/backtrace.tgz
http://shinh.skr.jp/d/backtrace.zip

never used it so...

In article <e4l47p$52$1@digitaldaemon.com>, Jeremy says...
>
>In article <e4l2dk$2uhd$1@digitaldaemon.com>, BCS says...
>>
>>IIRC their is a version of Phobos that does stack traces.
>
>Really? Where? :-O
>

backtracing your own stuff shouldn't be to hard, put this at the top of each function. (you will still need to look up function from line numbers but it's the best you can do until a __FUNC_NAME__ const it added).


vertion(backtrace) scope(falure) writef(__FILE__":" ~ itoa!(__LINE__)~\n);


you will need the itoa template:
(from http://www.digitalmars.com/d/templates-revisited.html


<code>
template decimalDigit(int n)	// [3]
{
const char[] decimalDigit = "0123456789"[n..n+1];
}

template itoa(long n)
{
static if (n < 0)
const char[] itoa = "-" ~ itoa!(-n);
else static if (n < 10)
const char[] itoa = decimalDigit!(n);
else
const char[] itoa = itoa!(n/10L) ~ decimalDigit!(n%10L);
}

</code>