[lkml]   [2000]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linu (Ingo Molnar)  wrote on 05.09.00 in <>:

    > On Tue, 5 Sep 2000, Andi Kleen wrote:
    > > I don't really believe that. It is as easy to add a silly NULL pointer
    > > check based on a oops as it is after a debugging session (and it is
    > > even likely you chose the simple fix because it is harder and more
    > > work to proceed) Usually with the debugger it is at least easier to
    > > collect the data needed for a real fix. [...]
    > this is the conceptual difference David tried to show, and which view i
    > support as well. There are two basic types of 'debugging behaviors':
    > A) 'Collect enough data to understand the local context and fix the bug.'
    > B) 'See the point of the immediate crash, think about that code, think
    > about code that called this code, think about the intent and
    > implementation of that code and find the bug based on
    > understanding the code.'

    In other words, with (A) cou can see the differende between your
    understanding and reality, and with (B) you can't.

    > A) results in people being able to debug easy and moderate kernel bugs.
    > The same people are lost if faced with bugs that are not apparent in the
    > 'state of the system around the bug' represented by the debugger.
    > B) results in people with the ability to identify bugs based on the source
    > code - and the ability to fix the really mindblowing tough bugs. We had
    > about 10 such bugs during the cycle of the 2.3 kernel.

    I think this is complete and utter nonsense.

    Just about *all* the tough bugs I've ever fixed took about 100 times more
    time to fix if I couldn't look at the actual system state.

    *Easy* bugs don't *need* a debugger. One look at the error message, one
    slap at the head, correct the mistake.

    The problem with most tough bugs is that what actually happens is *not*
    what you think is happening. That's what makes them tough. That's also
    what makes trying to find them by reading the source such an excercise in

    One bug I particularly remember (this was in a Pascal program) was a range
    check at a point where, looking at the source, a range check "could not
    happen". I spent a long time looking at the source with exactly zero
    effect. And nobody knew how to reproduce the bug.

    Then I managed to get my hands on a core dump. Located the place in
    question. Looked at the buffer. Clearly saw it being overwritten by some
    completely unrelated text.

    And from the contents of that text, it was pretty obvious where to look
    for the original bug, and it wasn't all that hard to find. And to
    reproduce, once I knew what went wrong.

    Without the core dump (or alternatively a debugger) I wouldn't even have
    known to look for text, since the part which bombed wasn't handling any

    A classical memory corruption bug, and like most late-effect bugs hell to
    find without some sort of support for poking around in the actual program

    > I do claim that the real mainsteam-kernel development 'bottleneck' is the
    > ability to fix the tough bugs. It's always these tough bugs that keep up
    > the addition of new features in devel kernels. We should thus do
    > everything to teach people the proper debugging methodology.

    And the proper methodology for tough bugs is named "debugger". Or core
    dumps, or any other way to get at the actual system state.

    It's most definitely *not* printk. That's "fooling around".

    MfG Kai
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.025 / U:4.780 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site