New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build error: "region RAM overflowed with stack" #363

Closed
carlosperate opened this Issue Oct 21, 2016 · 17 comments

Comments

Projects
None yet
4 participants
@carlosperate
Contributor

carlosperate commented Oct 21, 2016

Running the latest available gcc-arm-none-eabi 5.4.1 for debian-based systems (https://launchpad.net/~team-gcc-arm-embedded/+archive/ubuntu/ppa), I am basically running out of memory on a clean master:

/usr/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: region RAM overflowed with stack
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
error: command ['ninja'] failed

I basically have to reduce 320 bytes from the heap:

// allocate the heap statically in the bss
static uint32_t heap[9692 / 4];

to:

static uint32_t heap[9372 / 4];

This is quite a lot of memory, has anybody else experienced this?

@carlosperate carlosperate changed the title from Running out of heap to Running out of RAM Oct 23, 2016

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Oct 24, 2016

Member

I have to ask: did you do "yt up"? I did see this problem before but I think it was just on a development branch. Current master builds for me just fine, using gcc 6.2.0, but 5.4.1 should be that different that you need 320 extra bytes of RAM.

Member

dpgeorge commented Oct 24, 2016

I have to ask: did you do "yt up"? I did see this problem before but I think it was just on a development branch. Current master builds for me just fine, using gcc 6.2.0, but 5.4.1 should be that different that you need 320 extra bytes of RAM.

@carlosperate

This comment has been minimized.

Show comment
Hide comment
@carlosperate

carlosperate Oct 24, 2016

Contributor

Yes, I've basically used this script and done all this on a Vagrant virtual machine using Ubuntu 16.04, so this specific case can be easily replicated (link).

I forgot to add that I was also using the patch submitted to lancaster-university/microbit-dal#228, not sure if that could affect it.

Contributor

carlosperate commented Oct 24, 2016

Yes, I've basically used this script and done all this on a Vagrant virtual machine using Ubuntu 16.04, so this specific case can be easily replicated (link).

I forgot to add that I was also using the patch submitted to lancaster-university/microbit-dal#228, not sure if that could affect it.

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Oct 24, 2016

Member

I forgot to add that I was also using the patch submitted to lancaster-university/microbit-dal#228, not sure if that could affect it.

Hmm, it might. Can you please try without that patch?

Member

dpgeorge commented Oct 24, 2016

I forgot to add that I was also using the patch submitted to lancaster-university/microbit-dal#228, not sure if that could affect it.

Hmm, it might. Can you please try without that patch?

@carlosperate

This comment has been minimized.

Show comment
Hide comment
@carlosperate

carlosperate Oct 24, 2016

Contributor

Can't compile micropython without it, so unless I compile a newer compatible version of gcc arm from source (or install arch) I am not sure how else to test it.
Alternatively you could try to compile it in 6.2 with the changed dependency?

Contributor

carlosperate commented Oct 24, 2016

Can't compile micropython without it, so unless I compile a newer compatible version of gcc arm from source (or install arch) I am not sure how else to test it.
Alternatively you could try to compile it in 6.2 with the changed dependency?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Oct 24, 2016

Member

Alternatively you could try to compile it in 6.2 with the changed dependency?

Using "carlosperate/microbit-dal#update_ble_dep" as the dependency for microbit-dal (instead of lancaster version) it builds ok for me with gcc 6.2.

The issue you're having is probably something to do with the C library (newlib?) that's taking extra RAM. Without inspecing the resulting .map files it's hard to debug this.

Member

dpgeorge commented Oct 24, 2016

Alternatively you could try to compile it in 6.2 with the changed dependency?

Using "carlosperate/microbit-dal#update_ble_dep" as the dependency for microbit-dal (instead of lancaster version) it builds ok for me with gcc 6.2.

The issue you're having is probably something to do with the C library (newlib?) that's taking extra RAM. Without inspecing the resulting .map files it's hard to debug this.

@carlosperate

This comment has been minimized.

Show comment
Hide comment
@carlosperate

carlosperate Oct 24, 2016

Contributor

Could you upload somewhere the map file you got from the build with my dal fork? I could have a look tonight and post mine as well.

Contributor

carlosperate commented Oct 24, 2016

Could you upload somewhere the map file you got from the build with my dal fork? I could have a look tonight and post mine as well.

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Oct 24, 2016

Member

Could you upload somewhere the map file you got from the build with my dal fork?

See http://micropython.org/resources/microbit-micropython.map.gz

Member

dpgeorge commented Oct 24, 2016

Could you upload somewhere the map file you got from the build with my dal fork?

See http://micropython.org/resources/microbit-micropython.map.gz

@carlosperate

This comment has been minimized.

Show comment
Hide comment
@carlosperate

carlosperate Oct 24, 2016

Contributor

Thanks Damien, I'll see what I can spot tonight.

Contributor

carlosperate commented Oct 24, 2016

Thanks Damien, I'll see what I can spot tonight.

@carlosperate

This comment has been minimized.

Show comment
Hide comment
@carlosperate

carlosperate Oct 25, 2016

Contributor

So I didn't have as much time as I thought tonight, so didn't have a chance to have a proper look at the map files. On a quick scan noticed that the data section is ~360 Bytes larger:

mine:   .data           0x0000000020000000      0x290 load address 0x000000000003c404
yours:  .data           0x0000000020000000      0x128 load address 0x000000000003a238

But the bss is 316 bytes smaller

mine:   .bss            0x0000000020000290     0x2d70 load address 0x000000000003c694
yours:  .bss            0x0000000020000128     0x2eac load address 0x000000000003a360

https://gist.githubusercontent.com/carlosperate/bee7267830dbc1aed8d3b828e95cfb10/raw/96ac2b88cfa939c5fe218502d7c9d2085ac0ca6b/microbit-micropython.map

Is it possible that the std has not been set and the default has changed to c++11 or 14 between gcc 5 and 6?

Contributor

carlosperate commented Oct 25, 2016

So I didn't have as much time as I thought tonight, so didn't have a chance to have a proper look at the map files. On a quick scan noticed that the data section is ~360 Bytes larger:

mine:   .data           0x0000000020000000      0x290 load address 0x000000000003c404
yours:  .data           0x0000000020000000      0x128 load address 0x000000000003a238

But the bss is 316 bytes smaller

mine:   .bss            0x0000000020000290     0x2d70 load address 0x000000000003c694
yours:  .bss            0x0000000020000128     0x2eac load address 0x000000000003a360

https://gist.githubusercontent.com/carlosperate/bee7267830dbc1aed8d3b828e95cfb10/raw/96ac2b88cfa939c5fe218502d7c9d2085ac0ca6b/microbit-micropython.map

Is it possible that the std has not been set and the default has changed to c++11 or 14 between gcc 5 and 6?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Oct 25, 2016

Member

Make sure you build your version with the original uPy heap size. To get it to build you can edit ./yotta_targets/bbc-microbit-classic-gcc-nosd/ld/NRF51822.ld and change line 6, increase the RAM LENGTH.

Member

dpgeorge commented Oct 25, 2016

Make sure you build your version with the original uPy heap size. To get it to build you can edit ./yotta_targets/bbc-microbit-classic-gcc-nosd/ld/NRF51822.ld and change line 6, increase the RAM LENGTH.

@carlosperate

This comment has been minimized.

Show comment
Hide comment
@carlosperate

carlosperate Oct 28, 2016

Contributor

Sorry, I haven't had a chance to look into this yet (had to spend the time working on something else instead). I'll see if I can spare some time next week.

@dpgeorge we could still target the newest version of the DAL as that should work for everybody as this is a different issue. It's a tiny change, do you you'll change that manually soon, or prefer I send a PR?

Contributor

carlosperate commented Oct 28, 2016

Sorry, I haven't had a chance to look into this yet (had to spend the time working on something else instead). I'll see if I can spare some time next week.

@dpgeorge we could still target the newest version of the DAL as that should work for everybody as this is a different issue. It's a tiny change, do you you'll change that manually soon, or prefer I send a PR?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Nov 3, 2016

Member

@carlosperate see #374 for the update to the DAL.

Member

dpgeorge commented Nov 3, 2016

@carlosperate see #374 for the update to the DAL.

@jimmo

This comment has been minimized.

Show comment
Hide comment
@jimmo

jimmo Jan 6, 2017

Contributor

FYI - I just ran into this also, building on Arch Linux which (currently) uses newlib 2.5.0 and arm-none-eabi-gcc 6.3.0

The main thing I noticed was that a lot of symbols relating to "locale" were using up BSS. @carlosperate I can't load your map file above but might be worth checking if it has the same problem -- look for __global_locale. Damien's map file doesn't have these symbols.

Reverting to newlib 2.4.0-2 solved it for me (all the locale symbols disappeared from the map). (Note that reverting to 2.4.0-4 wasn't sufficient).

I hope there's a way to disable the new locale code with a #define or something...

Contributor

jimmo commented Jan 6, 2017

FYI - I just ran into this also, building on Arch Linux which (currently) uses newlib 2.5.0 and arm-none-eabi-gcc 6.3.0

The main thing I noticed was that a lot of symbols relating to "locale" were using up BSS. @carlosperate I can't load your map file above but might be worth checking if it has the same problem -- look for __global_locale. Damien's map file doesn't have these symbols.

Reverting to newlib 2.4.0-2 solved it for me (all the locale symbols disappeared from the map). (Note that reverting to 2.4.0-4 wasn't sufficient).

I hope there's a way to disable the new locale code with a #define or something...

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 6, 2017

Member

I also hit this (again) in the past few days. I'll try to find a fix.

Member

dpgeorge commented Jan 6, 2017

I also hit this (again) in the past few days. I'll try to find a fix.

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 6, 2017

Member

Reverting to newlib 2.4.0-2 solved it for me (all the locale symbols disappeared from the map). (Note that reverting to 2.4.0-4 wasn't sufficient).

newlib 2.5.0 introduced some new locale handling code, and has a large (~350 bytes) __global_locale data structure that is not constant and isn't put in ROM but rather in RAM. Looking at the newlib source code it could be that this data structure is read-only and could in fact go in ROM, but that requires patching/fixing upstream (and it's a long way upstream, would take a while to filter down).

There is no easy way to fix this. The data structure is used by strtol, isalpha, etc and you can't override these symbols by defining your own. You could disabled the entire stdlib (-nostdlib) but then you'd need to provide implementations of many functions, like memset, sprintf, fclose, malloc, free, etc.

Only real option seems to be to stick with newlib 2.4.0-2.

@jaustin any other ideas how to fix or work around this?

Member

dpgeorge commented Jan 6, 2017

Reverting to newlib 2.4.0-2 solved it for me (all the locale symbols disappeared from the map). (Note that reverting to 2.4.0-4 wasn't sufficient).

newlib 2.5.0 introduced some new locale handling code, and has a large (~350 bytes) __global_locale data structure that is not constant and isn't put in ROM but rather in RAM. Looking at the newlib source code it could be that this data structure is read-only and could in fact go in ROM, but that requires patching/fixing upstream (and it's a long way upstream, would take a while to filter down).

There is no easy way to fix this. The data structure is used by strtol, isalpha, etc and you can't override these symbols by defining your own. You could disabled the entire stdlib (-nostdlib) but then you'd need to provide implementations of many functions, like memset, sprintf, fclose, malloc, free, etc.

Only real option seems to be to stick with newlib 2.4.0-2.

@jaustin any other ideas how to fix or work around this?

@dpgeorge dpgeorge changed the title from Running out of RAM to build error: "region RAM overflowed with stack" Jan 6, 2017

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Jan 19, 2017

Member

Ping @jaustin : this issue with newlib 2.5 taking a lot of RAM may soon become a real issue for everyone using mbed, not just us. Do you have any thoughts how to deal with it?

Member

dpgeorge commented Jan 19, 2017

Ping @jaustin : this issue with newlib 2.5 taking a lot of RAM may soon become a real issue for everyone using mbed, not just us. Do you have any thoughts how to deal with it?

@dpgeorge

This comment has been minimized.

Show comment
Hide comment
@dpgeorge

dpgeorge Mar 7, 2018

Member

Fixed by 498125d

Member

dpgeorge commented Mar 7, 2018

Fixed by 498125d

@dpgeorge dpgeorge closed this Mar 7, 2018

@microbit-carlos microbit-carlos added this to the v1.0 milestone Mar 8, 2018

qoelet added a commit to qoelet/radiobit that referenced this issue Jul 16, 2018

Reduce heap size
There is a similar issue to builds failing with `region RAM
overflowed with stack` mentioned in
bbcmicrobit/micropython#363.

@qoelet qoelet referenced this issue Jul 16, 2018

Closed

Reduce heap size #5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment