Re: More on debuggers

Discussion in 'C Programming' started by BartC, Dec 1, 2010.

  1. BartC

    BartC Guest

    "Richard" <> wrote in message
    news:id3ll8$c7a$-september.org...
    >
    > Despite the luminaries here telling us that debuggers are useless and
    > that its twice as hard to debug a program as is it is write code
    > properly the first time, I thought some of you might enjoy this
    >
    > http://video.google.com/videoplay?docid=3897010229726822034#
    >
    > This Stanford lecturer agrees with me : debuggers help you track state
    > and force test conditions in a controlled manner. Obviously he's not as
    > smart as the people here who claim they prefer to read a print out .....


    Debuggers are not really my thing (I see debugging as more of a sport), but
    just two minutes of that guy with the funny hat has put me off for life.

    --
    bartc
     
    BartC, Dec 1, 2010
    #1
    1. Advertising

  2. On Dec 1, 4:43 pm, Richard <> wrote:
    > "BartC" <> writes:
    >
    > > Debuggers are not really my thing (I see debugging as more of a sport), but
    > > just two minutes of that guy with the funny hat has put me off for
    > > life.

    >
    > So you're not a programmer? You dont maintain code? That or you dont
    > know what a debugger is and what it can do.
    >

    I don't use debuggers either. I find I can always track down bugs with
    diagnostic printfs.

    The reason I don't use a debuggers is that I'm constantly switching
    between systems. The debugger becomes a very intimate part of the way
    you work, and then when suddenly deprived of it it's bit like
    switching from a car with a steering wheel and gearbox to one with a
    tiller and a double declutch - effectively you've got to relearn to
    drive.
     
    Malcolm McLean, Dec 12, 2010
    #2
    1. Advertising

  3. BartC

    BartC Guest

    "Malcolm McLean" <> wrote in message
    news:...
    > On Dec 1, 4:43 pm, Richard <> wrote:
    >> "BartC" <> writes:
    >>
    >> > Debuggers are not really my thing (I see debugging as more of a sport),
    >> > but
    >> > just two minutes of that guy with the funny hat has put me off for
    >> > life.

    >>
    >> So you're not a programmer? You dont maintain code? That or you dont
    >> know what a debugger is and what it can do.
    >>

    > I don't use debuggers either. I find I can always track down bugs with
    > diagnostic printfs.
    >
    > The reason I don't use a debuggers is that I'm constantly switching
    > between systems. The debugger becomes a very intimate part of the way
    > you work, and then when suddenly deprived of it it's bit like
    > switching from a car with a steering wheel and gearbox to one with a
    > tiller and a double declutch - effectively you've got to relearn to
    > drive.


    I knew someone who had a plane, a couple of boats, and several cars, with a
    combination of LHD/RHD, manual and automatic, and had one home where they
    drove on the left, and another where they drove on the right.

    He never had the slightest trouble adapting.

    --
    Bartc
     
    BartC, Dec 12, 2010
    #3
  4. BartC

    Ike Naar Guest

    On 2010-12-12, BartC <> wrote:
    > I knew someone who had a plane, a couple of boats, and several cars, with a
    > combination of LHD/RHD, manual and automatic, and had one home where they
    > drove on the left, and another where they drove on the right.
    >
    > He never had the slightest trouble adapting.


    Did he use a debugger?
     
    Ike Naar, Dec 12, 2010
    #4
  5. BartC

    Chris H Guest

    In message <
    s.com>, Malcolm McLean <> writes
    >On Dec 1, 4:43 pm, Richard <> wrote:
    >> "BartC" <> writes:
    >>
    >> > Debuggers are not really my thing (I see debugging as more of a sport), but
    >> > just two minutes of that guy with the funny hat has put me off for
    >> > life.

    >>
    >> So you're not a programmer? You dont maintain code? That or you dont
    >> know what a debugger is and what it can do.
    >>

    >I don't use debuggers either. I find I can always track down bugs with
    >diagnostic printfs.


    There speaks an amateur

    >The reason I don't use a debuggers is that I'm constantly switching
    >between systems.


    So?

    >The debugger becomes a very intimate part of the way
    >you work, and then when suddenly deprived of it it's bit like
    >switching from a car with a steering wheel and gearbox to one with a
    >tiller and a double declutch - effectively you've got to relearn to
    >drive.


    Yes.
    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Dec 12, 2010
    #5
  6. BartC

    BartC Guest

    "Ike Naar" <> wrote in message
    news:...
    > On 2010-12-12, BartC <> wrote:
    >> I knew someone who had a plane, a couple of boats, and several cars, with
    >> a
    >> combination of LHD/RHD, manual and automatic, and had one home where they
    >> drove on the left, and another where they drove on the right.
    >>
    >> He never had the slightest trouble adapting.

    >
    > Did he use a debugger?


    No.
     
    BartC, Dec 12, 2010
    #6
  7. On Dec 12, 12:34 pm, Malcolm McLean <>
    wrote:
    > On Dec 1, 4:43 pm, Richard <> wrote:> "BartC" <> writes:
    >
    > > > Debuggers are not really my thing (I see debugging as more of a sport), but
    > > > just two minutes of that guy with the funny hat has put me off for
    > > > life.

    >
    > > So you're not a programmer? You dont maintain code? That or you dont
    > > know what a debugger is and what it can do.

    >
    > I don't use debuggers either. I find I can always track down bugs with
    > diagnostic printfs.
    >
    > The reason I don't use a debuggers is that I'm constantly switching
    > between systems. The debugger becomes a very intimate part of the way
    > you work, and then when suddenly deprived of it it's bit like
    > switching from a car with a steering wheel and gearbox to one with a
    > tiller and a double declutch - effectively you've got to relearn to
    > drive.


    I've switched between gdb (both gui and cli) and ms studio without
    much difficulty.
     
    Nick Keighley, Dec 12, 2010
    #7
  8. Couldn't we all just agree that debuggers are sometimes the
    best debugging tool, sometimes inappropriate, and the boundary
    between the two cases varies due to various factors, including a
    particular programmer's skill set?

    I seldom use debuggers, but definitely set a lot of breakpoints
    with them when I was understanding and busting copy-protect
    schemes for money^H^H^H^H^H as an avocation.

    On Dec 12, 8:05 pm, "BartC" <> wrote:
    > I knew someone who ... had one home where they
    > drove on the left, and another where they drove on the right.


    My big problem driving in London for the first time was
    that I always hold my cigarette in right hand, but ashtray
    was on the left.

    I quit smoking.

    James Dow Allen
     
    James Dow Allen, Dec 12, 2010
    #8
  9. On Dec 12, 1:26 pm, Chris H <> wrote:
    > In message <
    > s.com>, Malcolm McLean <> writes
    >
    > >On Dec 1, 4:43 pm, Richard <> wrote:
    > >> "BartC" <> writes:

    >
    > >> > Debuggers are not really my thing (I see debugging as more of a sport), but
    > >> > just two minutes of that guy with the funny hat has put me off for
    > >> > life.

    >
    > >> So you're not a programmer? You dont maintain code? That or you dont
    > >> know what a debugger is and what it can do.

    >
    > >I don't use debuggers either. I find I can always track down bugs with
    > >diagnostic printfs.

    >
    > There speaks an amateur


    struct Whatsit
    {
    int k;
    };

    struct SubT
    {
    Whatsit w;
    };

    struct Thing
    {
    SubT p1;
    SubT p2;
    };

    ....

    Thing t[100];
    t[0] = initial;

    for (i = 1; i < 100; i++)
    {
    t = f (t[i - 1]);
    }

    I believe something is going wrong and I'd like to see all the k
    values. This seems to mean a certain amount buggering about in the
    debugger. Whilst a one line printf() seems easy...

    > >The reason I don't use a debuggers is that I'm constantly switching
    > >between systems.

    >
    > So?
    >
    > >The debugger becomes a very intimate part of the way
    > >you work, and then when suddenly deprived of it it's bit like
    > >switching from a car with a steering wheel and gearbox to one with a
    > >tiller and a double declutch - effectively you've got to relearn to
    > >drive.

    >
    > Yes.
     
    Nick Keighley, Dec 12, 2010
    #9
  10. On Dec 12, 3:26 pm, Chris H <> wrote:
    > In message <
    >
    > >I don't use debuggers either. I find I can always track down bugs with
    > >diagnostic printfs.

    >
    > There speaks an amateur
    >

    No, a professional programmer who has often worked on systems where no
    debugger is available.

    I've never had a case of a known bug which couldn't be tracked down by
    diagnostic alterations to the source code, but which was solved by use
    of a debugger. I've had the reverse.
     
    Malcolm McLean, Dec 13, 2010
    #10
  11. BartC

    Ian Collins Guest

    On 12/13/10 09:32 PM, Malcolm McLean wrote:
    > On Dec 12, 3:26 pm, Chris H<> wrote:
    >> In message<
    >>
    >>> I don't use debuggers either. I find I can always track down bugs with
    >>> diagnostic printfs.

    >>
    >> There speaks an amateur
    >>

    > No, a professional programmer who has often worked on systems where no
    > debugger is available.
    >
    > I've never had a case of a known bug which couldn't be tracked down by
    > diagnostic alterations to the source code, but which was solved by use
    > of a debugger. I've had the reverse.


    I've yet to find a way to make diagnostic alterations to the source code
    when analysing core files!

    --
    Ian Collins
     
    Ian Collins, Dec 13, 2010
    #11
  12. BartC

    Chris H Guest

    In message <
    s.com>, Malcolm McLean <> writes
    >On Dec 12, 3:26 pm, Chris H <> wrote:
    >> In message <
    >>
    >> >I don't use debuggers either. I find I can always track down bugs with
    >> >diagnostic printfs.

    >>
    >> There speaks an amateur
    >>

    >No, a professional programmer who has often worked on systems where no
    >debugger is available.


    SO no logic analyser available then?

    >I've never had a case of a known bug which couldn't be tracked down by
    >diagnostic alterations to the source code, but which was solved by use
    >of a debugger. I've had the reverse.


    I have... many times.

    Of course many systems you have to ship the code that was tested.
    printf changes the memory map, path of execution and timing. IT is
    like opening the fridge door to se if the light is on.



    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Dec 13, 2010
    #12
  13. BartC

    Chris H Guest

    In message <>, Ian Collins <ian-
    > writes
    >On 12/13/10 09:32 PM, Malcolm McLean wrote:
    >> On Dec 12, 3:26 pm, Chris H<> wrote:
    >>> In message<
    >>>
    >>>> I don't use debuggers either. I find I can always track down bugs with
    >>>> diagnostic printfs.
    >>>
    >>> There speaks an amateur
    >>>

    >> No, a professional programmer who has often worked on systems where no
    >> debugger is available.
    >>
    >> I've never had a case of a known bug which couldn't be tracked down by
    >> diagnostic alterations to the source code, but which was solved by use
    >> of a debugger. I've had the reverse.

    >
    >I've yet to find a way to make diagnostic alterations to the source
    >code when analysing core files!


    Diagnostic code changes the memory map, the path of execution and
    timing. SO the code it is diagnosing is not the code you will be
    shipping.

    printf can not give accurate results anyway.
    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Dec 13, 2010
    #13
  14. BartC

    Ian Collins Guest

    On 12/13/10 09:46 PM, Chris H wrote:
    > In message<>, Ian Collins<ian-
    > > writes
    >> On 12/13/10 09:32 PM, Malcolm McLean wrote:
    >>> On Dec 12, 3:26 pm, Chris H<> wrote:
    >>>> In message<
    >>>>
    >>>>> I don't use debuggers either. I find I can always track down bugs with
    >>>>> diagnostic printfs.
    >>>>
    >>>> There speaks an amateur
    >>>>
    >>> No, a professional programmer who has often worked on systems where no
    >>> debugger is available.
    >>>
    >>> I've never had a case of a known bug which couldn't be tracked down by
    >>> diagnostic alterations to the source code, but which was solved by use
    >>> of a debugger. I've had the reverse.

    >>
    >> I've yet to find a way to make diagnostic alterations to the source
    >> code when analysing core files!

    >
    > Diagnostic code changes the memory map, the path of execution and
    > timing. SO the code it is diagnosing is not the code you will be
    > shipping.
    >
    > printf can not give accurate results anyway.


    Especially when dealing with my least favourite bugs - timing queerness
    in multi-threaded code and hardware/software timing hiccups.

    Actually the most time consuming bug I ever traced was in the closed
    source of an RTOS. That eventually required a logic analyser with a
    trace buffer, not pretty.

    --
    Ian Collins
     
    Ian Collins, Dec 13, 2010
    #14
  15. On Dec 13, 10:43 am, Chris H <> wrote:
    > In message <
    >
    > >No, a professional programmer who has often worked on systems where no
    > >debugger is available.

    >
    > SO no logic analyser available then?
    >

    No. I've never used a logic analyser. That's not to say that there
    might not be projects that require them or where they may be helpful.
    However it's never been a felt need in the places where I have worked.

    >
    > >I've never had a case of a known bug which couldn't be tracked down by
    > >diagnostic alterations to the source code, but which was solved by use
    > >of a debugger. I've had the reverse.

    >
    > I have... many times.
    >
    > Of course many systems you have to ship the code that was tested.
    > printf changes the memory map, path of execution and timing.   IT is
    > like opening the fridge door to se if the light is on.
    >

    It's a diagnostic. To debug you find the source of the bug and
    understand why the behaviour is as it is. It's not sufficient just to
    make a change and see the problem go away. Adding printfs() will let
    you do this. If the program is incorrect it's not possible that adding
    a printf() will make it correct - it might go wrong in a different
    way, but the bug will still be there.

    Actually, if the behaviour changes when you add a printf(), that's
    important and useful information. It tells you what sort of problem
    you are probably looking at.
     
    Malcolm McLean, Dec 13, 2010
    #15
  16. BartC

    Ian Collins Guest

    On 12/13/10 09:55 PM, Malcolm McLean wrote:
    > On Dec 13, 10:43 am, Chris H<> wrote:
    >>
    >> Of course many systems you have to ship the code that was tested.
    >> printf changes the memory map, path of execution and timing. IT is
    >> like opening the fridge door to se if the light is on.
    >>

    > It's a diagnostic. To debug you find the source of the bug and
    > understand why the behaviour is as it is. It's not sufficient just to
    > make a change and see the problem go away. Adding printfs() will let
    > you do this. If the program is incorrect it's not possible that adding
    > a printf() will make it correct - it might go wrong in a different
    > way, but the bug will still be there.


    You appear yo be overlooking the large (possibly the majority of
    current) number of applications that don't have a standard output. Try
    adding a printf to your microwave controller.

    > Actually, if the behaviour changes when you add a printf(), that's
    > important and useful information. It tells you what sort of problem
    > you are probably looking at.


    Have you ever worked with multi-threaded or real time systems?
    --
    Ian Collins
     
    Ian Collins, Dec 13, 2010
    #16
  17. On Dec 13, 11:02 am, Ian Collins <> wrote:
    >
    > You appear yo be overlooking the large (possibly the majority of
    > current) number of applications that don't have a standard output.  Try
    > adding a printf to your microwave controller.
    >

    In the development environment there's usually some output.
    >
    > > Actually, if the behaviour changes when you add a printf(), that's
    > > important and useful information. It tells you what sort of problem
    > > you are probably looking at.

    >
    > Have you ever worked with multi-threaded or real time systems?
    >

    Parallel code is a case in point. There was no debugger for my
    parallel MPI system. So you know that adding printfs is likely to
    change the synchonisation. The important point is, you can't make
    incorrect code into correct code simply by adding diagnostics. So the
    bug is still there, and you can find it.
     
    Malcolm McLean, Dec 13, 2010
    #17
  18. BartC

    BartC Guest

    "Ian Collins" <> wrote in message
    news:...
    > On 12/13/10 09:55 PM, Malcolm McLean wrote:
    >> On Dec 13, 10:43 am, Chris H<> wrote:
    >>>
    >>> Of course many systems you have to ship the code that was tested.
    >>> printf changes the memory map, path of execution and timing. IT is
    >>> like opening the fridge door to se if the light is on.
    >>>

    >> It's a diagnostic. To debug you find the source of the bug and
    >> understand why the behaviour is as it is. It's not sufficient just to
    >> make a change and see the problem go away. Adding printfs() will let
    >> you do this. If the program is incorrect it's not possible that adding
    >> a printf() will make it correct - it might go wrong in a different
    >> way, but the bug will still be there.

    >
    > You appear yo be overlooking the large (possibly the majority of current)
    > number of applications that don't have a standard output. Try adding a
    > printf to your microwave controller.


    I started off debugging microprocessor circuits using a multimeter. A bit
    later, when I was paid for it, I used an ordinary non-storage oscilloscope.

    Never did I have what some would consider the 'proper' equipment (logic
    analysers, ICEs, whatever).

    Yet, I could often debug a brand-new PCB (production faults, design faults,
    even the firmware) in a matter of hours (or possibly, if my memory is
    painting too favourable a picture, within a day or two..).

    Ingenuity can go a long way. It would not be inconceivable to hook up a
    temporary LCD character display to the microwave circuit, simply for the
    purpose of obtaining diagnostic output. Or even just place the output into
    memory accessible by a controlling PC. If you have some input into the
    hardware design, then you can build in test points.

    --
    Bartc
     
    BartC, Dec 13, 2010
    #18
  19. BartC

    Chris H Guest

    In message <
    s.com>, Malcolm McLean <> writes
    >On Dec 13, 10:43 am, Chris H <> wrote:
    >> In message <
    >>
    >> >No, a professional programmer who has often worked on systems where no
    >> >debugger is available.

    >>
    >> SO no logic analyser available then?
    >>

    >No. I've never used a logic analyser.


    Use an ICE?

    >> >I've never had a case of a known bug which couldn't be tracked down by
    >> >diagnostic alterations to the source code, but which was solved by use
    >> >of a debugger. I've had the reverse.

    >>
    >> I have... many times.
    >>
    >> Of course many systems you have to ship the code that was tested.
    >> printf changes the memory map, path of execution and timing.   IT is
    >> like opening the fridge door to se if the light is on.
    >>

    >It's a diagnostic. To debug you find the source of the bug and
    >understand why the behaviour is as it is. It's not sufficient just to
    >make a change and see the problem go away.


    Correct.

    >Adding printfs() will let
    >you do this. If the program is incorrect it's not possible that adding
    >a printf() will make it correct - it might go wrong in a different
    >way, but the bug will still be there.



    SO what help has that given? yo9u have added a whole load of variable
    and got a different behaviour.

    >Actually, if the behaviour changes when you add a printf(), that's
    >important and useful information. It tells you what sort of problem
    >you are probably looking at.


    Which is? change in timing? memory usage? library usage? compilation?
    reordering of variable and storage? change of optimisation? The lsit
    goes on.

    Without using a debugger with trace you have absolutely no idea how the
    printf got the output it is giving.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Dec 13, 2010
    #19
  20. BartC

    Chris H Guest

    In message <>, Ian Collins <ian-
    > writes
    >On 12/13/10 09:55 PM, Malcolm McLean wrote:
    >> On Dec 13, 10:43 am, Chris H<> wrote:
    >>>
    >>> Of course many systems you have to ship the code that was tested.
    >>> printf changes the memory map, path of execution and timing. IT is
    >>> like opening the fridge door to se if the light is on.
    >>>

    >> It's a diagnostic. To debug you find the source of the bug and
    >> understand why the behaviour is as it is. It's not sufficient just to
    >> make a change and see the problem go away. Adding printfs() will let
    >> you do this. If the program is incorrect it's not possible that adding
    >> a printf() will make it correct - it might go wrong in a different
    >> way, but the bug will still be there.

    >
    >You appear yo be overlooking the large (possibly the majority of
    >current) number of applications that don't have a standard output. Try
    >adding a printf to your microwave controller.
    >
    >> Actually, if the behaviour changes when you add a printf(), that's
    >> important and useful information. It tells you what sort of problem
    >> you are probably looking at.

    >
    >Have you ever worked with multi-threaded or real time systems?


    Wot? U mean like Windows and Linux? :)


    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris H, Dec 13, 2010
    #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. Marco Lorenzini
    Replies:
    0
    Views:
    409
    Marco Lorenzini
    May 13, 2004
  2. R. Bernstein
    Replies:
    18
    Views:
    606
  3. Magno

    Re: More on debuggers

    Magno, Nov 30, 2010, in forum: C Programming
    Replies:
    3
    Views:
    294
    Chris H
    Dec 1, 2010
  4. Lew Pitcher

    Re: More on debuggers

    Lew Pitcher, Nov 30, 2010, in forum: C Programming
    Replies:
    8
    Views:
    362
    Lew Pitcher
    Dec 1, 2010
  5. Chris H

    Re: More on debuggers

    Chris H, Dec 1, 2010, in forum: C Programming
    Replies:
    4
    Views:
    324
    Chris H
    Dec 1, 2010
Loading...

Share This Page