www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tracking down Access Violations

reply Jeremy <Jeremy_member pathlink.com> writes:
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?
May 18 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.)
May 18 2006
next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
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.
May 18 2006
prev sibling parent reply James Dunne <james.jdunne gmail.com> writes:
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
May 18 2006
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
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/
May 18 2006
prev sibling next sibling parent John Demme <me teqdruid.com> writes:
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
May 18 2006
prev sibling next sibling parent reply David Medlock <noone nowhere.com> writes:
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
May 18 2006
next sibling parent Derek Parnell <derek psych.ward> writes:
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
May 18 2006
prev sibling parent reply Jeremy <Jeremy_member pathlink.com> writes:
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?)
May 18 2006
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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/
May 18 2006
parent reply John Demme <me teqdruid.com> writes:
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
May 18 2006
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
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/
May 18 2006
prev sibling parent reply BCS <BCS pathlink.com> writes:
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?
 
 
May 19 2006
parent reply Jeremy <Jeremy_member pathlink.com> writes:
In article <e4l2dk$2uhd$1 digitaldaemon.com>, BCS says...
IIRC their is a version of Phobos that does stack traces.
Really? Where? :-O
May 19 2006
next sibling parent BCS <BCS pathlink.com> writes:
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...
May 19 2006
prev sibling parent BCS <BCS_member pathlink.com> writes:
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>
May 19 2006