re:
During a C++ compilation ...
"Leg1.c", line 87: internal <<AT&T C++ Translator
2.1.03 08/31/90>> error: bus error (or something
nasty like that)
Compilation failed
 ------------------------

 I am grateful to all the people who helped me resolve
 this problem.  Many contributed advice and suggestions,
 but especially helpful were Gary Angel and
 Shankar Unni.

 The error message may be symptomatic of a broad range
 of problems, for many tentative diagnoses were
 nominated.  I found one problem.  It occurs in that
 part of the C++ translator called "cfront".  It is
 not clear to me whether cfront contains a bug.

 The line of source at which the problem occurs is such as

        SwapLeg = (LegPtr)calloc(1, LEG_SIZE);

 Here is the fix:

 //#define LEG_SIZE sizeof(Leg)
 #define LEG_SIZE sizeof(struct leg)

 We had this pattern of code in six or eight programs.
 The line number cited in the error message is the
 closing bracket "}" of the function in which the
 error occurs.


 ----------------------------------------------

 Hypotheses proven false.

 1.  Big program uses too much memory.
 2.  ESQL causes it.
 3.  Unused argument list variables  cause it.
 4.  CC "+w" option causes.
 5.  Error occurs in cpp.
 6.  Error does not occur in cfront.

DanB

--
 --------------------------------------------------------------
 Daniel Brockman             tel 415-953-0406, fax 415-622-2892
 Bank of America, Dept 5906, 555 Calif St
 San Francisco 94104 USA    email uunet!odinba!dan dan@BofA.COM

In article <1992Nov10.192157.20810@BofA.com>, dan@BofA.COM (Dan Brockman) writes:
|> re:
|> During a C++ compilation ...
|> "Leg1.c", line 87: internal <<AT&T C++ Translator
|> 2.1.03 08/31/90>> error: bus error (or something
|> nasty like that)
|> Compilation failed

                    ...

|>  The error message may be symptomatic of a broad range
|>  of problems, for many tentative diagnoses were
|>  nominated.  I found one problem.  It occurs in that
|>  part of the C++ translator called "cfront".  It is
|>  not clear to me whether cfront contains a bug.

When a compiler dies with an internal error, causes an access
violation, etc. it is *always* a bug.
--
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm

In <1992Nov14.233744.27337@ornl.gov> mullens@jamsun.ic.ornl.gov (James A. Mullens) writes:

>In article <5798@npg-sd.SanDiegoCA.NCR.COM>, rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert) writes:
>|> In <BxIp1L.M37@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
>|>
>|> >When a compiler dies with an internal error, causes an access
>|> >violation, etc. it is *always* a bug.
>|>
>|> Not *always*: if the internal error is caused by an error in the program
>|> being compiled, it is merely a very user-unfriendly error message (I
>|> consider "segmentation violation -- core dumped" to be the ultimate
>|> diagnostic).

>You forgot the (;-), right?

I purposely omitted it, but it was implied.  I try to be subtle.

