Hi,

Been trying to compile a nondescript C-project on my A1. The grim reaper jumps in saying that red zone was damaged. Later on, when trying again I get a stack overflow to acknowledge. Somewhere on 3.4.2/ccl or something. (Oops, forgot which specific funktion it was about...)

Could stacksize be the culprit? What is its initial size? And how do I increase it?

OldFart

_________________
Life is a waste of time.
Time is a waste of life.
Get wasted all the time
and you'll have the time of your life!

@OldFart

Use DOS preferences or type "stack 123456" in shell (replacing 123456 maybe ;)

@OldFart

There at least four ways to set the stack

1) prefs/DOS - globally for all commands

2) in the icon of a Tool

3) as a stack cookie in the executable itself

4) run as "stack 100000" right before you run the command in a shell


As Juha pointed out the most sensible way for gcc would be the 4th way. Maybe make yourself a compile-shell script or icon that you use solely for stack-heavy tasks like compiling big projects, specially c++ ones are.

_________________
Nicolas Mendoza

@nicomen & Juha


Running the makefile from its icon. Default tool is 'Make'. Set stack to 300.000. Same thing.

Maybe there is some other thing in the source that upsets the compiler. I'll downgrade the source until there is nothing left to compile anymore.


Thanks,

OldFart

P.s.: It is InternalRunCommand() that suffers from a stack overrun.

Last edited by OldFart on 13-Apr-2005 at 07:36 AM.

_________________
Life is a waste of time.
Time is a waste of life.
Get wasted all the time
and you'll have the time of your life!

@OldFart

what version of OS4 pre are you running - Update 2 ?

did you update the SDK ?

I found that I could no longer compile with the SDK off the original Pre-Release CD
once I did the big update (similar symptoms)

re-installing the SDK off the 2nd CD fixed it for me.

of course, hardly any of my makefile scripts worked, but a smidge of fiddling solved that.

_________________
XH558 - the worlds last flying Vulcan.
ok, its actually XL426 in the picture but you know what I mean.

@Agafaster

Tracked it down to exactly 1 line of offending code. But that code, being a macro, expands to some 15 lines of code, mostly tags for a CHOOSER-gadget. Must have overlooked some fact while thinking it up. After commenting-out that one line, it compiles fine.

Thanks anyway,

OldFart

P.s.: have indeed upgraded to the latest version, i.e. 2nd upgrade, but do not know whether I've upgraded the SDK as well. If it had to be done manually then certainly not. If it did so automatically then probably I have the latest in SDK.

_________________
Life is a waste of time.
Time is a waste of life.
Get wasted all the time
and you'll have the time of your life!

Quote:

by OldFart on 13-Apr-2005 7:33:50 @nicomen & Juha Running the makefile from its icon. Default tool is 'Make'. Set stack to 300.000. Same thing. Maybe there is some other thing in the source that upsets the compiler. I'll downgrade the source until there is nothing left to compile anymore. Thanks, OldFart P.s.: It is InternalRunCommand() that suffers from a stack overrun.

@nicomen & Juha, thank you for your input on the makefile issue with 'Make'. Adjusting the default tool and setting STACK size to 300,000 should help manage memory usage during compilation. Downgrading source files might be necessary if specific code triggers a stack overrun in InternalRunCommand(). I appreciate OldFart's proactive approach!