arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted

[Arjan van Vught]

Dear list,

What does the error mean? Is it just that the .list file is not generated completely? This error got introduced when upgrading from version 7 to 9.

Many thanks in advance. Arjan


arm-none-eabi-objdump -D lib_h3/libh3.a | arm-none-eabi-c++filt > lib_h3/lib.list
arm-none-eabi-objdump: error: lib_h3/libh3.a(h3_codec.o)(.bss) section size (0x800c bytes) is larger than file size (0xde8 bytes)
arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted
arm-none-eabi-objdump: error: lib_h3/libh3.a(udp.o)(.bss) section size (0x19934 bytes) is larger than file size (0xcfc bytes)
arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted

~ % arm-none-eabi-objdump --version
GNU objdump (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 2.33.1.20191025

[Bob Proulx]

This mailing list has very little activity. I don't know and would
normally comment but I hate to see people post questions and then not
get any response at all. Therefore I will comment here in the hope
that I might be able to get you to a better place to ask your question.

Arjan van Vught wrote:
> What does the error mean? Is it just that the .list file is not
> generated completely? This error got introduced when upgrading from
> version 7 to 9.

Upgrading what from version 7 to what version 9? What is being
upgraded?

> arm-none-eabi-objdump -D lib_h3/libh3.a | arm-none-eabi-c++filt > lib_h3/lib.list
> arm-none-eabi-objdump: error: lib_h3/libh3.a(h3_codec.o)(.bss) section size (0x800c bytes) is larger than file size (0xde8 bytes)

The BSS section is normally used to store static data. In a C program
if one is defining a variable with initialized data then this will go
into the BSS section.

int iii = 42;

It makes no sense if the BSS segment is larger than the file size. It
makes me thing there is a data corruption problem. Or perhaps the
file system is full and part of the file could not be written. Or
potentially other problem of which this is only a down stream cascade
failure with a different root cause.

Reference:

https://en.wikipedia.org/wiki/.bss

> arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted

Memory exhausted indicates that the program tried to allocate memory
or tried to fork and whichever action it was failed due to being out
of virtual memory.

I would look to see if the storage filled up. I would look to see if
whatever you are doing ran out of memory.

Since this is ARM I assume some type of NAND flash file system. In
which case I would look for a failure of the storage such as due to
worn out storage cells. If it is an SD card I would try reading from
every byte and verifying that the storage device is working okay. I
have had SD cards using NAND storage and other similar devices fail
creating file corruption.

Bob

[Bob Proulx]

Bob Proulx wrote:
> The BSS section is normally used to store static data. In a C program
> if one is defining a variable with initialized data then this will go
> into the BSS section.

Did I say that reversed from what it is actually? How embarrasing!
That is what I get from answering too quickly without thinking
everything through carefully.

Bob

[Arjan van Vught]

> Op 7 apr. 2020, om 02:41 heeft Bob Proulx <b...@proulx.com> het volgende geschreven:
>
> This mailing list has very little activity. I don't know and would
> normally comment but I hate to see people post questions and then not
> get any response at all. Therefore I will comment here in the hope
> that I might be able to get you to a better place to ask your question.

Hi Bob, thank you working on this issue with me. Much appreciated.

>
> Arjan van Vught wrote:
>> What does the error mean? Is it just that the .list file is not
>> generated completely? This error got introduced when upgrading from
>> version 7 to 9.
>
> Upgrading what from version 7 to what version 9? What is being
> upgraded?

With the brew cask upgrade the GNU tools got updated from 7 to 9 ->

arm-none-eabi-objdump --version
GNU objdump (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 2.33.1.20191025
>

>> arm-none-eabi-objdump -D lib_h3/libh3.a | arm-none-eabi-c++filt > lib_h3/lib.list
>> arm-none-eabi-objdump: error: lib_h3/libh3.a(h3_codec.o)(.bss) section size (0x800c bytes) is larger than file size (0xde8 bytes)
>

> The BSS section is normally used to store static data. In a C program
> if one is defining a variable with initialized data then this will go
> into the BSS section.
>

> int iii = 42;
>
> It makes no sense if the BSS segment is larger than the file size. It
> makes me thing there is a data corruption problem. Or perhaps the
> file system is full and part of the file could not be written. Or
> potentially other problem of which this is only a down stream cascade
> failure with a different root cause.

arjanvanvught@MacBook-Air lib-h3 % arm-none-eabi-objdump -D lib_h3/libh3.a | arm-none-eabi-c++filt > lib_h3/lib.list

arm-none-eabi-objdump: error: lib_h3/libh3.a(h3_codec.o)(.bss) section size (0x800c bytes) is larger than file size (0xde8 bytes)

arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted

arm-none-eabi-objdump: error: lib_h3/libh3.a(udp.o)(.bss) section size (0x19934 bytes) is larger than file size (0xcfc bytes)

arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted

arjanvanvught@MacBook-Air lib-h3 % echo $?
0

arjanvanvught@MacBook-Air lib-h3 % ls -al build_h3/src/h3_codec.o
-rwx------ 1 arjanvanvught staff 3560 7 apr 17:50 build_h3/src/h3_codec.o

The file size of the object file is 3560 bytes which is the (0xde8 bytes) as mentioned in the error. Why would there be an error or even better; why would there be any relationship between the allocated bytes in .bss and the object file size?

objdump is just displaying information from object files. This looks to me as an internal error for objdump.

The objdump exit code is 0. Therefore the command is completing correctly.

>
> Reference:
>
> https://en.wikipedia.org/wiki/.bss
>
>> arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted
>
> Memory exhausted indicates that the program tried to allocate memory
> or tried to fork and whichever action it was failed due to being out
> of virtual memory.
>
> I would look to see if the storage filled up. I would look to see if
> whatever you are doing ran out of memory.
>
> Since this is ARM I assume some type of NAND flash file system. In
> which case I would look for a failure of the storage such as due to
> worn out storage cells. If it is an SD card I would try reading from
> every byte and verifying that the storage device is working okay. I
> have had SD cards using NAND storage and other similar devices fail
> creating file corruption.

The cross-compilation is running on MacOS with 8GB RAM. It would be surprising to me when objdump, working with a relative small archive file, is running out memory.
It seems to be that there is somehow a bug introduced within objdump.

Would it be good to open a bug report with objdump?

Thanks, Arjan

>
> Bob

[Bob Proulx]

Arjan van Vught wrote:
> > Bob Proulx het volgende geschreven:

> >> What does the error mean? Is it just that the .list file is not
> >> generated completely? This error got introduced when upgrading from
> >> version 7 to 9.
> >
> > Upgrading what from version 7 to what version 9? What is being
> > upgraded?
>
> With the brew cask upgrade the GNU tools got updated from 7 to 9 ->
> arm-none-eabi-objdump --version
> GNU objdump (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 2.33.1.20191025

objdump is part of the GNU binutils package. Therefore I deduce from
this that you must be upgrading binutils from 7 to 9. HOWEVER! The
latest version of binutils appears to be 2.34 and therefore that does
not make sense.

$ objdump --version
GNU objdump (GNU Binutils for Debian) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

What is it exactly that you are trying to upgrade from 7 to 9?

Whatever that *thing* is that is where you should be directing your
questions. But version 7 and version 9 do not match up with any
available version of binutils.

I have no idea what "brew cask" might possibly be. Must be some Apple
thing? Perhaps you should be discussing this problem with the people
behind that project?

> arjanvanvught@MacBook-Air lib-h3 % ls -al build_h3/src/h3_codec.o
> -rwx------ 1 arjanvanvught staff 3560 7 apr 17:50 build_h3/src/h3_codec.o
>
> The file size of the object file is 3560 bytes which is the (0xde8
> bytes) as mentioned in the error. Why would there be an error or
> even better; why would there be any relationship between the
> allocated bytes in .bss and the object file size?

I have no idea.

> objdump is just displaying information from object files. This looks
> to me as an internal error for objdump.

I have no idea.

> The objdump exit code is 0. Therefore the command is completing
> correctly.

Or at least the program did not report an error.

> The cross-compilation is running on MacOS with 8GB RAM. It would be
> surprising to me when objdump, working with a relative small archive
> file, is running out memory.

It all depends upon what else is running consuming memory at the same
time. The program is reporting it is out of memory. That's all I can
tell from the error message.

> It seems to be that there is somehow a bug introduced within
> objdump.
>
> Would it be good to open a bug report with objdump?

Generally these things tend not to be bugs in the upstream project
like binutils. Since binutils is used by almost everything.
Typically I would expect to find this as a bug in the Apple Mac side
of things. But that is just my experience. I would go to the Apple
Mac side of things and open a discussion there about the problem.

However if you want to open a discussion with the binutils project
people then I would go to their project page. I would see that they
list several resources for these things.

https://www.gnu.org/software/binutils/

Bug reports
There is a bug-tracking system at http://sourceware.org/bugzilla/.

Mailing lists
There are three binutils mailing lists:

bug-bi...@gnu.org
For reporting bugs.

binu...@sourceware.org
For discussing binutils issues.

I would start by discussion. Therefore I would send a mail message to
their sourceware address. That is where the documentation is
directing people to go for discussion. That is the place to start. I
think it is unlikely to be a bug in binutils.

When doing this I would find the version of the software on your
system by running the utility with the --version option as I did
above. Report that version information.

$ objdump --version

Good luck!
Bob

[Arjan van Vught]

Fyi

https://sourceware.org/bugzilla/show_bug.cgi?id=24708 <https://sourceware.org/bugzilla/show_bug.cgi?id=24708>

https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7e56c51c7932cfdb178e9457011d09d53e98937b <https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7e56c51c7932cfdb178e9457011d09d53e98937b>

- Arjan
http://www.orangepi-dmx.org