marks@tekigm2.TEK.COM (Mark D. Salzman) (12/19/87)
Hi out there,
A friend of mine just discovered a bug in Microsoft C Ver. 5.0 that
crashes the "cl" compiler. I offer it so others can avoid the problem
until Microsoft produces a fix (if ever). BTW, Microsoft has been informed
on the matter. The following short program produces the bug.
double a,b = 3.0;
main()
{
a = (b * 1.7E-9) + ((b * 1.9E-9) * 1.0E-4); /* <-- This crashes "cl" */
}
The "cl" compiler crashes with the following error message:
run-time error R6000
- stack overflow
Note that this works fine under Ver 4.0 and if you use Quick C. It also
works fine if you replace any of the constants with a variable. The value
of the constants have no effect on the bug as long as they are still clearly
floating point constants. The variable names used also have no effect.
I hope this prevents some headaches. Happy Programming.
--
Mark D. Salzman Phone (206) 253-5542. | The more complex the mind,
Tektronix Inc., P.O. Box 3500, M/S C1-937 | the greater the need for
Vancouver, Washington. 98668 | the simplicity of play.
{world_at_large}!tektronix!tekigm2!marks | James T. Kirktim@doug.UUCP (Tim J Ihde) (12/22/87)
In article <2276@tekigm2.TEK.COM>, marks@tekigm2.TEK.COM (Mark D. Salzman) writes: > A friend of mine just discovered a bug in Microsoft C Ver. 5.0 that > crashes the "cl" compiler . . . > > double a,b = 3.0; > main() > { > a = (b * 1.7E-9) + ((b * 1.9E-9) * 1.0E-4); /* <-- This crashes "cl" */ > } > > The "cl" compiler crashes with the following error message: > > run-time error R6000 > - stack overflow I'm not sure I see what is happening - you state that the compiler itself crashes, but that it reports a run-time error? A stack overflow complaint from your running program would simply mean that you need to use exemod and expand the stack space. On the other hand, if the compiler bombs out with a complaint like that, then it not only means a bug in the compiler but a bug that MS did not anticipate and wasn't checking for! I don't suppose your friend would have exemod'ed cl and decreased its allocated stack space? I myself found a bug awhile back and reported it here, but I got a more involved error message describing source file and line within the compiler itself and a note to notify MS support. Incidentally, I recieved email from them almost immediately letting me know that they were working on the problem - have you heard any comments from them about this? tim -- Tim J. Ihde ihnp4!ctsmain!doug!tim (201) 535-9897 Ok, we can all agree that this is my fault.
marks@tekigm2.TEK.COM (Mark D. Salzman) (12/23/87)
In article <433@doug.UUCP> tim@doug.UUCP (Tim J Ihde) writes: >In article <2276@tekigm2.TEK.COM>, marks@tekigm2.TEK.COM (Mark D. Salzman) writes: ## A friend of mine just discovered a bug in Microsoft C Ver. 5.0 that ## crashes the "cl" compiler . . . ## ## double a,b = 3.0; ## main() ## { ## a = (b * 1.7E-9) + ((b * 1.9E-9) * 1.0E-4); /* <-- This crashes "cl" */ ## } ## ## The "cl" compiler crashes with the following error message: ## ## run-time error R6000 ## - stack overflow # #I'm not sure I see what is happening - you state that the compiler itself #crashes, but that it reports a run-time error? A stack overflow complaint #from your running program would simply mean that you need to use exemod #and expand the stack space. On the other hand, if the compiler #bombs out with a complaint like that, then it not only means a bug in #the compiler but a bug that MS did not anticipate and wasn't checking #for! I don't suppose your friend would have exemod'ed cl and decreased #its allocated stack space? # # tim It is pass #2 of the "cl" compiler itself that crashes. You can see this by compiling the short program given above with the command: cl /d bugtest.c Note: This turns on a debug mode that shows the command line given for each pass of the compiler. We got a call back from Microsoft after my first posting and it was found that turning on loop optimizations (/Ol) also seems to "cure" this bug. We also tried changing the stack space of each pass of the compiler with EXEMOD and found it had no effect on the bug. Since there are so many ways to work around this bug, it will likely be a low priority for Microsoft to produce a fix. However they are working on it. -- Mark D. Salzman Phone (206) 253-5542. | The more complex the mind, Tektronix Inc., P.O. Box 3500, M/S C1-937 | the greater the need for Vancouver, Washington. 98668 | the simplicity of play. {world_at_large}!tektronix!tekigm2!marks | James T. Kirk
rmtodd@uokmax.UUCP (Richard Michael Todd) (12/23/87)
In article <433@doug.UUCP> tim@doug.UUCP (Tim J Ihde) writes: >In article <2276@tekigm2.TEK.COM>, marks@tekigm2.TEK.COM (Mark D. Salzman) writes: >> The "cl" compiler crashes with the following error message: >> run-time error R6000 >> - stack overflow >I'm not sure I see what is happening - you state that the compiler itself >crashes, but that it reports a run-time error? A stack overflow complaint The fact that a compiler crashes with "run-time error" doesn't surprise me at all. After all, the compiler is itself a program, presumably written in C; I assume Microsoft uses their own C compiler to create versions of MS C. The run-time error presumably comes from the compiled C code that makes up the C compiler. Their C code can overflow its stack space just as easily as yours can... >and expand the stack space. On the other hand, if the compiler >bombs out with a complaint like that, then it not only means a bug in >the compiler but a bug that MS did not anticipate and wasn't checking >for! I don't suppose your friend would have exemod'ed cl and decreased Yep, that's probably what it means. Unfortunately compilers are very complex pieces of software, and you never can be sure that the thing will function correctly under all conditions. I myself don't use Microsoft C, but I've found a couple of bugs that caused Aztec C v3.40 to crash. (So far I haven't seen 4.1 crash-yet.) The best we can hope for is that when customers find the bugs that the companies do a good job of fixing them. -------------------------------------------------------------------------- Richard Todd USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!occrsh!uokmax!rmtodd
platt@emory.uucp (Dan Platt) (12/30/87)
In article <433@doug.UUCP> tim@doug.UUCP (Tim J Ihde) writes: >In article <2276@tekigm2.TEK.COM>, marks@tekigm2.TEK.COM (Mark D. Salzman) writes: >> A friend of mine just discovered a bug in Microsoft C Ver. 5.0 that >> crashes the "cl" compiler . . . [with a stack-overflow error message] >> >> double a,b = 3.0; >> main() >> { >> a = (b * 1.7E-9) + ((b * 1.9E-9) * 1.0E-4); /* <-- This crashes "cl" */ >> } >> - stack overflow > ... I don't suppose your friend would have exemod'ed cl and decreased >its allocated stack space? > > tim >-- >Tim J. Ihde ihnp4!ctsmain!doug!tim >(201) 535-9897 Actually, this error is: 1) in the compiler, 2) not caused by exemod'ing the cl (it's actually probably not in cl proper, but in one of the files spawned by cl), 3) only works in the above format. A form like a=b*2+b*3*4; will also crash. A form like a=b+b*3*4; won't, and neither will a=b*2+b*3; and a=2*b+3*4*b; won't crash. This seems to be restricted to the above form. My guess is that it tries to save multiplies by factoring and gets sick. Given what you (Tim) said about MS working on the bug you reported, I wonder if Microsoft will come out with an update sooner than they usually do (maybe a msc5.1 -- something they've refrained from doning in the past). Dan Platt