Re: Seriously struggling with C

Herbert Rosenau wrote:
On Fri, 24 Feb 2006 00:29:09 UTC, Flash Gordon <spam@xxxxxxxxxxxxxxxxxx> wrote:

Herbert Rosenau wrote:
<snip>
Oh look, my debugger broke on the file open failing. <fx: looks at file system> Odd, the file is there and with correct permissions. <fx: Looks at nicely timestamped logs from system here and system 200 miles away> Ah, I see, that server 200 miles away is taking longer than the specified time to put the file on my server.

There are times when debug logs can be *far* easier to use than a debugger. Not always in my opinion, but they do exist.

I've found never such a situation.

You may not, but I have.

> It was always at lest
- knowing how to use the debug

I know how. I even use it when appropriate.

- exact knowledge of how the system works

Being one of the authors of one of the systems and the maintainer of the main library it uses I have a pretty good idea.

(what does an API do excactly on which condition and what side effects
are prior, during and after the system api gets called are active

So tell me, how am I to know from the documentation of the other application that it can't cope with 5 simultaneous connections when even the company selling it doesn't know that?

I generally know the interfaces to the extent they are documented, and over time I learn a lot that is not documented. It does not change the reality of the situation that I and others sometimes find it *far* easier to go through logs.

Or another situation that really has happened to me. Two different programs one in Java the other in C are interacting in an incorrect manner. However, the system only fails more than once every few weeks when under heavy load at customer sites in the week before month end when they are running hundreds of invoices through the system hourly. Do I ask my customer if they will let me know each time they start a new session so I can attach a debugger to it (I can't wait the minimum likely time of weeks minimum it would take for me to replicate the problem once and don't know *exactly* what the customers 50 users in that department are doing to cause it) or do I spend an hour putting in some debug logging and ask them to run with that build for a bit?

Oh, for such remote environment we had setup our CORBA applications running on the same mashine as CORBA is designed to work local or remote even under another OS.

<fx: Phones up Microsoft> Excuse me, can you please add a CORMA interface to SQL Server 2000?

<fx: Phones up Oracle> Excuse me, can you please add a CORBA interface to Oracle Financials?

Hmm. That's strange. They don't seem to be prepared to make the required changes this month.

> Setting up an test environment had not
even a single change of the code needed - but a bit defferent environment. So debugging server and client in parallel was more nice as to fiund some technices to setup debug logfiles.

Se tell me how I am going to debug Oracle Financials, or MS SQL Server, or Sun Financials, or any of the many other systems my SW has to interface with in parallel with mine.

Not to mention that if I break my application sometimes the application on the far end will time out the connection forcing me to start again.

I chose putting in some debug logging. I had a significant piece of the puzzle a couple of days later (they could not install the debug build immediately) and the next day I had the solution. Far less work than using a debugger would have been.

It is quite common for those reporting bugs to miss out some critical piece of information in what they are doing. The addition of easily enabled logging is gradually making it far easier for us to see exactly what the customer is doing to cause the failure, something a debugger can never do.

I had an similar situation. One of our customers reported constantly an abnormal end of one application - but nobody and nothing was able to reproduce that until we crippled a mashine to exact the same hardware environment the user had.

<fx: me phones up Boss> Hello, can you authorise a purchase order for half a million pounds cost of kit so I can replicate the customer environment? No, I can't get it second hand because it is brand new current kit.

Even renting kit can be rather expensive.

You see, our customers are much bigger than us and buy much more expensive HW than we can afford.

Not to mention needing licenses for all the applications it is being interfaced to, and not having a couple of hundred people I can sit down at PCs entering data (or the 200 PCs for them to sit at) or...

> So it was easy in 9 from 10 runs to
produce the abort - but it was impossible to find the cause for even then. Using a debugger to catch it was resulting in unable to get the abort reproduced! Using the same debugger then more advanced and it was absolutely clear what the cause was and using the brain it was easy to fix by manually syncronise the threads at that critical point against the stand rules. The next version of the OS brought a new system API to make that syncronising inside the kernel to make that problem going away.

<snip>

Just because it worked for you does not mean it is always the best approach.

I'll use logging where appropriate, debuggers when appropriate, and sitting down with a printout and a pen when appropriate. All methods have problems and all have advantages.
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro - http://clc-wiki.net/wiki/Intro_to_clc
.