edw@wells.UUCP (Ed Wells) (02/08/89)
Several times while compiling large 'C' programs I ran into
'fatal error 26' errors. This is from a 'parser stack overflow'.
Does anyone know how to get around this one. I would think that
if the 386 if virtual, that the stack should never overflow unless
you run out of real memory.
What's strange about this is that even though it crashes compiling
in 386 mode, it works like in 286 large mode (-M2l flag).
Any comment anyone?
--
=========================================================================
Edward E. Wells Jr., President Voice: (215)-943-6061
Wells Computer Systems Corp., Box 343, Levittown, Pa. 19058
{dsinc,francis,hotps,lgnp1,mdi386,pebco}!wells!edwjbayer@ispi.UUCP (Jonathan Bayer) (02/10/89)
In article <10@wells.UUCP> edw@wells.UUCP (Ed Wells) writes: > > Several times while compiling large 'C' programs I ran into >'fatal error 26' errors. This is from a 'parser stack overflow'. >Does anyone know how to get around this one. I would think that >if the 386 if virtual, that the stack should never overflow unless >you run out of real memory. > > What's strange about this is that even though it crashes compiling >in 386 mode, it works like in 286 large mode (-M2l flag). I assume you are running SCO Xenix with the 2.2 development system. First thing is to know that the 86 and 286 mode use a different compiler than the 386 mode. That will explain why it works in 286 large mode, and not in 386 mode. The stack overflow is harder. I would assume that there are some internal constants in the compiler which are being exceeded. The parser probably has it's own internal stack stored somewhere in an array. If the array is exceeded it would generate this error. As to why the 386 compiler would have smaller constants than the 286, your guess is as good as mine. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi.UUCP