Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Re: More on debuggers (http://www.velocityreviews.com/forums/t739203-re-more-on-debuggers.html)

Lew Pitcher 11-30-2010 09:51 PM

Re: More on debuggers
 
On November 30, 2010 15:09, in comp.lang.c, rgrdev_@gmail.com 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. ------



Ian Collins 11-30-2010 10:03 PM

Re: More on debuggers
 
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

Lew Pitcher 11-30-2010 10:13 PM

Re: More on debuggers
 
On November 30, 2010 17:03, in comp.lang.c, ian-news@hotmail.com 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. ------



Magno 11-30-2010 10:14 PM

Re: More on debuggers
 
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.

Ian Collins 11-30-2010 10:37 PM

Re: More on debuggers
 
On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
> On November 30, 2010 17:03, in comp.lang.c, ian-news@hotmail.com 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

Lew Pitcher 11-30-2010 10:41 PM

Re: More on debuggers
 
On November 30, 2010 17:37, in comp.lang.c, ian-news@hotmail.com wrote:

> On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
>> On November 30, 2010 17:03, in comp.lang.c, ian-news@hotmail.com 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. ------



Eric Sosman 12-01-2010 01:46 AM

Re: More on debuggers
 
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
esosman@ieee-dot-org.invalid

Ian Collins 12-01-2010 02:09 AM

Re: More on debuggers
 
On 12/ 1/10 11:41 AM, Lew Pitcher wrote:
> On November 30, 2010 17:37, in comp.lang.c, ian-news@hotmail.com wrote:
>
>> On 12/ 1/10 11:13 AM, Lew Pitcher wrote:
>>> On November 30, 2010 17:03, in comp.lang.c, ian-news@hotmail.com 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

Lew Pitcher 12-01-2010 03:49 PM

Re: More on debuggers
 
On November 30, 2010 20:46, in comp.lang.c, esosman@ieee-dot-org.invalid
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. ------




All times are GMT. The time now is 06:05 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.