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?

"Jeremy" <Jeremy_member@pathlink.com> wrote in message news:e4j2uv$7av$1@digitaldaemon.com...

> The "-g" option gives me "forward reference" errors so I cannot run it
> through a
> debugger and get good results (correct?).

That sounds like a bug.  You shouldn't get forward reference errors just by turning on the "generate debug info" flag.  That's the best way to track down the access violation - debug the program.  If you can get that working...

(Of course, if you're like me, chances are this is caused by dereferencing a null object reference.  Which could be checked by D before calling any methods on objects, but Walter feels that access violations are _more_ than enough to track down bugs.)

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?

I dunno about access violations, but when I get a segfault on Linux, I run it through GDB and it gives me a backtrace... I don't need debugging information to get a backtrace-- the debugging information would just give me the line number of the error, without it I can at least get the method which the error is in.

~John Demme

Jarrett Billingsley wrote:
> "Jeremy" <Jeremy_member@pathlink.com> wrote in message news:e4j2uv$7av$1@digitaldaemon.com...
> 
>> The "-g" option gives me "forward reference" errors so I cannot run it through a
>> debugger and get good results (correct?).
> 
> That sounds like a bug.  You shouldn't get forward reference errors just by turning on the "generate debug info" flag.  That's the best way to track down the access violation - debug the program.  If you can get that working...

Yes, it's a known bug that has hit other people, too. Including me. I'm hoping it gets fixed in the next release.

Jarrett Billingsley wrote:
> "Jeremy" <Jeremy_member@pathlink.com> wrote in message news:e4j2uv$7av$1@digitaldaemon.com...
> 
> 
>>The "-g" option gives me "forward reference" errors so I cannot run it through a
>>debugger and get good results (correct?).
> 
> 
> That sounds like a bug.  You shouldn't get forward reference errors just by turning on the "generate debug info" flag.  That's the best way to track down the access violation - debug the program.  If you can get that working...
> 
> (Of course, if you're like me, chances are this is caused by dereferencing a null object reference.  Which could be checked by D before calling any methods on objects, but Walter feels that access violations are _more_ than enough to track down bugs.) 
> 

Hehe.. *poke poke*

I've run into this little snag before, when printf just doesn't cut it, and when AVs are just about as useless as JPEGs to Helen Keller...

-- 
Regards,
James Dunne

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

On Thu, 18 May 2006 22:25:24 -0400, David Medlock wrote:

> Jeremy wrote:
>> The "-g" option gives me "forward reference" errors so I cannot run it through a debugger and get good results (correct?).

> 1. Compile your files with -g.

Oops. If the compiler allows you to compile with "-g" ;-)

> 2. run 'windbg <your-prog>.exe'

Assuming you are running on Windows and have the 'right' version of windbg.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
19/05/2006 1:05:45 PM

James Dunne wrote:
> Hehe.. *poke poke*
> 
> I've run into this little snag before, when printf just doesn't cut it, and when AVs are just about as useless as JPEGs to Helen Keller...

It's all about the Pentiums, yeah!

*cough*

Sorry about that.

	-- Daniel Keep

-- 

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

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

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

-- 

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