Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Arjan van Vught <arjan.van.vught@gmail.com>
Newsgroups: gnu.utils.help
Subject: Re: arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted
Date: Tue, 7 Apr 2020 18:06:51 +0200
Lines: 106
Approved: help-gnu-utils@gnu.org
Message-ID: <mailman.314.1586275622.2644.help-gnu-utils@gnu.org>
References: <58616427-9DBC-4DF7-AF74-6EAA6844492B@gmail.com> <20200406183213536211500@bob.proulx.com> <3179994E-5E74-48D5-9120-0A1AC5D4FBA1@gmail.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: help-gnu-utils@gnu.org
To: Bob Proulx <bob@proulx.com>
Envelope-to: help-gnu-utils@gnu.org
In-Reply-To: <20200406183213536211500@bob.proulx.com>
Precedence: list
Xref: csiph.com gnu.utils.help:322



> Op 7 apr. 2020, om 02:41 heeft Bob Proulx <bob@proulx.com> het =
volgende geschreven:
>=20
> 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.

>=20
> 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.
>=20
> 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
>=20
>> 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)
>=20
> 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.
>=20
>  int iii =3D 42;
>=20
> 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 $?                               =
                                           =20
0

arjanvanvught@MacBook-Air lib-h3 % ls -al build_h3/src/h3_codec.o        =
                                           =20
-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?=20

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.=20

>=20
> Reference:
>=20
>  https://en.wikipedia.org/wiki/.bss
>=20
>> arm-none-eabi-objdump: Reading section .bss failed because: memory =
exhausted
>=20
> 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.
>=20
> I would look to see if the storage filled up.  I would look to see if
> whatever you are doing ran out of memory.
>=20
> 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?=20

Thanks, Arjan

>=20
> Bob