1 / 13

Debugging Scenarios

Debugging Scenarios. If program crashes, find core file Start debugger and snarf core file as well Use backtrace feature “where” (or “bt”) to find where the code crashed along with state of variables at the time of crash. Good Programming Practice.

vahe
Télécharger la présentation

Debugging Scenarios

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Debugging Scenarios • If program crashes, find core file • Start debugger and snarf core file as well • Use backtrace feature “where” (or “bt”) to find where the code crashed along with state of variables at the time of crash.

  2. Good Programming Practice • Run valgrind especially for those programs which dynamically allocate memory whether or not it’s crashing. • /usr/shared/bin/valgrind • Web Page: http://valgrind.kde.org % valgrind [vgoptions] your_program [prgm args]

  3. Valgrind Features • No need to modify, recompile or relink • Can debug large programs • Usable on almost any kind of software written in any language • Works on entire program, including proprietary libraries • Works with GDB • Actively maintained % valgrind [vgoptions] your_program [prgm args]

  4. Valgrind Features • Use of unintialized memory • Read/Write of freed memory • ABR/ABW of malloc’d or new blocks • Inappropriate stack writes • Memory leaks • Mismatched use of malloc/new v.s. free/delete

  5. What valgrind can’t do (Sob!) • Cannot detect ABW/ABR of static or stack arrays. From FAQ: int static[5]; int main(void) { int stack[5]; static[5] = 0; stack [5] = 0; return 0; } Unfortunately, [it] doesn't do bounds checking on static or stack arrays. We'd like to, but it's just not possible to do in a reasonable way that fits with how [it] works. Sorry.

  6. Valgrind • Open source and actively maintained • Other developers have provided “add-ons” • Helgrind – detects data races in C & C++ that use pthreads • Massif – a profiler providing heap and stack information on running programs

  7. Final Case . . . EVENT: office_id = LWX EVENT: num_rows = 7 Hsql_query = select * from rpt where (wmo_dd not like 'SAUS4%' or (wmo_dd like 'SAUS4%' and (report like '%METAR%' or report like '%SPECI%') and report like '%RMK%')) and icao_loc_id IN ('KBWI', 'KCON', 'KIAD', 'KITR', 'KMOT', 'KPWM', 'KSLC') and (date_trunc('hour', origin) = date_trunc('hour', timestamp '2005-01-12 14:00:00') - interval '1 hour') ORDER by icao_loc_id ASC, date ASC, origin DESC Printing rows = 146 ==17183== ==17183== Invalid write of size 4 ==17183==    at 0x8071EF0: get_report (db_report.ecpp:967) ==17183==    by 0x69676972: ??? ==17183==    Address 0x2772756F is not stack'd, malloc'd or free'd Segmentation fault (core dumped) • Valgrind provides a clue . . . .

  8. Final case . . . • The offending line looks innocuous . . .an assignment • What’s going on? Let’s look again at valgrind’s output. { *hm_data = first_data; }

  9. Final case . . . ==17183== Invalid write of size 4 ==17183==    at 0x8071EF0: get_report (db_report.ecpp:967) ==17183==    by 0x69676972: ??? ==17183==    Address 0x2772756F is not stack'd, malloc'd or free'd • The last two lines provided important clues. To understand what is meant by them, a brief digression.

  10. Brief Digression • Now lets go back and look at valgrind’s output again

  11. Final Case. . . • Originally these variables referred to sane addresses in the heap area, but “something” happened, not at the line where the crash happened, but earlier. • Using DDD and watching the address of the affected variable, an ABW of a completely unrelated stack array was found. This clobbered pointer values. If you dereference invalid addresses -> SEGV.

  12. When stumped? • Try to use all available clues offered. • Get another set of eyes to look at the problem. • Explaining the problem to someone else helps.

  13. Questions/Comments? • This presentation will be archived on the Quality Assurance web page under the “Training” link on the LHS. http://www.mdl.nws.noaa.gov/qa Cece is on next week!  Her presentation will be on Tk/Tcl programming.

More Related