Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: More on debuggers

Reply
Thread Tools

Re: More on debuggers

 
 
Lew Pitcher
Guest
Posts: n/a
 
      11-30-2010
On November 30, 2010 15:09, in comp.lang.c, http://www.velocityreviews.com/forums/(E-Mail Removed) 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?do...0229726822034#
>
> 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. ------


 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      11-30-2010
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
 
Reply With Quote
 
 
 
 
Lew Pitcher
Guest
Posts: n/a
 
      11-30-2010
On November 30, 2010 17:03, in comp.lang.c, (E-Mail Removed) 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. ------


 
Reply With Quote
 
Magno
Guest
Posts: n/a
 
      11-30-2010
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.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-30-2010
On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
> On November 30, 2010 17:03, in comp.lang.c, (E-Mail Removed) 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
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      11-30-2010
On November 30, 2010 17:37, in comp.lang.c, (E-Mail Removed) wrote:

> On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
>> On November 30, 2010 17:03, in comp.lang.c, (E-Mail Removed) 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. ------


 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      12-01-2010
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
(E-Mail Removed)lid
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      12-01-2010
On 12/ 1/10 11:41 AM, Lew Pitcher wrote:
> On November 30, 2010 17:37, in comp.lang.c, (E-Mail Removed) wrote:
>
>> On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
>>> On November 30, 2010 17:03, in comp.lang.c, (E-Mail Removed) 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
 
Reply With Quote
 
Lew Pitcher
Guest
Posts: n/a
 
      12-01-2010
On November 30, 2010 20:46, in comp.lang.c, (E-Mail Removed)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. ------


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: More on debuggers BartC C Programming 82 12-19-2010 07:34 PM
Re: More on debuggers Chris H C Programming 4 12-01-2010 02:59 PM
Re: More on debuggers Magno C Programming 3 12-01-2010 08:02 AM
JDWP/JPDA - Often VM stops listening for debuggers connnection Marco Lorenzini Java 0 05-13-2004 04:03 PM



Advertisments