Re: More on debuggers

Discussion in 'C Programming' started by Lew Pitcher, Nov 30, 2010.

  1. Lew Pitcher

    Lew Pitcher Guest

    On November 30, 2010 15:09, in comp.lang.c, wrote:

    >
    > 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,


    Huh?? I've never read /that/ opinion here. Are you sure that you got that
    right? Or are you just exaggerating for effect?

    > 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.


    Yes, a good debugger can do all that.

    > Obviously he's not as
    > smart as the people here who claim they prefer to read a print out .....


    Again, I've never read /that/ opinion here.

    OTOH, I /have/ read (and stated myself) that often there is no need for a
    debugger, and, in many instances, a debugger is often not available.

    For instance, in the job I retired from, we were /forbidden/ to run a
    debugger on production code in a production environment. In fact,
    there /was no debugger installed/ in that environment. Should an abend
    occur, we were expected to diagnose and repair the error from program
    listings, data listings, and a symbolic dump alone.

    Perhaps you (mis)remember these sorts of statements?

    --
    Lew Pitcher
    Master Codewright & JOAT-in-training | Registered Linux User #112576
    Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
    ---------- Slackware - Because I know what I'm doing. ------
    Lew Pitcher, Nov 30, 2010
    #1
    1. Advertising

  2. Lew Pitcher

    Ian Collins Guest

    On 12/ 1/10 10:51 AM, Lew Pitcher wrote:
    >
    > For instance, in the job I retired from, we were /forbidden/ to run a
    > debugger on production code in a production environment. In fact,
    > there /was no debugger installed/ in that environment. Should an abend
    > occur, we were expected to diagnose and repair the error from program
    > listings, data listings, and a symbolic dump alone.


    Why? Security paranoia?

    --
    Ian Collins
    Ian Collins, Nov 30, 2010
    #2
    1. Advertising

  3. Lew Pitcher

    Lew Pitcher Guest

    On November 30, 2010 17:03, in comp.lang.c, wrote:

    > On 12/ 1/10 10:51 AM, Lew Pitcher wrote:
    >>
    >> For instance, in the job I retired from, we were /forbidden/ to run a
    >> debugger on production code in a production environment. In fact,
    >> there /was no debugger installed/ in that environment. Should an abend
    >> occur, we were expected to diagnose and repair the error from program
    >> listings, data listings, and a symbolic dump alone.

    >
    > Why? Security paranoia?


    That, to a small degree.

    But... when you run a 7/24 shop, servicing thousands of branches, providing
    sub-millisecond response time for both personal and commercial banking
    services, mortgages, cash machines, loans, payrolls, etc. you /do not/ want
    some hack programmer burning cycles and locking up production databases and
    data, trying to debug a S0C7. Production systems are no place for
    interactive debugging sessions. And, production systems are the /only/
    place for production data (which is often the thing that initiates an
    abend).

    So, to diagnose and repair a production abend, you /don't/ resort to
    interactive debugging; you read the source code, the abend dump, and the
    dataset, and determine *from logic alone* what the cause of the abend is.
    Then, you code a fix, apply it to the test system, have other people
    promote the fix into production, and rerun the job that abended, hopefully
    without error this time.

    FWIW, I worked for a large Canadian bank; one of the few that didn't have
    ABCP problems (because we didn't hold any ABCP).

    --
    Lew Pitcher
    Master Codewright & JOAT-in-training | Registered Linux User #112576
    Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
    ---------- Slackware - Because I know what I'm doing. ------
    Lew Pitcher, Nov 30, 2010
    #3
  4. Lew Pitcher

    Magno Guest

    On 11/30/2010 07:03 PM, Ian Collins wrote:
    > On 12/ 1/10 10:51 AM, Lew Pitcher wrote:
    >>
    >> For instance, in the job I retired from, we were /forbidden/ to run a
    >> debugger on production code in a production environment. In fact,
    >> there /was no debugger installed/ in that environment. Should an abend
    >> occur, we were expected to diagnose and repair the error from program
    >> listings, data listings, and a symbolic dump alone.

    >
    > Why? Security paranoia?
    >


    Perhaps they just wanted to make sure that the hired staff was competent
    enough.
    Magno, Nov 30, 2010
    #4
  5. Lew Pitcher

    Ian Collins Guest

    On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
    > On November 30, 2010 17:03, in comp.lang.c, wrote:
    >
    >> On 12/ 1/10 10:51 AM, Lew Pitcher wrote:
    >>>
    >>> For instance, in the job I retired from, we were /forbidden/ to run a
    >>> debugger on production code in a production environment. In fact,
    >>> there /was no debugger installed/ in that environment. Should an abend
    >>> occur, we were expected to diagnose and repair the error from program
    >>> listings, data listings, and a symbolic dump alone.

    >>
    >> Why? Security paranoia?

    >
    > That, to a small degree.
    >
    > But... when you run a 7/24 shop, servicing thousands of branches, providing
    > sub-millisecond response time for both personal and commercial banking
    > services, mortgages, cash machines, loans, payrolls, etc. you /do not/ want
    > some hack programmer burning cycles and locking up production databases and
    > data, trying to debug a S0C7. Production systems are no place for
    > interactive debugging sessions. And, production systems are the /only/
    > place for production data (which is often the thing that initiates an
    > abend).


    Ah. There's one answer to that - DTrace. But you need the right OS to
    use it!

    --
    Ian Collins
    Ian Collins, Nov 30, 2010
    #5
  6. Lew Pitcher

    Lew Pitcher Guest

    On November 30, 2010 17:37, in comp.lang.c, wrote:

    > On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
    >> On November 30, 2010 17:03, in comp.lang.c, wrote:
    >>
    >>> On 12/ 1/10 10:51 AM, Lew Pitcher wrote:
    >>>>
    >>>> For instance, in the job I retired from, we were /forbidden/ to run a
    >>>> debugger on production code in a production environment. In fact,
    >>>> there /was no debugger installed/ in that environment. Should an abend
    >>>> occur, we were expected to diagnose and repair the error from program
    >>>> listings, data listings, and a symbolic dump alone.
    >>>
    >>> Why? Security paranoia?

    >>
    >> That, to a small degree.
    >>
    >> But... when you run a 7/24 shop, servicing thousands of branches,
    >> providing sub-millisecond response time for both personal and commercial
    >> banking services, mortgages, cash machines, loans, payrolls, etc. you /do
    >> not/ want some hack programmer burning cycles and locking up production
    >> databases and data, trying to debug a S0C7. Production systems are no
    >> place for interactive debugging sessions. And, production systems are the
    >> /only/ place for production data (which is often the thing that initiates
    >> an abend).

    >
    > Ah. There's one answer to that - DTrace. But you need the right OS to
    > use it!


    Which OS would that be? If it isn't one of {MVS, OS/390, zOS}, then it
    wouldn't have worked for us.

    --
    Lew Pitcher
    Master Codewright & JOAT-in-training | Registered Linux User #112576
    Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
    ---------- Slackware - Because I know what I'm doing. ------
    Lew Pitcher, Nov 30, 2010
    #6
  7. Lew Pitcher

    Eric Sosman Guest

    On 11/30/2010 5:13 PM, Lew Pitcher wrote:
    > [...] Production systems are no place for
    > interactive debugging sessions. And, production systems are the /only/
    > place for production data (which is often the thing that initiates an
    > abend).
    >
    > So, to diagnose and repair a production abend, you /don't/ resort to
    > interactive debugging; you read the source code, the abend dump, and the
    > dataset, and determine *from logic alone* what the cause of the abend is.
    > Then, you code a fix, apply it to the test system, have other people
    > promote the fix into production, and rerun the job that abended, hopefully
    > without error this time.


    Agreed. I'd also note that relying on post-mortem diagnosis
    drives the adoption of coding techniques specifically designed to
    help that diagnosis along. A particularly helpful technique is the
    "history buffer" (I'm not sure what others may call it). I first
    encountered it in an assembly-language program I'd inherited from
    someone smarter, the first real-time code I'd ever worked with. All
    through the code at strategic moments you'd find

    BAL R14,TRACE REMEMBER THIS MOMENT, MY SON

    "BAL R14," was roughly the equivalent of "CALL SUBROUTINE", and the
    TRACE subroutine would simply record its return address in a circular
    buffer and then return. (The remainder of the line, as you may have
    guessed, was commentary.) In the event of an abend or other crash,
    the core dump would include the contents of the circular buffer and
    hence a history of the last couple hundred trace-points that had been
    encountered. "How in Heaven's name did we get *here*?" was fairly
    easily answered.

    I submit that this approach is something that would be unlikely to
    occur to someone who relied purely on interactive debugging techniques.
    He'd want to track the history by setting breakpoints here and there,
    stepping around and seeing where the program went. Since the suspension
    of execution is a bad idea when there's a client awaiting a response (in
    some applications, many millions of dinars may ride on its promptness),
    stalling at a breakpoint while some programmer ponders is probably not
    a good idea. Better to crash and to redirect the client to the backup
    server; he'll get his answer a few milliseconds later rather than some
    tens of minutes later.

    Interactive debugging techniques focus on what is happenING, while
    post-mortem techniques look at what happenED. IMHO, the former can be
    applied only in certain situations, while the latter are nearly always
    applicable.

    --
    Eric Sosman
    lid
    Eric Sosman, Dec 1, 2010
    #7
  8. Lew Pitcher

    Ian Collins Guest

    On 12/ 1/10 11:41 AM, Lew Pitcher wrote:
    > On November 30, 2010 17:37, in comp.lang.c, wrote:
    >
    >> On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
    >>> On November 30, 2010 17:03, in comp.lang.c, wrote:
    >>>
    >>>> On 12/ 1/10 10:51 AM, Lew Pitcher wrote:
    >>>>>
    >>>>> For instance, in the job I retired from, we were /forbidden/ to run a
    >>>>> debugger on production code in a production environment. In fact,
    >>>>> there /was no debugger installed/ in that environment. Should an abend
    >>>>> occur, we were expected to diagnose and repair the error from program
    >>>>> listings, data listings, and a symbolic dump alone.
    >>>>
    >>>> Why? Security paranoia?
    >>>
    >>> That, to a small degree.
    >>>
    >>> But... when you run a 7/24 shop, servicing thousands of branches,
    >>> providing sub-millisecond response time for both personal and commercial
    >>> banking services, mortgages, cash machines, loans, payrolls, etc. you /do
    >>> not/ want some hack programmer burning cycles and locking up production
    >>> databases and data, trying to debug a S0C7. Production systems are no
    >>> place for interactive debugging sessions. And, production systems are the
    >>> /only/ place for production data (which is often the thing that initiates
    >>> an abend).

    >>
    >> Ah. There's one answer to that - DTrace. But you need the right OS to
    >> use it!

    >
    > Which OS would that be? If it isn't one of {MVS, OS/390, zOS}, then it
    > wouldn't have worked for us.


    Anything derived from Solaris (and I believe MacOS).

    --
    Ian Collins
    Ian Collins, Dec 1, 2010
    #8
  9. Lew Pitcher

    Lew Pitcher Guest

    On November 30, 2010 20:46, in comp.lang.c, lid
    wrote:

    > On 11/30/2010 5:13 PM, Lew Pitcher wrote:
    >> [...] Production systems are no place for
    >> interactive debugging sessions. And, production systems are the /only/
    >> place for production data (which is often the thing that initiates an
    >> abend).
    >>
    >> So, to diagnose and repair a production abend, you /don't/ resort to
    >> interactive debugging; you read the source code, the abend dump, and the
    >> dataset, and determine *from logic alone* what the cause of the abend is.
    >> Then, you code a fix, apply it to the test system, have other people
    >> promote the fix into production, and rerun the job that abended,
    >> hopefully without error this time.

    >
    > Agreed. I'd also note that relying on post-mortem diagnosis
    > drives the adoption of coding techniques specifically designed to
    > help that diagnosis along. A particularly helpful technique is the
    > "history buffer" (I'm not sure what others may call it). I first
    > encountered it in an assembly-language program I'd inherited from
    > someone smarter, the first real-time code I'd ever worked with. All
    > through the code at strategic moments you'd find
    >
    > BAL R14,TRACE REMEMBER THIS MOMENT, MY SON


    By the time I retired, we had "lost" most of our Assembly programmers. While
    I /did/ write assembly, I mostly wrote in high-level languages. It is
    regrettable that the "new" generation of programmers didn't have
    low-level-language exposure; their code was remarkably convoluted for
    something that would have to execute tens-of-thousands of times per second,
    and they could have learned a lot from even a brief exposure to the
    low-level impacts.

    [snip]
    > Interactive debugging techniques focus on what is happenING, while
    > post-mortem techniques look at what happenED. IMHO, the former can be
    > applied only in certain situations, while the latter are nearly always
    > applicable.


    So true. And "what's happening" is often not available when the programmer
    has to debug (unless you get the end-user to recreate the problem at
    leasure, which is not usually possible).


    --
    Lew Pitcher
    Master Codewright & JOAT-in-training | Registered Linux User #112576
    Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
    ---------- Slackware - Because I know what I'm doing. ------
    Lew Pitcher, Dec 1, 2010
    #9
    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:
    388
    Marco Lorenzini
    May 13, 2004
  2. R. Bernstein
    Replies:
    18
    Views:
    577
  3. Magno

    Re: More on debuggers

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

    Re: More on debuggers

    Chris H, Dec 1, 2010, in forum: C Programming
    Replies:
    4
    Views:
    312
    Chris H
    Dec 1, 2010
  5. BartC

    Re: More on debuggers

    BartC, Dec 1, 2010, in forum: C Programming
    Replies:
    82
    Views:
    1,590
    Ian Collins
    Dec 19, 2010
Loading...

Share This Page