Debugging a rare / unreproducible bug..

This is a discussion on Debugging a rare / unreproducible bug.. within the A Brief History of Cprogramming.com forums, part of the Community Boards category; For bounds checker, I really recommend using Visual Studio because it provides very nice debugging tools, including check for overruns, ...

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    For bounds checker, I really recommend using Visual Studio because it provides very nice debugging tools, including check for overruns, both on stack and heap.
    Another good idea when something goes wrong is typically using Just-in-time (JIT), which can point you to a line of code that crashed a program. Visual Studio supports this.
    Or you can attach a debugger to it and hope it crashes, at which time the debugger can catch the line it occured at.

    Anyway, as people have pointed out already, you should fix the debug errors first and they are very likely the problem.
    As for debugging "unknown" problems, the first thing you have to do if figure out what type of error you get. Very common errors are double-free, using deleted pointers, buffer overruns and clobbering memory. Good debuggers and tools spot many of these common problems.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    The superhaterodyne twomers's Avatar
    Join Date
    Dec 2005
    Location
    Ireland
    Posts
    2,262
    >> Right, maybe I'll have a look at the code. Thanks.
    For a program bug? Really? You sure that's the way to do it?

  3. #18
    In the Land of Diddly-Doo g4j31a5's Avatar
    Join Date
    Jul 2006
    Posts
    476
    Quote Originally Posted by dwks View Post
    It's a program that examines your code, without compiling it or running it, and identifies bad practises or possible buffer overruns and that kind of thing. I've used splint before, and it works pretty well.
    Wikipedia page: http://en.wikipedia.org/wiki/Splint_...amming_tool%29
    Download page: http://www.splint.org/
    Windows download page: http://www.splint.org/win32.html


    It's a program or a library that examines your program as it is run, detecting any buffer overruns or memory errors. The only one I've really used is Valgrind, which is fantastic, but unfortunately only runs under Linux. I've heard of Purity, Electric Fence, and dmalloc(), but never tried any of them.
    AFAIK, valgrind is a profiler, CMIIW. I've used it before to check for a bottleneck when I was developing an application for Linux last year.

    I've looked at Purity. It's commercial, right? Dunno if my boss would want to buy it. Is there any open source one?

    Quote Originally Posted by twomers View Post
    >> Right, maybe I'll have a look at the code. Thanks.
    For a program bug? Really? You sure that's the way to do it?
    Not really. But it's my only lead so far.
    ERROR: Brain not found. Please insert a new brain!

    “Do nothing which is of no use.” - Miyamoto Musashi.

  4. #19
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    Quote Originally Posted by g4j31a5 View Post
    AFAIK, valgrind is a profiler, CMIIW. I've used it before to check for a bottleneck when I was developing an application for Linux last year.
    Well, Valgrind is really an instruction framework that lets a program be executed in a sort of virtual machine, if you know what I mean. The most common use of this (that I can tell) is for memory error detection -- every malloc()/free() call and every variable access can be trapped and examined -- but I'm sure you can do other things with it as well.

    Believe me, Valgrind can detect memory leaks and very strange memory errors. That's all I use it for, and I probably use it several times a week.

    I've looked at Purity. It's commercial, right? Dunno if my boss would want to buy it. Is there any open source one?
    I believe you can download a trial or something. As Elysia said, though, you can just use Microsoft's built-in functions if you're using one of their compilers. http://www.codeproject.com/KB/applic...kdetector.aspx

    Other suggestions: http://www.thefreecountry.com/source...ebugging.shtml
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. ATL bug of CComPtr?
    By George2 in forum Windows Programming
    Replies: 6
    Last Post: 04-07-2008, 08:52 AM
  2. Dev-C++: Problems with Breakpoint Debugging
    By Thileepan_Bala in forum C Programming
    Replies: 1
    Last Post: 01-17-2008, 10:48 AM
  3. Debugging Dev C++
    By tuurb046 in forum Tech Board
    Replies: 10
    Last Post: 08-16-2007, 01:51 PM
  4. Debugging book recommendation
    By dagans in forum Projects and Job Recruitment
    Replies: 1
    Last Post: 09-13-2005, 08:35 PM
  5. Debugging leads to buggy code and longer hours?
    By no-one in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 01-28-2002, 11:14 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21