Error compiling C program on MSX

[albs-br]

Hi, after hitting a certain complexity on code I'm getting the following error:

abort("Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 268435456, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which allows increasing the size at runtime, or (3) if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0 ") at Error at jsStackTrace (https://8bitworkshop.com/v3.8.0/src/worker/wasm/sdcc.js:5:17950) at stackTrace (https://8bitworkshop.com/v3.8.0/src/worker/wasm/sdcc.js:5:18121) at abort (https://8bitworkshop.com/v3.8.0/src/worker/wasm/sdcc.js:5:143510) at abortOnCannotGrowMemory (https://8bitworkshop.com/v3.8.0/src/worker/wasm/sdcc.js:5:19188) at enlargeMemory (https://8bitworkshop.com/v3.8.0/src/worker/wasm/sdcc.js:5:19544) at <anonymous>:wasm-function[2141]:0x142780 at <anonymous>:wasm-function[1537]:0x119941 at <anonymous>:wasm-function[56]:0x1b0e at <anonymous>:wasm-function[58]:0x1bca at <anonymous>:wasm-function[153]:0x12245 If this abort() is unexpected, build with -s ASSERTIONS=1 which can give more information.

If I remove/comment the last line of code I wrote, the error vanishes.

Project link: https://8bitworkshop.com/v3.8.0/?repo=albs-br%2Farya&platform=msx&file=main.c#

Thanks for helping.

[sehugg]

Sometimes SDCC does that with large (actually not that large) functions. Try splitting up your biggest function and see if it happens again.

[TheFakeMontyOnTheRun]

Just to reinforce the solution, refactoring my code circumvented the issue. It's rather odd that I faced this on 8bitworkshop, but not with CPCTelera (which also uses SDCC). Could be the case of different versions? 🤷‍♂️

If, in any case, we wanted to actually expand the memory on a local instance, where would we have to look into, please?

[MikeDX]

Just to reinforce the solution, refactoring my code circumvented the issue. It's rather odd that I faced this on 8bitworkshop, but not with CPCTelera (which also uses SDCC). Could be the case of different versions? 🤷‍♂️

If, in any case, we wanted to actually expand the memory on a local instance, where would we have to look into, please?

In addition to the above, my pitfall for galaxian hw (60/40 mix of asm/c) absolutely refuses to compile regardless of function sizes, so I had to build 8bitworkshop locally, including 8bitworkshop-compilers, adding

 -s ALLOW_MEMORY_GROWTH=1

into the SDCC_FLAGS section.

it may be worth considering this for a future update, but I won't insult your intelligence by submitting a PR

[sehugg]

I've had problems with SDCC running out of memory even assembling .asm files! Not sure why it's so hungry. Maybe the right idea is to ALLOW_MEMORY_GROWTH on everything? I kinda worry about if it needs more than 512 MB or so though, as I'd like the IDE to run on underpowered Chromebooks. Maybe there are some flags like --max-allocs-per-node that will help.

Thanks for compiling the compilers, good to know it still works! It's been a bit of a pain dealing with different Emscripten versions. (Pitfall for Galaxian hardware sounds amazing btw!)

BTW, CPCTelera is integrated now so you can try that too if you like!

[MikeDX]

I've had problems with SDCC running out of memory even assembling .asm files! Not sure why it's so hungry. Maybe the right idea is to ALLOW_MEMORY_GROWTH on everything? I kinda worry about if it needs more than 512 MB or so though, as I'd like the IDE to run on underpowered Chromebooks. Maybe there are some flags like --max-allocs-per-node that will help.

The way I understand it is the memory is only upped when necessary and I think sdcc will use it briefly for sorting/caching until the output completes. on a chromebook even with modest ram it should just swap in and out. I don't believe it will cause a bigger issue that prevents 8bitworkshop running on lower end chrromebook although the concern there is not memory but performance of the emulator(s).

Thanks for compiling the compilers, good to know it still works! It's been a bit of a pain dealing with different Emscripten versions. (Pitfall for Galaxian hardware sounds amazing btw!)

Thanks!! I've been using 8bitworkshop for the main development, but had to modify slightly to get the different hw configuration targets to work correctly. This means I can target 3 different scramble boards, and an ongoing work in progress that run on the master system, all compiling in 8bitworkshop!

BTW, CPCTelera is integrated now so you can try that too if you like!

Great! Just played with the snowy scene example, that's lovely to see.

I'd really like to get commodore c16/plus4 running if at all possible. I have already got a web emulator built for it, but I'm unsure of the steps to integrate it into the IDE. It's more simple than the C64 so hopefully that's something you could help me with.

[sehugg]

Did you manage to get SDCC compiled with the latest Emscripten (I think 3.x now)?

I really should do a "how to add a new platform" FAQ. This doc is a start. There are two paths, either implement the Machine interface for full debugging support, or just the bare minimum of the Platform interface like the x86. There's also the WASM interface which I use for C64, ZX, and CPC via the chips library (VIC20 is also available but not integrated, dunno if C16 would be easy to add)

I don't like to put copyrighted ROMs into the main repo which might be a sticky point for C16 (C64 has an open source ROM) but the IDE will allow you to upload your own BIOS, it just has to be named ".bios" I think.

[ninjadynamics]

Hi!

I think I'm facing a similar issue on with a very complex MMC3 NES project. I'm getting the following error: abort("OOM"). Build with -s ASSERTIONS=1 for more info.

If I compile offline using CC65 on Linux, I face no issues whatsoever, everything works just fine.

[MikeDX]

@sehugg are there any plans for a new version that includes this minor change soon please? I'm encountering issues now with projects in 8080wb, galaxian and sms now due to memory limits.

I notice there is an open issue for checking out the same repo into a different platforms, something I'm also looking forward to (tried to checkout my multi platform pitfall to sms but failing and having to do it manually)

[sehugg]

Would you mind posting some test cases, preferably single files? I can put them into the test suite and then figure out the proper command line flags, or if a SDCC rebuild is needed. There's an automated build at https://sehugg.github.io/8bitworkshop/ so it'll be fairly quick once the fix is in. Thanks!

[MikeDX]

I don't think I've got anything "open source" that violates the SDCC compiler flags as-is but i'll add you to the repo so you can see the offending files if that's any good.

[sehugg]

The current build of SDCC is limited due to the version of Emscripten it was compiled with; it's stuck at 256MB. However I'm not sure increasing the memory size would fix it, if the problem is a runaway loop that allocates memory. The best solution for the current build is to hack apart files and functions as neccessary to get the bugs to go away.

The latest SDCC (4.2.x) at least compiles your project, and upgrading SDCC is probably the right solution going forward. However it breaks a bunch of existing projects for various reasons -- the z80 calling convention has changed, for example. It even exposes a Z80 emulator bug! So it'll take awhile to work out the kinks and make sure there's an upgrade path for existing code.

[MikeDX]

Is there an option here to compile sdcc with a modern emscripten? I think that's how I ended up completing the project locally (I could be wrong, it seems a lifetime ago).

However I do have that local build/setup on another machine I could run some version numbers on.

Is the problem that I have buggy code? I'm happy to fix it by that route if necessary - or are you saying that's one of the possible cases where increasing the memory catches us out.