gcc ARM options

[hal9K]

Hi,

i am trying to use the command

gcc -mcpu=native -march=native -Q --help=target

on my RasPi 3 with gcc version 4.9.2 (Raspbian 4.9.2-10) and the following message appears:

*** Error in `gcc': double free or corruption (top): 0x01099c18 ***

As far as I know these compiler flags should be supported (gcc >= 4.7). Is this a bug or a feature?

Thanks a lot for your help.

Regards, Timo

[Paeryn]

Looking at the ARM detection code in GCC on github there seems to be a bug. It opens /proc/cpuinfo to read the processor information and closes it after trying to match with known processors. At this point it should set the file pointer to NULL but it doesn't. If it doesn't find a match (for some reason the a53 and a57 aren't listed for aarch32) then it goes to the not_found part which tries to close the file, since the pointer wasn't set to NULL when it was previously closed it attempts a second closing, this is what's causing the error. So at a guess whilst GCC knows about the A53, the native detection code doesn't and the bug rears it's head.

Hmm, looks like a patch was submitted on 10th Feb 2014 to add a53 and a57 to the detection list, but it's not there...
Edit: Bug report posted to gcc bugzilla.

[hal9K]

Thank you very much for your detailed explanation and for posting a bug report.

[dgencare]

Is there any workaround until the fix is available?

[Paeryn]

Only to specify the cpu/arch directly and not use native. The code that gcc uses to determine what native means doesn't recognise the a53 and any cpu it doesn't recognise causes the crash on ARM platforms (rather than the intended ignoring of the switch).

[jahboater]

The usual options for the Pi3 are:-

Code: Select all

-mcpu=cortex-a53 -mfpu=neon-vfpv4 

[jamesh]

Cool - I always wondered why I got that double free warning. I now set the processor type directly.

[ibic]

Hmm, this is quite annoying and I think the fix for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132

has not been merged to debian yet.

[swampdog]

Fwiw, it is a bit wierd. Same (nfs jessie) with same gcc. One works. One bombs.

This works (strace snippet)..

Code: Select all

access("/usr/lib/gcc/arm-linux-gnueabihf/specs", R_OK) = -1 ENOENT (No such file or directory)
open("/proc/cpuinfo", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f4e000
read(3, "processor\t: 0\nmodel name\t: ARMv7"..., 1024) = 1024
close(3)                                = 0
munmap(0x76f4e000, 4096)                = 0
open("/proc/cpuinfo", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f4e000
read(3, "processor\t: 0\nmodel name\t: ARMv7"..., 1024) = 1024
close(3)                                = 0
munmap(0x76f4e000, 4096)                = 0
access("/usr/lib/gcc/arm-linux-gnueabihf/4.9/", X_OK) = 0

This does not..

Code: Select all

access("/usr/lib/gcc/arm-linux-gnueabihf/specs", R_OK) = -1 ENOENT (No such file or directory)
open("/proc/cpuinfo", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f10000
read(3, "processor\t: 0\nmodel name\t: ARMv7"..., 1024) = 1024
close(3)                                = 0
munmap(0x76f10000, 4096)                = 0
open("/dev/tty", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
writev(3, [{"*** Error in `", 14}, {"gcc", 3}, {"': ", 3}, {"double free or corruption (top)", 31}, {": 0x", 4}, {"01961c18", 8}, {" ***\n", 5}], 7) = 68
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x76f10000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()                                = 6700
tgkill(6700, 6700, SIGABRT)             = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=6700, si_uid=1001} ---
+++ killed by SIGABRT +++

The only difference is the hardware (and the mmap address). The working one is an RPI2 whilst the failing one is an RPI3.

[Paeryn]

Fwiw, it is a bit wierd. Same (nfs jessie) with same gcc. One works. One bombs.
<snip>
The only difference is the hardware (and the mmap address). The working one is an RPI2 whilst the failing one is an RPI3.

Are you still trying to use -mcpu=native here? That option doesn't work on the RPi3, at least not until we get a version of gcc with the bug fixed. The code in gcc that checks what native should be replaced with is broken for ARM if the detected processor isn't in it's list of known processors. It tries to close a file that it already closed (/proc/cpuinfo).

The list of processors in the native detection code is not the same as the list of processors that it can compile for. Our version of gcc can happily compile for an A53 if it is told to use that specifically, it's auto-detection code however doesn't know about the A53 (in aarch32 mode).

[swampdog]

Fwiw, it is a bit wierd. Same (nfs jessie) with same gcc. One works. One bombs.
<snip>
The only difference is the hardware (and the mmap address). The working one is an RPI2 whilst the failing one is an RPI3.

Are you still trying to use -mcpu=native here? That option doesn't work on the RPi3, at least not until we get a version of gcc with the bug fixed. The code in gcc that checks what native should be replaced with is broken for ARM if the detected processor isn't in it's list of known processors. It tries to close a file that it already closed (/proc/cpuinfo).

The list of processors in the native detection code is not the same as the list of processors that it can compile for. Our version of gcc can happily compile for an A53 if it is told to use that specifically, it's auto-detection code however doesn't know about the A53 (in aarch32 mode).

Yes I was still using "-mpu=native" there. The wierdness was that the 'strace' doesn't show the double close. Then again I don't use strace that often.

[jahboater]

The "=native" stuff works fine with the latest version of GCC (6.2), I use it on all my Pi's.

[Paeryn]

Yes I was still using "-mpu=native" there. The wierdness was that the 'strace' doesn't show the double close. Then again I don't use strace that often.

strace doesn't show close() a second time because close() never gets called the second time, libc knows that the actual stream has been closed so doesn't need to close it again.

The the last thing fclose() does it to free the FILE structure from the pointer passed to it. Calling it again (especially so soon) the chances are the memory pointed to still holds correct data so fclose() can see that the associated file is already closed, but as far as it is concerned the pointer you passed is valid and it attempts to free it again - that's where free() notices that the pointer has already been freed and aborts.

The "=native" stuff works fine with the latest version of GCC (6.2), I use it on all my Pi's.

It has been fixed, and it has been back-ported to 4.9, but unless rasbpian updates it we won't have it by default.

[swampdog]

Yes I was still using "-mpu=native" there. The wierdness was that the 'strace' doesn't show the double close. Then again I don't use strace that often.

strace doesn't show close() a second time because close() never gets called the second time, libc knows that the actual stream has been closed so doesn't need to close it again.

Ah, right. I've got it now.

[numb]

I have this problem installing motion. Can you help me? I do not know how to use those options for gcc. Thank you

[Paeryn]

I have this problem installing motion. Can you help me? I do not know how to use those options for gcc. Thank you

Where ever the compile commands for motion use -mcpu=native you need to replace with -mcpu=cortex-a53 for an RPi3 specific build (resultant code will probably still work on an RPi2 but not RPi1), or take the option out (or change to -mcpu=arm1176jzf-s) and it will build a version compatible with all RPis.
Similarly where -march=native is you change to -march=armv8-a for RPi3 only or -march=armv6 (or just remove -march=native option) to build for all RPis.

Safest is to remove all -mcpu and -march options, the program will run on any RPi then but if you need performance and know it will only run on an RPi3 then use the RPi3 specific versions.

[debarghaya]

This can be resolved by install GCC 6. Follow these steps :-

Code: Select all

sudo apt-get update
sudo apt-get upgrade

Next, open /etc/apt/sources.list in your favorite editor and repalce jessie with stretch:

Code: Select all

sudo vim /etc/apt/sources.list

Update your package list:

Code: Select all

sudo apt-get update

Install GCC 6

Code: Select all

sudo apt-get install gcc-6 g++-6

Last step is to revert back from Stretch to Jessie, open /etc/apt/sources.list and replace stretch with jessie, after that do an update to refresh the package list:

Code: Select all

sudo vim /etc/apt/sources.list
sudo apt-get update

The above procedure will keep GCC 4.9 as the default C and C++ compiler for any package that depends on it, if you want to compile a program with GCC 6 you will have to use gcc-6 or g++-6 when invoking the compilers.

In GCC 6 the default C++ standard is now -std=gnu++14, which means that by default any C++ program will be treated as a C++14. For C, the default is std=gnu11 starting from GCC 5.

[numb]

I have this problem installing motion. Can you help me? I do not know how to use those options for gcc. Thank you

Where ever the compile commands for motion use -mcpu=native you need to replace with -mcpu=cortex-a53 for an RPi3 specific build (resultant code will probably still work on an RPi2 but not RPi1), or take the option out (or change to -mcpu=arm1176jzf-s) and it will build a version compatible with all RPis.
Similarly where -march=native is you change to -march=armv8-a for RPi3 only or -march=armv6 (or just remove -march=native option) to build for all RPis.

Safest is to remove all -mcpu and -march options, the program will run on any RPi then but if you need performance and know it will only run on an RPi3 then use the RPi3 specific versions.

I did what you suggested changing the Makefile and removing options -march=native -mtune=native in CFLAGS =
Then I get this other error:

track.c:1136:25: error: storage size of ‘control_s’ isn’t known
struct v4l2_control control_s;
^
track.c:1136:25: warning: unused variable ‘control_s’ [-Wunused-variable]
<builtin>: recipe for target 'track.o' failed
make: *** [track.o] Error 1


Any clue? Did I miss something? Should I do something else? Maybe some option after the ./configure command?
Thank you.

[Paeryn]

I did what you suggested changing the Makefile and removing options -march=native -mtune=native in CFLAGS =
Then I get this other error:

track.c:1136:25: error: storage size of ‘control_s’ isn’t known
struct v4l2_control control_s;
^
track.c:1136:25: warning: unused variable ‘control_s’ [-Wunused-variable]
<builtin>: recipe for target 'track.o' failed
make: *** [track.o] Error 1


Any clue? Did I miss something? Should I do something else? Maybe some option after the ./configure command?
Thank you.

That looks like you've got an version of the source-code which doesn't work on the RPi, a quick look found one that looks like it doesn't include the needed header file (possibly the struct used to be defined elsewhere) https://github.com/sackmotion/motion, and a fork with track.c modified to include the current header which defines it https://github.com/Motion-Project/motion. This particular issue is nothing to do with this thread though (which is about the native cpu detection in the stock gcc crashing on the RPi3).

[numb]

thanks again very much.
Sorry but my knowledge of Linux is limited. I cloned the fork with git -clone command. However inside the folder there is no configure or makefile. How can use the fork to install the program? Do I have to merge the two?

[numb]

Forgive me. Just needed to install autoconf ))