help-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Arjan van Vught
Subject: Re: arm-none-eabi-objdump: Reading section .bss failed because: memory exhausted
Date: Tue, 7 Apr 2020 18:06:51 +0200


> Op 7 apr. 2020, om 02:41 heeft Bob Proulx <bob@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]