Can't compile with 800MZ Sam Flex

Today I discovered that I can't compile large programs on my SAM FLex (800 MX) with the latest public OS4 SDK. After some files are compiled, cc1 crashes with an ISI error and I have to reboot. The cc1 module crashed 7 times while I was compiling YAM and 3 times while I was compiling Jabberwocky. Here are some of the unsuccessful changes I have tried:
Reinstalled the SDK from the archive on an SFS/2 and SFS/0 partition.
Booted with the OS 4.1 CD to see if the Quickfix was the problem.
Tried compiling with the sources in a ram: directory.
Tried compiling with the SDK installed in ram:
Tried compiling with only 512MB memory installed in SAM Flex.
Switched to older versions of "make" and "sh".

Can anyone else with an 800MZ SAM Flex compile large programs successfully? Does anyone have additional suggestions for changes I can try to fix my compile problem. I'm no programming expert, but I've been compiling programs with OS4 for a couple of years and never encountered problems as serious as this.

@xenic

what stack size are you using? I usually use "stack 10000000" to be safe.

Varthall

@Varthall
I use 400000 stack on my ?A1 and have been using 800000 on the SAM Flex. I think 10000000 seems excessive, but I'll give it a try and let you know if it changes anything.

@Varthall
I tried your huge stack suggestion. It doesn't seem to make any difference. Hopefully someone will point me in the right direction so I can get back to using my computer instead of debugging it.

@xenic

I wouldn't suggest ever using any stack smaller than 1000000 when compiling (I have this in S:Shell-Startup). For larger projects I usually use 20000000 to be safe. Sometimes I have to use even 30000000 or more when compiling some projects.

@xenic

Does it crash at the same file each time?

@xenic

I know this crashes from my AOne XE.

I fixed it after MUCH hassle and trial and error by reducing the size of the RAM to 512MB (read 1 Module). As soon as two modules were in OR a 1 GB stick it kept crashing on me.

Unfortunately it seems that you already tried that.

I don?t know what it could cause in your case, but i?ll be interested in a solution you?ll eventually find (maybe there *is* a bug afterall?)

Good luck

@broadblues
Quote:
No. Somtimes it crashes after compiling 3 files, other times it might make it as far as a dozen files before crashing. So far it occurs with any large program I've tried to compile so the source code doesn't seem to make any difference.

@xenic

That's probably not a stack issue then, where I've had crashes due insufficient stack it's always on the same files. (usually C++ ones).

Do you have another high cpu high disk usage app, you can run a test with?

@Raziel
Quote:
I may try 512MB again. I noticed when I applied the Quickfix that there are SOBJS for GCC. Considering other problems occuring with different amounts of memory installed in A1 and SAM, I wonder if the dynamic linking could be affected by the memory map?
I have tried one more thing since starting this topic and it works. If I replace the "gcc" directory in the latest SDK with the "gcc" directory from the previous SDK the compile works start to finish every time. That would seem to indicate that the crash is related to the current GCC installation and not some hardware problem on my SAM. As I suggested, I'm suspicious of the SOBJS. They were eliminated from recent OWB versions for a reason I suspect. I would still like to get the latest SDK working on my SAM though.

@xenic

gcc etal as far as I can tell are not dynamically linked. Certainly I'm running a build of AWeb at the background and the SOBJS: assigned is still in a defered state.

The new sobjs in the update are used by gcc to create new dynamically linked programs (and the resulting programs to link with at runtime). If there was a problem with them, the programs you *build* would be crashing not gcc itself.

@broadblues
Quote:
Yes. You're right. After my original most I tried reassigning SOBJS: to an empty directory and ran the compiler. It works normally other than the cc1 crashes. I also tried the compiler with 512MB again instead of 1GB but that doesn't help. I wonder if GCC or CC1 could be using processor specific instructions that are different or don't exist on the SAM processor. Since nobody else with a SAM Flex has chimed in with a confirmation of this problem, it's hard to tell if it's just my system or a general SAM problem. I'm hoping one of the devs will take a look at the issue since I'd rather be compiling with the latest SDK.

@xenic

What is it you are compiling and I'll give it a go when I get home from work?

@Slayer
Mainly I've been testing with sources that I've kept on my system for a long time. I've been testing with the current YAM sources from the SVN repository at SourceForge and the Jabberwocky sources from SourceForge CVS repository. To compile current YAM you will need to install newer "Flex" from OS4Depot.net but Jabberwocky might need some unusual Includes that you may not have installed. This evening I will D/L some large sources from OS4Depot that might be easier for others to try also. I'll let you know what I find so you can try that if you don't have access to the other sources I mentioned.

@xenic
(SAM-flex)
Sucks in my opinion. Seems like an admission that the 800MZ board is flawed and had to be slowed down.
Maybe is not a 'sucking' problem, but a bad timer chip! Afterall, isn't it a SAM 667 overclocked?
[ b] I've been compiling programs with OS4 for a couple of years and never encountered problems as serious as this. [/b]
What does ACube think?

@Snuffy
Quote:
What's your point? All I can say is the the problems I've encountered are certainly sucking the enthusiasm out of me.
Quote:
I'm not sure what they think but they seem to be saying that if Debian works then there is nothing wrong with the hardware.

@Slayer
I haven't been able to find any large sources on OS4Depot that will compile without hunting down some includes or tinkering with the makefile/sources. Some smaller sources like AmiSounded seem to compile without a crash. I check out the sources for MuiBase from SourceForge and made it about 95% through the compile before cc1 crashed. So far it crashes for me with the YAM, Jabberwocky & MUIBase sources. Can you check out YAM or MUIBase and try compiling those. YAM seems to crash cc1 most reliably.

@xenic

What's your point?
Send it back to ACube! You're wasting your time trying to compile your code if there's a hardware timing problem. Let them look and see. It's under warranty, yes? Other SAM owners haven't been as annoyed as as much as you, so let's re-evaluate the problem and ask ACube to checkout your board. I would do this if I was in your predicament.

@xenic

Do you some times have errors in the Boot picture? or maybe the Background of the Workbench screen is coruppted.

For I have the same problem that I can't compile without crashes, and I suspect the HD makes read errors. I havent tested with another HD so far.

RWO

@all

the ppl with the sam 600mhz have this kind of problems too or it is just for the overclocked version ?

I am plan to use one sam and this kind of topics make me worried.

I never use the AmigaOS 4+, it have a guru meditation like the classic ?

how it show the crash ? some report ?

do you know if it is a really a stack overflow to just increase the stack to try abort the problem ?

BR,

edit ************

looking the 440ep architeture maybe the problem that we are having, and looking we giving much stack to the environment, I suspect the problem is in the memory alocation.

The PPC 440ep have a bug in the last 256k alocation anddress, if the OS no make it unvailable, I do not know if it is, we will have problems if the program tray get this .

from the errata
-------------------------------
CHIP_11: End of memory range area restricted access.
Category: 3
Overview:
The PPC440EP DDR controller acknowledges transactions which cross over the end-of-memory-range boundary and correctly responds only with the valid data. When the PLB3-to-PLB4 bridge is the PLB4 bus master making the read request to the DDR controller, it waits indefinitely until it receives all of the data requested regardless of the boundary condition.
Impact:
Since the DDR controller only returns the valid portion of a read request, the PLB3-to-PLB4 bridge waits indefinitely for the remaining data preventing other PLB masters from completing their transactions.
Workaround:
Forbid any application to access the last 256 bytes of DDR memory. For example, make your operating system believe that the last 256 bytes of DDR memory are absent.

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

Maybe other problem, but maybe is in it.

no much data about what you are dooing to know more about the problem.

sorry to not explain best, my english is terrible.

I hope it help you.

BR

Ice