Sorry to decrease the signal/noise ratio of comp.std.c++, though.  I had
second thoughts after posting (although the original article, and resulting
thread, shouldn't have been cross-posted to comp.std.c++, anyway).

>I'd say *always*.  I'd also say that C++ compilers are more prone to this
>problem than any other language compilers (my experience anyway).

cfront seems to be prone to this.  Are these other C++ compilers cfront-based?
[You don't have to answer that.]

>When I'm faced with an access violation/segmentation violation/bus error,
>and I really have no clue as to what's causing it, I start removing large
>blocks of source code with #if 0 ... #endif until the compiler finishes
>successfully.  Then I reintroduce parts of code until the compiler bombs
>again.  In the end, the problem is isolated.  I may have a programming
>error there, or the compiler may just be batty.  I always send a bug report.
>I'd like to send a bill for my time ( at $60/hour :-).

It's always a good idea to try to isolate a problem before reporting it:
it increases your chances of having the bug fixed (not to mention helping
out the people supporting the software).

Follow-ups probably not appropriate, but I'm not redirecting them.

-- Rick Schubert (rick.schubert@SanDiegoCA.NCR.COM)

In article <5798@npg-sd.SanDiegoCA.NCR.COM>, rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert) writes:
|> In <BxIp1L.M37@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
|>
|> >When a compiler dies with an internal error, causes an access
|> >violation, etc. it is *always* a bug.
|>
|> Not *always*: if the internal error is caused by an error in the program
|> being compiled, it is merely a very user-unfriendly error message (I

Nonsense.  It is a symptom of an oversight on the part of the compiler
writer to handle less than ideal programs.  It is a flaw in the
compiler.  (I'm sure we all have these flaws in our compilers, but
they *are* flaws.  It is our job to eliminate them -- or at least
to minimize them.)

(Actually, the correct answer is along the lines of:  Not *always*.
Such an internal error *could* be caused by a bug in the operating
system -- in which case it is not the fault of the compiler.  But
this case certainly is pretty rare.)

|> consider "segmentation violation -- core dumped" to be the ultimate
|> diagnostic).
|>
|> -- Rick Schubert (rick.schubert@SanDiegoCA.NCR.COM)

You must use a lot of UNIX compilers -- maybe even free ones.
--
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm

In article <1992Nov14.233744.27337@ornl.gov>, mullens@jamsun.ic.ornl.gov (James A. Mullens) writes:

|> When I'm faced with an access violation/segmentation violation/bus error,
|> and I really have no clue as to what's causing it, I start removing large
|> blocks of source code with #if 0 ... #endif until the compiler finishes
|> successfully.  Then I reintroduce parts of code until the compiler bombs
|> again.  In the end, the problem is isolated.  I may have a programming
|> error there, or the compiler may just be batty.  I always send a bug report.
|> I'd like to send a bill for my time ( at $60/hour :-).

Pretty irritating, isn't it?  Certainly *we* expect to receive a bug report
if our compiler behaves in this way -- and having someone pinpoint the
problem with a test case of a finite number of lines is heavenly.
If you don't have debuggable version of the compiler (and most production
versions aren't), these things are *hard* to find.  $60/hr would be
a bargain.
--
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm

In article <5798@npg-sd.SanDiegoCA.NCR.COM> rns@npg-sd.SanDiegoCA.NCR.COM (Rick Schubert) writes:
|In <BxIp1L.M37@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
|
|>When a compiler dies with an internal error, causes an access
|>violation, etc. it is *always* a bug.
|
|Not *always*: if the internal error is caused by an error in the program
|being compiled, it is merely a very user-unfriendly error message (I
|consider "segmentation violation -- core dumped" to be the ultimate
|diagnostic).

I'd say you're both right -- because a "bug" is any failure to meet
customer expectations.  In the case of the "C" standard it is quite
"legal" for a compiler to crash when fed an erroneous program --
as long as it emits some kind of warning or error message before during
or after its death.  Whether or not this meets customer expectations
or not is not a "legal" issue.  [In the case of the "C++" standard there
isn't so who can say?]  Personally, I hate compilers that die without
an applicable line#, such that I have to debug by binary chop.  But, I
have yet to find any compiler where it is not easy to construct
erroneous input such as to kill the compiler horribly.  A better measure
is whether or not beginning programmers frequently write erroneous programs
that invoke such horrible deaths.  Once people begin to understand the language,
they tend to exercise these truly exceptional paths [partway;-] through
the compiler less often.

In article <1992Nov17.013839.20401@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:

|> isn't so who can say?]  Personally, I hate compilers that die without
|> an applicable line#, such that I have to debug by binary chop.  But, I
|> have yet to find any compiler where it is not easy to construct
|> erroneous input such as to kill the compiler horribly.  A better measure

I would dispute the "easy" here (except as a report of your own experience
with a given set of compilers, of course).  It's pretty hard to do this
on our mainframe C compiler.  Usually what is required is some pretty
hideous source that will take advantage of chinks in the compiler's
error recovery and result in a cascade of errors.  Our testing department
is pretty devious and perverse in throwing crap at the compiler.
Still, it's *possible* to construct source that will make the compiler
barf.  We still regard the barfing as a bug.

It's been a long time since I used it, but I think the PL/I Checkout
Compiler was pretty robust.  I don't recall ever getting it to go
belly up, but it could get pretty tedious watching it try to reconstruct
an acceptable program from what you had handed it if you just left
a semi-colon off a declaration.  As in virtually everything, there
are tradeoffs here.
--
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm