🚀 go-pugleaf

gc948374@tycho.gbar.dtu.dk (Rask Lambertsen) writes:

>On Thu, 14 Sep 1995 11:19:57 GMT Bernd "Bernie" Meyer (root@wombat.hanse.de) wrote:
>> corp0008@sable.ox.ac.uk (John Reynolds) writes:

>> >I don't find it to be too much of a problem. It is true that
>> >when developing software on my Amiga, I have to reboot fairly
>> >frequently, but it only takes a few seconds. It is usually
>> >fairly obvious when my code has gone wrong. ;)

>> Is it also obvious _where_ it has gone wrong, and _why_? Getting a nice
>> coredump instead of a system crash has its adavntages --- the debugger can
>> analyze the coredump, but not the system crash.

>??? Have you never heard of those Guru numbers that the Amiga OS give?

Heard of them? Seen them! 

>They have often allowed me to pin-point the problem.

But they just give a short indication of what happened, and where in memory.
The second information is basically worthless in a multitasking system
without separate address spaces, and the first isn't that informative.

Also, the GURU often doesn't happen when things go wrong, but some time
later. The first wild memory access has a good chance of not being fatal,
as has the second, the third, ......

>Also don't forget basic debugging techniques such as debugging output
>from your programmes.

You bet I won't forget these. However, when you develop stuff with
interesting data structures and dynamic memory management, the thing
might suddenly crash in the middle of your main loop, after getting
through it correctly several million times. Now I don't like several
million debugging lines on my harddisk, just to find out I didn't print
the one important value. 

However, typing "ups program core" after it
dumped core will allow me to see exactly where it was when dumping core
(in the source code, that is!), to look at any variable the program had
and so on. I can the set breakpoints at strategically clever points
and restart the program. I can also interrupt a program caught in an
infinite loop and look at all variables.

I am not talking about Mandelbrot programs here. I am talking about
linked lists the elements of which are pointers to elements of another
linked list, which are pointers to structures that, among a lot of
other information, include three more linked lists which hold pointers back
to other such structures, sometimes in the same, sometimes in other lists.
They also hold pointers back to the first element of the previously mentioned
linked list

Then there are a bunch of arrays of pointers pointing directly at various
points in that list-jungle (for faster access).

Now that structure not only has to be created once and that's it. No, 
that structure is heavilyy manipulated, at every level lists are extended
and (worse!) pruned. Memory has to be deallocated at just the right time,
making sure no pointers to freed regions exist anymore.

Now if you can manage to find out why, with a certain input sequence, the
program dies at frame 283 (of 400, each frame takes 5 seconds to work on)
in a routine that worked flawlessly hundreds of thousands of times before,
just by putting in debugging output, you are a better bug-hunter than I am.
And I am very good at bug-hunting, believe me.

>There is also the option of running the program with a debugger in the
>background.

Which is pretty useless once your system crashes, right?

>Btw, lots of nasty thing can happen to a UN*X system that runs out of
>hard disk space during a coredump.

Huh? If you fear that, you

a) limit the maximum core file size ("man ulimit") or
b) do your testing on a partition other than /

BTW, what "nasty things" do you refer to?

Bernie

P.S.: And you can always run your program _in_ the debugger. No need for
corefiles then.
-- 
==============================================================================
I'm using an experimental version of "nn" to read news. So if anything seems
strange about the headers of this mail or post, please inform me. Thanks!