digitalmars.D - Tracking down Access Violations
- Jeremy (16/16) May 18 2006 My program is starting to get fairly large, and all seems to be going fa...
- Jarrett Billingsley (10/13) May 18 2006 That sounds like a bug. You shouldn't get forward reference errors just...
- Mike Parker (3/14) May 18 2006 Yes, it's a known bug that has hit other people, too. Including me. I'm
- James Dunne (7/26) May 18 2006 Hehe.. *poke poke*
- Daniel Keep (8/12) May 18 2006 It's all about the Pentiums, yeah!
- John Demme (7/29) May 18 2006 I dunno about access violations, but when I get a segfault on Linux, I r...
- David Medlock (9/32) May 18 2006 Sure.
- Derek Parnell (9/14) May 18 2006 Assuming you are running on Windows and have the 'right' version of wind...
- Jeremy (6/38) May 18 2006 That would be awesome if step 1 worked :)
- Daniel Keep (19/64) May 18 2006 [Disclaimer: my experiences were with GDB and GDC under Cygwin]
- John Demme (6/81) May 18 2006 Wrong patch URL-- That one's for the GCC patch.
- Daniel Keep (6/24) May 18 2006 Oops. Thanks for the correction :)
- BCS (2/25) May 19 2006
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
"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
Mike Parker <aldacron71 yahoo.com> Jarrett Billingsley wrote:"Jeremy" <Jeremy_member pathlink.com> wrote in message news:e4j2uv$7av$1 digitaldaemon.com...Yes, it's a known bug that has hit other people, too. Including me. I'm hoping it gets fixed in the next release.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...
May 18 2006
Jarrett Billingsley wrote:"Jeremy" <Jeremy_member pathlink.com> wrote in message news:e4j2uv$7av$1 digitaldaemon.com...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 DunneThe "-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
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
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
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
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
In article <e4ja9v$cdi$1 digitaldaemon.com>, David Medlock says...Jeremy wrote: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?)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
Jeremy wrote:In article <e4ja9v$cdi$1 digitaldaemon.com>, David Medlock says...[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/Jeremy wrote: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?)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
Daniel Keep wrote:Jeremy wrote: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 DemmeIn article <e4ja9v$cdi$1 digitaldaemon.com>, David Medlock says...[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. -- DanielJeremy wrote: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?)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
John Demme wrote:Daniel Keep wrote:Oops. Thanks for the correction :) -- Daniel Keep -- v1sw5+8Yhw5ln4+5pr6OFma8u6+7Lw4Tm6+7l6+7D a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/[snip] Let me just dig up the patch url... http://home.earthlink.net/%7Edvdfrdmn/d/ Hope this helps. -- DanielWrong 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
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
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
Jeremy wrote:In article <e4l2dk$2uhd$1 digitaldaemon.com>, BCS says...http://shinh.skr.jp/d/backtrace.tgz http://shinh.skr.jp/d/backtrace.zip never used it so...IIRC their is a version of Phobos that does stack traces.Really? Where? :-O
May 19 2006
In article <e4l47p$52$1 digitaldaemon.com>, Jeremy says...In article <e4l2dk$2uhd$1 digitaldaemon.com>, BCS says...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>IIRC their is a version of Phobos that does stack traces.Really? Where? :-O
May 19 2006