Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!kaukau.comp.vuw.ac.nz!virtue!ccc_ldo
From: ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.system
Subject: "Yuck" to core dumps (was Re: X vs. Mac)
Message-ID: <399.26406397@waikato.ac.nz>
Date: 3 May 90 05:00:07 GMT
References: <1990Apr20.193426.16869@uswmrg2.UUCP> <5566@okstate.UUCP> <1990Apr25 <67@victoria.cs.utexas.edu> <1990May1.163331.625@smsc.sony.com> <1990May2.214126.18304@agate.berkeley.edu>
Followup-To: comp.sys.mac.system
Lines: 27

In <1990May2.214126.18304@agate.berkeley.edu>, c60c-3cf@web-3a.berkeley.edu
(Dan Kogai) says "UNIX is far better ... Core dump is better than Bomb
Alert or Macsbug screen..."

I say "Bleah!" to core dumps. I much prefer the VMS "traceback"
facility. Here's an example:

%RMS-F-SYN, file specification syntax error
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

DIRECTORY_STACK PARSE_DEFAULT                     540      000000AD  00000E0D
DIRECTORY_STACK DO_PUSH                           599      00000022  00001452
DIRECTORY_STACK DO_COMMAND                       1062      0000003B  0000106F
DIRECTORY_STACK DIRECTORY_STACK                  1099      0000003E  0000102E

Cryptic error messages aside, often that's all the information you need
to find a bug in your program. And the overhead? About 10% extra in the
size of the on-disk application file, *zero* in-memory space and run-time
overhead--until your program bombs. And this is the level of debugging you
get by default!

Lawrence D'Oliveiro
Computer Services Dept                    fone: +64-71-562-889
University of Waikato                      fax: +64-71-384-066
Hamilton, New Zealand            electric mail: ldo@waikato.ac.nz
I think, therefore I can't thwim.