Segfault only with optimization

Discussion in 'C Programming' started by Jeff Taylor, Mar 17, 2008.

  1. Jeff Taylor

    Jeff Taylor Guest

    I have a C program that GCC compiles without warnings and it runs just
    fine. However, when I compile it using any of the -O options (-O0, -O1,
    etc.) it segfaults when executed (still no compiler warnings or errors).

    I know nothing about compiler otimization, other than it makes my program
    run faster. Any suggestions on how to debug this, or what to look for
    would be greatly appreciated.

    Thank you.
     
    Jeff Taylor, Mar 17, 2008
    #1
    1. Advertising

  2. In article <Xns9A6484D691516Jefflokiresearchcom@199.45.49.11>,
    Jeff Taylor <> wrote:

    >I have a C program that GCC compiles without warnings and it runs just
    >fine. However, when I compile it using any of the -O options (-O0, -O1,
    >etc.) it segfaults when executed (still no compiler warnings or errors).


    This seems rather surprising, since -O0 is documented to be the default.

    Apart from that, the usual reason or optimisation resulting in a crash
    is that your program has a bug, but one that does not show up without
    optimisation. (Of course, it could conceivably be a bug in the
    compiler.)

    I suggest you run your program under a debugger (probably gdb), and
    see just what is causing the segmentation fault.

    -- Richard
    --
    :wq
     
    Richard Tobin, Mar 17, 2008
    #2
    1. Advertising

  3. On Mar 17, 1:20 pm, (Richard Tobin) wrote:
    > In article <Xns9A6484D691516Jefflokiresearch...@199.45.49.11>,
    > Jeff Taylor <> wrote:
    >
    > >I have a C program that GCC compiles without warnings and it runs just
    > >fine. However, when I compile it using any of the -O options (-O0, -O1,
    > >etc.) it segfaults when executed (still no compiler warnings or errors).

    >
    > This seems rather surprising, since -O0 is documented to be the default.
    >
    > Apart from that, the usual reason or optimisation resulting in a crash
    > is that your program has a bug, but one that does not show up without
    > optimisation. (Of course, it could conceivably be a bug in the
    > compiler.)
    >
    > I suggest you run your program under a debugger (probably gdb), and
    > see just what is causing the segmentation fault.
    >
    > -- Richard
    > --
    > :wq


    If you have such available, or can install them, tools that detect
    memory corruption are often very good for helping diagnose this kind
    of thing. I'm partial to Valgrind these days, which is free, and used
    to use Rational Purify a lot, which is not free. Which tools, if any,
    are available depends on your particular system.

    If you want much direct help from comp.lang.c, a good approach is to
    try to reduce your problem to a smallish amount of code that
    demonstrates the issue. That exercise may well help you figure it out
    anyway :)

    -David
     
    David Resnick, Mar 17, 2008
    #3
  4. Jeff Taylor

    user923005 Guest

    On Mar 17, 10:04 am, Jeff Taylor <> wrote:
    > I have a C program that GCC compiles without warnings and it runs just
    > fine.  However, when I compile it using any of the -O options (-O0, -O1,
    > etc.) it segfaults when executed (still no compiler warnings or errors).  
    >
    > I know nothing about compiler otimization, other than it makes my program
    > run faster.  Any suggestions on how to debug this, or what to look for
    > would be greatly appreciated.


    What are the compile switches that you use?
    Crank the warnings up to the maximum level.
    Feed the code to splint:
    http://www.splint.org/
     
    user923005, Mar 17, 2008
    #4
  5. Jeff Taylor

    jacob navia Guest

    Jeff Taylor wrote:
    > I have a C program that GCC compiles without warnings and it runs just
    > fine. However, when I compile it using any of the -O options (-O0, -O1,
    > etc.) it segfaults when executed (still no compiler warnings or errors).
    >


    There are several approaches to this problem

    1) The approach I usually take:
    1.a Include the debug information when compiling (usually with -g)
    1.b Do not strip the executable
    1.c Start the gdb debugger and run your program within the debugger.
    1.d When it crashes, take note of where it crashes. The specific
    gdb command is "backtrace" as far as I remember.
    1.e Look at the local variables. Note that the values displayed
    by gdb are probably wrong since optimizations and debugging
    do not mix well.
    1.f Recompile the module where the crash happens WITHOUT
    any optimizations
    1.g Relink
    1.h Rerun. Does the program crash? If no, you have found the
    module where the fault is. Go to step 1.j
    If yes, the fault is still there. Take another module from
    the modules in the backtrace and recompile. Go to step 1.g.
    1.i If you have recompiled all the modules in the backtrace and
    the crash still persists, recompile one by one all other
    modules until the crash disappears. The last module that
    you recompiled is the module with the fault.
    1.j Isolate the fault within the module. This can be tricky
    unless there is a way to tell the compiler to enable/disable
    optimizations in a function by function basis.

    2) The approach recommended by the regulars in this group:
    Read the source code. If you read hard enough the bug will be
    obvious to you.

    > I know nothing about compiler otimization, other than it makes my program
    > run faster. Any suggestions on how to debug this, or what to look for
    > would be greatly appreciated.
    >


    There is no free lunch. Optimized programs are more sensible to
    programming errors than no optimized ones. Besides, you expose
    yourself to the bugs of the optimizer, that are many.

    If you are doing straight C though, it is highly unlikely that
    there is a bug in the optimizer...


    > Thank you.



    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Mar 17, 2008
    #5
  6. Jeff Taylor

    Willem Guest

    Jeff wrote:
    ) I have a C program that GCC compiles without warnings and it runs just
    ) fine. However, when I compile it using any of the -O options (-O0, -O1,
    ) etc.) it segfaults when executed (still no compiler warnings or errors).
    )
    ) I know nothing about compiler otimization, other than it makes my program
    ) run faster. Any suggestions on how to debug this, or what to look for
    ) would be greatly appreciated.

    Optimization often reorders automatic variables, sometimes putting them
    in registers instead of on the stack, sometimes putting several into the
    same piece of memory if their lifetimes don't coincide. So a buffer
    overflow or something similar would be one thing to look for.


    SaSW, Willem
    --
    Disclaimer: I am in no way responsible for any of the statements
    made in the above text. For all I know I might be
    drugged or something..
    No I'm not paranoid. You all think I'm paranoid, don't you !
    #EOT
     
    Willem, Mar 17, 2008
    #6
  7. Jeff Taylor <> wrote:
    > I have a C program that GCC compiles without warnings and
    > it runs just fine.


    Realise that output is not the only measure of correctness.

    > However, when I compile it using any of the -O options
    > (-O0, -O1, etc.) it segfaults when executed (still no
    > compiler warnings or errors).  


    I'm afraid you are responsible for diagnosing errors in your
    code, not your compiler.

    > I know nothing about compiler otimization, other than
    > it makes my program run faster.


    It should not do so at the cost of changing the semantics,
    unless your code relies on undefined or unspecified
    behaviour.

    > Any suggestions on how to debug this, or what to look for
    > would be greatly appreciated.


    Strip the program down to the smallest compilable version
    that exhibits the problem. This is not only useful for
    posting to usenet for analysis, it is a very useful debugging
    technique in its own right.

    If debugging was as simple as 'if I get a segfault what are
    the 6 things I need to check', then no one would ever need
    forums because programming would be a doddle! ;)

    --
    Peter
     
    Peter Nilsson, Mar 17, 2008
    #7
  8. Jeff Taylor

    jacob navia Guest

    Peter Nilsson wrote:
    > Jeff Taylor <> wrote:
    >> I have a C program that GCC compiles without warnings and
    >> it runs just fine.

    >
    > Realise that output is not the only measure of correctness.
    >


    Interesting interesting...

    Can you name any other measure that doesn't rely on
    output?

    Using a psychic medium is not allowed.


    >> However, when I compile it using any of the -O options
    >> (-O0, -O1, etc.) it segfaults when executed (still no
    >> compiler warnings or errors).

    >
    > I'm afraid you are responsible for diagnosing errors in your
    > code, not your compiler.
    >



    Deep thought.

    >> I know nothing about compiler otimization, other than
    >> it makes my program run faster.

    >
    > It should not do so at the cost of changing the semantics,
    > unless your code relies on undefined or unspecified
    > behaviour.
    >


    Or unless the optimizer has a bug. It wouldn't be the first bug in gcc
    and I would bet that it will not be the last one. Somehow you
    fail to consider that possibility.

    >> Any suggestions on how to debug this, or what to look for
    >> would be greatly appreciated.

    >
    > Strip the program down to the smallest compilable version
    > that exhibits the problem. This is not only useful for
    > posting to usenet for analysis, it is a very useful debugging
    > technique in its own right.
    >
    > If debugging was as simple as 'if I get a segfault what are
    > the 6 things I need to check', then no one would ever need
    > forums because programming would be a doddle! ;)
    >


    With all respect Peter, this is not really helpful to the OP.
    I tried to give a list of steps to follow (see my post).
    Obviously that is one debugging strategy. You have (maybe) another.

    It would be helpful for the OP if you tried to help him a bit you see?


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Mar 17, 2008
    #8
  9. Jeff Taylor

    santosh Guest

    jacob navia wrote:

    > Peter Nilsson wrote:
    >> Jeff Taylor <> wrote:
    >>> I have a C program that GCC compiles without warnings and
    >>> it runs just fine.

    >>
    >> Realise that output is not the only measure of correctness.
    >>

    >
    > Interesting interesting...
    >
    > Can you name any other measure that doesn't rely on
    > output?


    A program that invokes a buffer overrun, but happens to produce expected
    output is surely not correct?


    > Using a psychic medium is not allowed.
    >
    >
    >>> However, when I compile it using any of the -O options
    >>> (-O0, -O1, etc.) it segfaults when executed (still no
    >>> compiler warnings or errors).

    >>
    >> I'm afraid you are responsible for diagnosing errors in your
    >> code, not your compiler.
    >>

    > Deep thought.


    He means semantic errors. Or does your compiler do the programming for
    the programmer? :)

    <snip>
     
    santosh, Mar 17, 2008
    #9
  10. Jeff Taylor

    jacob navia Guest

    santosh wrote:
    > jacob navia wrote:
    >
    >> Peter Nilsson wrote:
    >>> Jeff Taylor <> wrote:
    >>>> I have a C program that GCC compiles without warnings and
    >>>> it runs just fine.
    >>> Realise that output is not the only measure of correctness.
    >>>

    >> Interesting interesting...
    >>
    >> Can you name any other measure that doesn't rely on
    >> output?

    >
    > A program that invokes a buffer overrun, but happens to produce expected
    > output is surely not correct?
    >


    How the hell do you know that there is a buffer
    overrun if the output is not affected?

    To KNOW that there is a buffer overrun the program MUST
    do something it should not do, i.e. produce an output
    that is different than the expected output

    If the output of the program is normal you have NO WAY
    to know there is a buffer overrun.

    And if you hook a debugger and see some buffer being
    overrun that *is* output of course.

    >
    >> Using a psychic medium is not allowed.
    >>
    >>
    >>>> However, when I compile it using any of the -O options
    >>>> (-O0, -O1, etc.) it segfaults when executed (still no
    >>>> compiler warnings or errors).
    >>> I'm afraid you are responsible for diagnosing errors in your
    >>> code, not your compiler.
    >>>

    >> Deep thought.

    >
    > He means semantic errors. Or does your compiler do the programming for
    > the programmer? :)
    >
    > <snip>
    >


    What I mean is that such sentences are not helpful to the OP.
    And we should try to be less patronizing with newcomers and
    people that ask questions. I am sure the OP knows that it is the
    programmer that debugs the program. He was asking us to help him
    to do that, not to answer him

    just do it pal...


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Mar 17, 2008
    #10
  11. Jeff Taylor

    santosh Guest

    jacob navia wrote:

    > santosh wrote:
    >> jacob navia wrote:
    >>
    >>> Peter Nilsson wrote:
    >>>> Jeff Taylor <> wrote:
    >>>>> I have a C program that GCC compiles without warnings and
    >>>>> it runs just fine.
    >>>> Realise that output is not the only measure of correctness.
    >>>>
    >>> Interesting interesting...
    >>>
    >>> Can you name any other measure that doesn't rely on
    >>> output?

    >>
    >> A program that invokes a buffer overrun, but happens to produce
    >> expected output is surely not correct?
    >>

    >
    > How the hell do you know that there is a buffer
    > overrun if the output is not affected?
    >
    > To KNOW that there is a buffer overrun the program MUST
    > do something it should not do, i.e. produce an output
    > that is different than the expected output
    >
    > If the output of the program is normal you have NO WAY
    > to know there is a buffer overrun.


    Not if you use a memory bounds checker. You can also "know" that there
    is a buffer overrun by just looking at the source.

    > And if you hook a debugger and see some buffer being
    > overrun that *is* output of course.


    No. The output of the debugger is not the output of the program being
    debugged.

    <snip>
     
    santosh, Mar 17, 2008
    #11
  12. Jeff Taylor

    Ben Pfaff Guest

    jacob navia <> writes:

    > How the hell do you know that there is a buffer
    > overrun if the output is not affected?


    By inspecting the source code.
    --
    Ben Pfaff
    http://benpfaff.org
     
    Ben Pfaff, Mar 17, 2008
    #12
  13. Jeff Taylor

    Flash Gordon Guest

    jacob navia wrote, On 17/03/08 21:45:
    > santosh wrote:
    >> jacob navia wrote:
    >>
    >>> Peter Nilsson wrote:
    >>>> Jeff Taylor <> wrote:
    >>>>> I have a C program that GCC compiles without warnings and
    >>>>> it runs just fine.
    >>>> Realise that output is not the only measure of correctness.
    >>>>
    >>> Interesting interesting...
    >>>
    >>> Can you name any other measure that doesn't rely on
    >>> output?

    >>
    >> A program that invokes a buffer overrun, but happens to produce expected
    >> output is surely not correct?

    >
    > How the hell do you know that there is a buffer
    > overrun if the output is not affected?
    >
    > To KNOW that there is a buffer overrun the program MUST
    > do something it should not do, i.e. produce an output
    > that is different than the expected output
    >
    > If the output of the program is normal you have NO WAY
    > to know there is a buffer overrun.


    You obviously do not understand what static analysis is. Or what reviews
    are for that matter! Just to explain...

    Static analysis is when you analyse the code *without* running it.
    Various methods of static analysis are used on safety critical software
    (in my previous job we were going to contract out the static analysis of
    the code to a third party, I know this because I was going out with one
    of out SW QA engineers visiting the companies to evaluate them). Since
    in static analysis you do not run the code you cannot sensibly consider
    the report produced (which should certainly include identifying buffer
    overflows) as an output of the program any more than you can consider
    1.1415926536 to be the output of a text file containing only the
    character "2" in it (it is the output of the program that runs on the file).

    > And if you hook a debugger and see some buffer being
    > overrun that *is* output of course.


    I suppose you will consider the report by an independent company that
    never runs the program to be output of the program as well. Also I
    suppose the minutes of the design review (held before a line of code is
    written) is an output of the program, and yes bugs *are* found in
    design reviews if they are held properly.

    >>> Using a psychic medium is not allowed.
    >>>
    >>>>> However, when I compile it using any of the -O options
    >>>>> (-O0, -O1, etc.) it segfaults when executed (still no
    >>>>> compiler warnings or errors).
    >>>> I'm afraid you are responsible for diagnosing errors in your
    >>>> code, not your compiler.
    >>>>
    >>> Deep thought.

    >>
    >> He means semantic errors. Or does your compiler do the programming for
    >> the programmer? :)
    >>
    >> <snip>

    >
    > What I mean is that such sentences are not helpful to the OP.
    > And we should try to be less patronizing with newcomers and
    > people that ask questions. I am sure the OP knows that it is the
    > programmer that debugs the program. He was asking us to help him
    > to do that, not to answer him
    >
    > just do it pal...


    The implication of what the OP posted was that he found it surprising
    that he would get a segfault on code that did not produce a warning,
    this is a common mistake. So pointing out that the compiler is not
    responsible for finding the errors is not unhelpful.

    Personally I would start by turning up the warnings on the compiler and
    fixing the issues that throws up (as someone else suggested) and then
    try running it through valgrind (as someone else suggested).
    --
    Flash Gordon
     
    Flash Gordon, Mar 17, 2008
    #13
  14. Jeff Taylor

    jacob navia Guest

    Flash Gordon wrote:
    > Static analysis is when you analyse the code *without* running it.
    > Various methods of static analysis are used on safety critical software
    > (in my previous job we were going to contract out the static analysis of
    > the code to a third party, I know this because I was going out with one
    > of out SW QA engineers visiting the companies to evaluate them). Since
    > in static analysis you do not run the code you cannot sensibly consider
    > the report produced (which should certainly include identifying buffer
    > overflows) as an output of the program any more than you can consider
    > 1.1415926536 to be the output of a text file containing only the
    > character "2" in it (it is the output of the program that runs on the
    > file).
    >


    Static analysis never goes beyond the most trivial
    bugs. The problem is that in medium to big sized
    programs, the number of possible paths grows
    exponentially. That is why static analyzers limit
    themselves and prune the tree of possibilities
    and because of that they can't see most of the difficult
    bugs.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Mar 17, 2008
    #14
  15. Jeff Taylor

    santosh Guest

    jacob navia wrote:

    > Flash Gordon wrote:
    >> Static analysis is when you analyse the code *without* running it.
    >> Various methods of static analysis are used on safety critical
    >> software (in my previous job we were going to contract out the static
    >> analysis of the code to a third party, I know this because I was
    >> going out with one of out SW QA engineers visiting the companies to
    >> evaluate them). Since in static analysis you do not run the code you
    >> cannot sensibly consider the report produced (which should certainly
    >> include identifying buffer overflows) as an output of the program any
    >> more than you can consider 1.1415926536 to be the output of a text
    >> file containing only the character "2" in it (it is the output of the
    >> program that runs on the file).
    >>

    >
    > Static analysis never goes beyond the most trivial
    > bugs. The problem is that in medium to big sized
    > programs, the number of possible paths grows
    > exponentially.


    This is where good design helps. Also in well written code, each module
    is functionally independent from other modules and static checking need
    only consider the program on a module by module basis.

    > That is why static analyzers limit
    > themselves and prune the tree of possibilities
    > and because of that they can't see most of the difficult
    > bugs.


    Perhaps. But your statement that bugs can only be found from the output
    of a program is simply erroneous.
     
    santosh, Mar 17, 2008
    #15
  16. Jeff Taylor

    user923005 Guest

    On Mar 17, 4:22 pm, santosh <> wrote:
    > jacob navia wrote:
    > > Flash Gordon wrote:
    > >> Static analysis is when you analyse the code *without* running it.
    > >> Various methods of static analysis are used on safety critical
    > >> software (in my previous job we were going to contract out the static
    > >> analysis of the code to a third party, I know this because I was
    > >> going out with one of out SW QA engineers visiting the companies to
    > >> evaluate them). Since in static analysis you do not run the code you
    > >> cannot sensibly consider the report produced (which should certainly
    > >> include identifying buffer overflows) as an output of the program any
    > >> more than you can consider 1.1415926536 to be the output of a text
    > >> file containing only the character "2" in it (it is the output of the
    > >> program that runs on the file).

    >
    > > Static analysis never goes beyond the most trivial
    > > bugs. The problem is that in medium to big sized
    > > programs, the number of possible paths grows
    > > exponentially.

    >
    > This is where good design helps. Also in well written code, each module
    > is functionally independent from other modules and static checking need
    > only consider the program on a module by module basis.
    >
    > > That is why static analyzers limit
    > > themselves and prune the tree of possibilities
    > > and because of that they can't see most of the difficult
    > > bugs.

    >
    > Perhaps. But your statement that bugs can only be found from the output
    > of a program is simply erroneous.


    Even some classes of memory overwrite errors can be detected
    statically:

    C:\tmp>lin bug.c

    C:\tmp>"C:\Lint\Lint-nt" +v -i"C:\Lint" std.lnt -os(_LINT.TMP)
    bug.c
    PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software
    1985-2006

    --- Module: bug.c (C)

    C:\tmp>type _LINT.TMP | more

    --- Module: bug.c (C)
    _
    strcpy(test, p);
    bug.c(9) : Warning 419: Apparent data overrun for function
    'strcpy(char *,
    const char *)', argument 2 (size=25) exceeds argument 1 (size=12)
    [Reference: file bug.c: lines 8, 9]
    bug.c(8) : Info 831: Reference cited in prior message
    bug.c(9) : Info 831: Reference cited in prior message
    _
    }
    bug.c(11) : Note 953: Variable 'p' (line 8) could be declared as const
    --- Eff.
    C++ 3rd Ed. item 3
    bug.c(8) : Info 830: Location cited in prior message

    --- Wrap-up for Module: bug.c

    Info 766: Header file 'C:\Program Files\Microsoft Visual Studio
    8\VC\INCLUDE\stdio.h' not used in module 'bug.c'

    ---
    output placed in _LINT.TMP

    C:\tmp>type bug.c
    #include <string.h>
    #include <stdlib.h>
    #include <stdio.h>

    int main(void)
    {
    char test[12];
    const char *p = "This string is too long.";
    strcpy(test, p);
    return 0;
    }
     
    user923005, Mar 18, 2008
    #16
  17. On 17 Mar, 21:40, santosh <> wrote:
    > jacob navia wrote:
    > > Peter Nilsson wrote:

    >
    > >> Realise that output is not the only measure of correctness.


    > > Can you name any other measure that doesn't rely on
    > > output?

    >
    > A program that invokes a buffer overrun, but happens to produce expected
    > output is surely not correct?


    What is the definition of "correct"? A computer program
    is simply a machine for computing some function on a set
    of strings from some alphabet. If the output is as expected
    for all possible inputs, then the program accurately models
    the function, and is thus correct. However, if it contains
    a programming error, it is very likely that it does not
    produce correct output on all possible inputs, but it
    is generally not feasible to check all possible inputs.
    So, Jacob is right in the sense that the output is the
    only thing that matters in an academic sense of determining
    the correctness of the program, and Santosh is right in
    the practical sense that a program that contains a buffer
    overflow will probably generate incorrect output on some
    input string. Can't we all just get along? :)
     
    William Pursell, Mar 18, 2008
    #17
  18. jacob navia said:

    <snip>

    > Static analysis never goes beyond the most trivial
    > bugs.


    Perhaps it is because you believe this that you need a debugger for every
    single bug. Not everyone is so hampered.

    On a number of occasions I have (correctly) debugged code that I haven't
    even seen, let alone run through a debugger. Okay, yes, those are
    generally the most trivial bugs - but with unseen source it doesn't even
    count as static analysis, IMHO.

    On at least two occasions that I can recall, my static analysis of a system
    (by which I mean looking at it, not linting it) was sufficient for me to
    deduce that the system needed to be rewritten entirely. (These were
    production systems, one of which was just a single program, but the other
    was a combination of overnight batch and ad hoc lookup.) In each case, I
    went to the system's "owner" and explained my point; in each case, the
    rewrite was approved (i.e. the system owner agreed with my static analysis
    to the point where he or she was prepared to fund the rewrite).

    A bug that requires a rewrite is not a trivial bug.

    Successful static analysis, however, is not for everyone. It requires an
    eye for detail that some people do not have and cannot imagine. It
    requires a level of pedantry that some people find offensive rather than
    useful. It requires a depth of imagination ("I wonder what would happen
    if...?") that some people see as irrelevant to programming. And it
    requires a humility that can acknowledge the possibility that long-held
    and cherished habits and beliefs might be erroneous. Those without the
    necessary qualities must either acquire them or doom themselves to wearing
    out their F5s and F9s.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Mar 18, 2008
    #18
  19. Jeff Taylor

    Ben Pfaff Guest

    Richard Heathfield <> writes:
    > jacob navia said:
    >> Static analysis never goes beyond the most trivial
    >> bugs.

    >
    > Perhaps it is because you believe this that you need a debugger for every
    > single bug. Not everyone is so hampered.


    On multiple occasions I've been able to tell students in a course
    (that I was teaching or assisting in teaching) exactly what bug
    they had introduced in their operating system kernel just by
    looking at a backtrace produced with the failure message or, in
    some cases, simply from a description of the symptoms. In one
    case the diagnosis became so mechanical that I modified the
    system regression tests to discover and report the cause of the
    problem.

    The operating system kernel in question is over 13,000 lines of C
    code. Students in the course add about 5,000 lines of their own
    code to it. Not what I'd consider a large program, or even
    medium size, but well above the 2,000 lines that Jacob says a
    person can debug without a debugger. I developed the kernel, and
    the reference solutions, without using a debugger.
    --
    "C has its problems, but a language designed from scratch would have some too,
    and we know C's problems."
    --Bjarne Stroustrup
     
    Ben Pfaff, Mar 18, 2008
    #19
  20. Jeff Taylor

    user923005 Guest

    On Mar 17, 10:43 pm, Ben Pfaff <> wrote:
    > Richard Heathfield <> writes:
    > > jacob navia said:
    > >> Static analysis never goes beyond the most trivial
    > >> bugs.

    >
    > > Perhaps it is because you believe this that you need a debugger for every
    > > single bug. Not everyone is so hampered.

    >
    > On multiple occasions I've been able to tell students in a course
    > (that I was teaching or assisting in teaching) exactly what bug
    > they had introduced in their operating system kernel just by
    > looking at a backtrace produced with the failure message or, in
    > some cases, simply from a description of the symptoms.  In one
    > case the diagnosis became so mechanical that I modified the
    > system regression tests to discover and report the cause of the
    > problem.
    >
    > The operating system kernel in question is over 13,000 lines of C
    > code.  Students in the course add about 5,000 lines of their own
    > code to it.  Not what I'd consider a large program, or even
    > medium size, but well above the 2,000 lines that Jacob says a
    > person can debug without a debugger.  I developed the kernel, and
    > the reference solutions, without using a debugger.


    There is a guy where I work who has 500K lines of code in his head
    perfectly (right down to the line number).
    Of course, I've never seen anyone else like him.
     
    user923005, Mar 18, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Harald Deischinger
    Replies:
    1
    Views:
    314
    Victor Bazarov
    Dec 15, 2003
  2. Vedran Vyroubal

    STL string segfault

    Vedran Vyroubal, Mar 3, 2004, in forum: C++
    Replies:
    5
    Views:
    1,381
    Vedran Vyroubal
    Mar 4, 2004
  3. Arthur J. O'Dwyer

    multiset segfault

    Arthur J. O'Dwyer, Jun 17, 2004, in forum: C++
    Replies:
    10
    Views:
    752
    Dave Townsend
    Jun 18, 2004
  4. Ravikiran

    Zero Optimization and Sign Optimization???

    Ravikiran, Nov 17, 2008, in forum: C Programming
    Replies:
    22
    Views:
    900
    Thad Smith
    Nov 24, 2008
  5. Andrey Vul
    Replies:
    8
    Views:
    709
    Richard Bos
    Jul 30, 2010
Loading...

Share This Page