Segmentation fault on Serial.begin() #486

UsoHolger · 2017-03-11T15:45:24Z

I am using Arch Linux and everything seemed to work fine. However: When I try to use serial communication I get
lto1: internal compiler error: Segmentation fault
as soon as Serial.begin(9600); is uncommented. The same code works fine when compiling with the Arduino IDE.

The makefile:

ARDUINO_DIR = /usr/share/arduino
MONITOR_PORT = /dev/ttyACM0
BOARD_TAG = uno
ARDUINO_LIBS = SoftwareSerial
include	/usr/share/arduino/Arduino.mk

Arduino.mk Configuration:

- [AUTODETECTED]       CURRENT_OS = LINUX 
- [USER]               ARDUINO_DIR = /usr/share/arduino 
- [COMPUTED]           ARDMK_DIR = /usr/share/arduino (relative to Common.mk)
- [AUTODETECTED]       ARDUINO_VERSION = 180 
- [DEFAULT]            ARCHITECTURE = avr 
- [DEFAULT]            ARDMK_VENDOR = arduino 
- [AUTODETECTED]       ARDUINO_PREFERENCES_PATH = /home/uso/.arduino15/preferences.txt 
- [AUTODETECTED]       ARDUINO_SKETCHBOOK = /home/uso/Arduino (from arduino preferences file)
- [AUTODETECTED]       AVR_TOOLS_DIR = /usr (found in $PATH)
- [COMPUTED]           ARDUINO_LIB_PATH = /usr/share/arduino/libraries (from ARDUINO_DIR)
- [COMPUTED]           ARDUINO_PLATFORM_LIB_PATH = /usr/share/arduino/hardware/arduino/avr/libraries (from ARDUINO_DIR)
- [COMPUTED]           ARDUINO_VAR_PATH = /usr/share/arduino/hardware/arduino/avr/variants (from ARDUINO_DIR)
- [COMPUTED]           BOARDS_TXT = /usr/share/arduino/hardware/arduino/avr/boards.txt (from ARDUINO_DIR)
- [DEFAULT]            USER_LIB_PATH = /home/uso/Arduino/libraries (in user sketchbook)
- [DEFAULT]            PRE_BUILD_HOOK = pre-build-hook.sh 
- [USER]               BOARD_TAG = uno 
- [COMPUTED]           CORE = arduino (from build.core)
- [COMPUTED]           VARIANT = standard (from build.variant)
- [COMPUTED]           OBJDIR = build-uno (from BOARD_TAG)
- [COMPUTED]           ARDUINO_CORE_PATH = /usr/share/arduino/hardware/arduino/avr/cores/arduino (from ARDUINO_DIR, BOARD_TAG and boards.txt)
- [DETECTED]           MONITOR_BAUDRATE = 9600  (in sketch)
- [DEFAULT]            OPTIMIZATION_LEVEL = s 
- [DEFAULT]            MCU_FLAG_NAME = mmcu 
- [DEFAULT]            CFLAGS_STD = -std=gnu11 -flto -fno-fat-lto-objects 
- [DEFAULT]            CXXFLAGS_STD = -std=gnu++11 -fno-threadsafe-statics -flto 
- [COMPUTED]           DEVICE_PATH = /dev/ttyACM0 (from MONITOR_PORT)
- [DEFAULT]            FORCE_MONITOR_PORT =  
- [AUTODETECTED]       Size utility: AVR-aware for enhanced output
-
-                      ARDUINO_LIBS =
- [PLATFORM]             SoftwareSerial
- [COMPUTED]           BOOTLOADER_PARENT = /usr/share/arduino/hardware/arduino/avr/bootloaders (from ARDUINO_DIR)
- [COMPUTED]           ARDMK_VERSION = 1.5 
- [COMPUTED]           CC_VERSION = 6.3.0 (avr-gcc)

Part of the code that leads to the error:

void setup()
{
    // Init serial data transmission
    Serial.begin(9600);  // If this line is not in here everything works perfectly

    for ( int i = 0; i < NUM_LEDS ; i++ ) // Init the LEDs
        pinMode(LED[i], OUTPUT);

    // Init the buttons
    pinMode(LBUTTON, INPUT);
    pinMode(RBUTTON, INPUT);
    //Serial.print("Initialized");
}

The text was updated successfully, but these errors were encountered:

sej7278 · 2017-03-11T17:34:38Z

the arch package seems seriously broken its been noticed before, use git

UsoHolger · 2017-03-11T21:25:13Z

Thanks for the reply but that does not resolve the issue. I completely removed the AUR packages and cloned the git repo. The most simplistic case is provided by the "SerialPrint" example in the example folder of the repo. It produces the exact same error while other examples like the "Blink" example compile without any problems:

-------------------------
Arduino.mk Configuration:
- [AUTODETECTED]       CURRENT_OS = LINUX 
- [AUTODETECTED]       ARDUINO_DIR = /usr/share/arduino 
- [COMPUTED]           ARDMK_DIR = /home/uso/arduino/Arduino-Makefile (relative to Common.mk)
- [AUTODETECTED]       ARDUINO_VERSION = 180 
- [DEFAULT]            ARCHITECTURE = avr 
- [DEFAULT]            ARDMK_VENDOR = arduino 
- [AUTODETECTED]       ARDUINO_PREFERENCES_PATH = /home/uso/.arduino15/preferences.txt 
- [AUTODETECTED]       ARDUINO_SKETCHBOOK = /home/uso/Arduino (from arduino preferences file)
- [AUTODETECTED]       AVR_TOOLS_DIR = /usr (found in $PATH)
- [COMPUTED]           ARDUINO_LIB_PATH = /usr/share/arduino/libraries (from ARDUINO_DIR)
- [COMPUTED]           ARDUINO_PLATFORM_LIB_PATH = /usr/share/arduino/hardware/arduino/avr/libraries (from ARDUINO_DIR)
- [COMPUTED]           ARDUINO_VAR_PATH = /usr/share/arduino/hardware/arduino/avr/variants (from ARDUINO_DIR)
- [COMPUTED]           BOARDS_TXT = /usr/share/arduino/hardware/arduino/avr/boards.txt (from ARDUINO_DIR)
- [DEFAULT]            USER_LIB_PATH = /home/alex/Arduino/libraries (in user sketchbook)
- [DEFAULT]            PRE_BUILD_HOOK = pre-build-hook.sh 
- [USER]               BOARD_TAG = uno 
- [COMPUTED]           CORE = arduino (from build.core)
- [COMPUTED]           VARIANT = standard (from build.variant)
- [COMPUTED]           OBJDIR = build-uno (from BOARD_TAG)
- [COMPUTED]           ARDUINO_CORE_PATH = /usr/share/arduino/hardware/arduino/avr/cores/arduino (from ARDUINO_DIR, BOARD_TAG and boards.txt)
- [DETECTED]           MONITOR_BAUDRATE = 9600  (in sketch)
- [DEFAULT]            OPTIMIZATION_LEVEL = s 
- [DEFAULT]            MCU_FLAG_NAME = mmcu 
- [DEFAULT]            CFLAGS_STD = -std=gnu11 -flto -fno-fat-lto-objects 
- [DEFAULT]            CXXFLAGS_STD = -std=gnu++11 -fno-threadsafe-statics -flto 
- [AUTODETECTED]       DEVICE_PATH = /dev/ttyACM0 
- [DEFAULT]            FORCE_MONITOR_PORT =  
- [AUTODETECTED]       Size utility: AVR-aware for enhanced output
- [COMPUTED]           BOOTLOADER_PARENT = /usr/share/arduino/hardware/arduino/avr/bootloaders (from ARDUINO_DIR)
- [COMPUTED]           ARDMK_VERSION = 1.5 
- [COMPUTED]           CC_VERSION = 6.3.0 (avr-gcc)
-------------------------
mkdir -p build-uno
/usr/bin/avr-gcc -mmcu=atmega328p -Wl,--gc-sections -Os -flto -fuse-linker-plugin -o build-uno/SerialPrint.elf build-uno/SerialPrint.ino.o build-uno/libcore.a   -lc -lm 
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: /usr/bin/avr-gcc returned 1 exit status
compilation terminated.
/usr/bin/avr-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [../../Arduino.mk:1442: build-uno/SerialPrint.elf] Error 1

(That is of course the output of a second make without all the successfull preceeding steps)

Edit:
I could resolve the issue by using the Linux makefile from Bare-Arduino-Project, which sets a lot more settings locally. I do not know which one exactly resovled the issue and sadly do not have the time to investigate this further right now.

sej7278 · 2017-03-12T22:06:39Z

probably as you're using avr-gcc 6.3 instead of 4.9, seems like something to do with LTO support (which BAP doesn't have).

ladislas · 2017-03-12T23:15:53Z

@UsoHolger how did you install your version of avr-gcc?

UsoHolger · 2017-03-13T12:30:53Z

I am using the avr-gcc package from the official Arch software repository installed via Pacman.

ladislas · 2017-03-13T12:43:56Z

well I guess the best way would be to comment the different variables used in bare arduino project and let us know what causes the bug.

UsoHolger · 2017-03-13T12:59:49Z

I tested using the simplistic SerialPrint example. What does the trick is setting the 2011 standard flag. So this makefile

BOARD_TAG    	  = uno

include ../../Arduino.mk

fails with the segmentation fault error while adding the line CXXFLAGS_STD = -std=gnu++11 leads to successful compilation.

ladislas · 2017-03-13T13:11:06Z

can i see your code?

UsoHolger · 2017-03-13T13:16:34Z

I used the SerialPrint example. So the code is:

void setup() {
	Serial.begin(9600);
	Serial.print("Press any key: ");
}

void loop() {
	if (Serial.available()) {
		Serial.println(Serial.read());
	}
}

with the makefile

# Arduino Make file. Refer to https://github.com/sudar/Arduino-Makefile

BOARD_TAG    	  = uno
CXXFLAGS_STD      = -std=gnu++11 # if this is missing compilation fails because of the segmentation fault error

include ../../Arduino.mk

sej7278 · 2017-03-13T13:55:02Z

its the LTO parts of CXXFLAGS_STD/CFLAGS_STD, changing them from -std=gnu11 -flto -fno-fat-lto-objects to anything else e.g. -std=gnu11 removes the LTO flags

https://github.com/sudar/Arduino-Makefile/blob/master/arduino-mk-vars.md#cflags_std

i assume your avr-gcc hasn't been built with LTO support

ladislas · 2017-04-25T08:46:03Z

Yes, that's an issue with AVR. We are currently investigating the homebrew formula. I'll keep you posted.

NVieville · 2017-07-21T13:40:18Z

Hello,

Just hitting this issue too, and google led me here. As suggested in osx-cross/homebrew-avr#46 (linked above), I can confirm adding:

CFLAGS_STD = -std=gnu11 -flto -fno-fat-lto-objects
CXXFLAGS_STD = -std=gnu++11 -fno-threadsafe-statics -flto -fno-devirtualize

to Makefile

just make arduino-mk (freshly checked-out from github) compiling without segfault on Fedora 26 x86_64 with:

/usr/bin/avr-gcc --version
avr-gcc (Fedora 6.3.0-1.fc26) 6.3.0
/usr/bin/avr-gcc-ar --version
GNU ar (GNU Binutils) 2.27

Hope this will be helpful.

Cordially,

--
NVieville

sej7278 · 2017-07-21T14:25:41Z

@NVieville i'm a bit confused as these are set by default now in Arduino.mk

grep gnu.*11 Arduino.mk 
        CFLAGS_STD      = -std=gnu11 -flto -fno-fat-lto-objects
        CXXFLAGS_STD      = -std=gnu++11 -fno-threadsafe-statics -flto

Removing LTO flags fixes things for > 4.9.0 compilers that don't have LTO support, but i'd have thought the f26 compilers do (otherwise report it as a bug as they also package IDE 1.6 which kind of requires it, although f26 is on 1.6.6 not 1.6.10 where LTO was added), what's the problem you're having?

what does -fno-devirtualize do? looks like its a bad thing to set (hacky workaround for a gcc 4.9 bug).

NVieville · 2017-07-21T15:07:20Z

Hello,

@sej7278 Thanks for your response, and sorry for not being quite explicit.
I saw that CFLAGS_STD and CXXFLAGS_STD were set in Arduino-mk, but my project wasn't compiling on Fedora 26 (lto1: internal compiler error: Segmentation fault). So, after reading this thread and the one cited above, I wanted to had -fno-devirtualize to CXXFLAGS_STD. The only way I found was to re-define it in my Makefile. Maybe I shouldn't have do it for CFLAGS_STD too, it's unnecessary (I removed it now and only kept CXXFLAGS_STD).

I just tried your suggestion to remove the -flto flag, and compiling goes well. I just noticed that AVR Memory Usage information displayed at the end of the building process is a bit higher when removing the -flto flag than with keeping it and adding the -fno-devirtualize one.

For information here is the output of the "avr-gcc -v" command on Fedora 26:

Using built-in specs.
Reading specs from /usr/lib/gcc/avr/6.3.0/device-specs/specs-avr2
COLLECT_GCC=/usr/bin/avr-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/6.3.0/lto-wrapper
Target: avr
Configured with: ../gcc-6.3.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --with-system-zlib --enable-version-specific-runtime-libs --with-pkgversion='Fedora 6.3.0-1.fc26' --with-bugurl=https://bugzilla.redhat.com/
Thread model: single
gcc version 6.3.0 (Fedora 6.3.0-1.fc26)

My knowledge about this is not enough to say if it's worth removing -flto flag (no link time optimization) or keeping it and adding -fno-devirtualize one in such a configuration.

Sorry again for not being quite explicit in my first message.
Cordially,

--
NVieville

sej7278 · 2017-07-21T18:04:14Z

how odd!

so if adding the -fno-devirtualize flag prevents it from segfaulting, then i assume avr-gcc has LTO support, but perhaps the regular gcc used to compile it has the bug mentioned here that was in gcc 4.9 - maybe try gcc -v?

you should just be able to add this to your local Makefile:

CXXFLAGS_STD += -fno-devirtualize

NVieville · 2017-07-21T19:05:56Z

Tha actual version of gcc in Fedora 26 is: gcc (GCC) 7.1.1 20170622 (Red Hat 7.1.1-3)
Output of gcc -v:

Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.1.1 20170622 (Red Hat 7.1.1-3) (GCC)

I tried your suggestion: adding CXXFLAGS_STD += -fno-devirtualize to my Makefile, but as Arduino.mk is included at the end of this Makefile, the += only defines the CXXFLAGS_STD variable with -fno-devirtualize and doesn't append the parameter to the variable (not already defined) that is seen later in Arduino.mk as user defined and then taken as is and not modified.
The only solution (fine to me) is to define entirely the CXXFLAGS_STD variable in my local Makefile with the same parameters as the ones used in Arduino.mk, but appending -fno-devirtualize at the end.

Thanks for your explanations.
Cordially,

--
NVieville

sej7278 · 2017-07-21T19:42:14Z

sorry, should be CXXFLAGS, this works for me:

BOARD_TAG = leonardo
MONITOR_PORT = /dev/ttyACM0
CXXFLAGS += -fno-devirtualize
include /usr/share/arduino/Arduino.mk

not sure if any other flags need to be changed like CFLAGS or ASFLAGS.

i'd say maybe we ought to add -fno-devirtualize to Arduino.mk but it seems to affect performance and is only a workaround for a gcc bug (on fedora) and it won't fix the arch/osx issue of having avr-gcc 6.3 without LTO support.

maybe we should move from querying the avr-gcc version:

    ifeq ($(shell expr $(CC_VERNUM) '>' 490), 1)

to looking for LTO support instead:

avr-gcc -v | grep COLLECT_LTO_WRAPPER

i can't remember if we added the version check just for LTO or if it was for g++11 also.

…s could impact performance we should track when the issue is fixed upstream to remove the flag again (see links from Issue sudar#486) Enabled colourised diagnostics from avr-gcc We forgot to increase ARDMK_VERSION for the 1.6.0 release

sej7278 · 2017-07-21T20:33:02Z

I made PR #510 which adds -fno-devirtualize to CXXFLAGS_STD whilst we wait for gcc to fix their compiler bug (good luck with that if it was discovered in 6.3 and not fixed in 7.1.....)

Fedora 26 RPM i made here

@ladislas do you have any input on this, you seem to be tracking the issue elsewhere?

NVieville · 2017-07-22T09:36:05Z

@sej7278 Thank you.
I confirm that adding CXXFLAGS += -fno-devirtualize to Arduino.mk works on Fedora 26.

About the gcc bug, it seems it has already been reported:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80717

and workaround different than this proposed here is available:

https://bbs.archlinux.org/viewtopic.php?pid=1722955#p1722955

Haven't tested it. Workaround proposed here seems fine to me.

Cordially,

--
NVieville

sej7278 · 2017-07-22T16:25:56Z

@NVieville we're already using avr-gcc-ar when we have avr-gcc > 4.9 (when LTO is enabled) i don't believe avr-ar will work with LTO at all, so can't be a workaround for this issue. thanks for testing my workaround.

seems the archlinux guys have reverted a commit in avr-gcc 7.1.0-2 which the fedora guys haven't in 7.1.1-3 meaning that its still going to bite most users of avr-gcc >= 6.3 (luckily debian's still on 4.9.2 😏) as upstream haven't fixed it.

@sudar / @ladislas any objections to merging my PR to workaround this?

sudar · 2017-07-25T03:47:22Z

@sej7278 No objections for merging the PR.

RicoWarner · 2019-05-28T17:26:09Z

Hi All - Have a simple Arduino Uno project. Have a simple project that does use the following line and does generate the segmentation fault error as identified in this thread:
Serial.begin(9600);

However, I do not have a makefile system installed and do not have the brain cells nor time to figure out the 5 pages of instructions on the referenced github page for making it work. Wondering if there is a way to set/unset the necessary flags via environment variables inside the program rather than through makefile?

Any simple fix without becoming Arduino compiler guru? Just have a few lines of code to run....

Thanks!

RicoWarner · 2019-05-28T17:39:15Z

Hi All - Have a simple Arduino Uno project. Have a simple project that does use the following line and does generate the segmentation fault error as identified in this thread:
Serial.begin(9600);

However, I do not have a makefile system installed and do not have the brain cells nor time to figure out the 5 pages of instructions on the referenced github page for making it work. Wondering if there is a way to set/unset the necessary flags via environment variables inside the program rather than through makefile?

Any simple fix without becoming Arduino compiler guru? Just have a few lines of code to run....

Thanks!

Hmmm maybe found fix? Included SoftwareSerial.h and it appears to be compiling.

sej7278 added the not-a-bug label Apr 13, 2017

tuna-f1sh mentioned this issue Apr 25, 2017

Link Time Optimisation 6.2.0 osx-cross/homebrew-avr#46

Closed

sej7278 mentioned this issue Jul 21, 2017

Add -fno-devirtualize to CXXFLAGS_STD #510

Merged

freespace mentioned this issue Aug 30, 2017

LTO causes internal compiler error platformio/platform-atmelavr#65

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Segmentation fault on Serial.begin() #486

Segmentation fault on Serial.begin() #486

UsoHolger commented Mar 11, 2017 •

edited

Loading

sej7278 commented Mar 11, 2017

UsoHolger commented Mar 11, 2017 •

edited

Loading

sej7278 commented Mar 12, 2017 •

edited

Loading

ladislas commented Mar 12, 2017

UsoHolger commented Mar 13, 2017 •

edited

Loading

ladislas commented Mar 13, 2017

UsoHolger commented Mar 13, 2017

ladislas commented Mar 13, 2017

UsoHolger commented Mar 13, 2017 •

edited

Loading

sej7278 commented Mar 13, 2017

ladislas commented Apr 25, 2017 •

edited

Loading

NVieville commented Jul 21, 2017 •

edited

Loading

sej7278 commented Jul 21, 2017 •

edited

Loading

NVieville commented Jul 21, 2017

sej7278 commented Jul 21, 2017

NVieville commented Jul 21, 2017

sej7278 commented Jul 21, 2017 •

edited

Loading

sej7278 commented Jul 21, 2017 •

edited

Loading

NVieville commented Jul 22, 2017

sej7278 commented Jul 22, 2017 •

edited

Loading

sudar commented Jul 25, 2017

RicoWarner commented May 28, 2019

RicoWarner commented May 28, 2019

Segmentation fault on Serial.begin() #486

Segmentation fault on Serial.begin() #486

Comments

UsoHolger commented Mar 11, 2017 • edited Loading

sej7278 commented Mar 11, 2017

UsoHolger commented Mar 11, 2017 • edited Loading

sej7278 commented Mar 12, 2017 • edited Loading

ladislas commented Mar 12, 2017

UsoHolger commented Mar 13, 2017 • edited Loading

ladislas commented Mar 13, 2017

UsoHolger commented Mar 13, 2017

ladislas commented Mar 13, 2017

UsoHolger commented Mar 13, 2017 • edited Loading

sej7278 commented Mar 13, 2017

ladislas commented Apr 25, 2017 • edited Loading

NVieville commented Jul 21, 2017 • edited Loading

sej7278 commented Jul 21, 2017 • edited Loading

NVieville commented Jul 21, 2017

sej7278 commented Jul 21, 2017

NVieville commented Jul 21, 2017

sej7278 commented Jul 21, 2017 • edited Loading

sej7278 commented Jul 21, 2017 • edited Loading

NVieville commented Jul 22, 2017

sej7278 commented Jul 22, 2017 • edited Loading

sudar commented Jul 25, 2017

RicoWarner commented May 28, 2019

RicoWarner commented May 28, 2019

UsoHolger commented Mar 11, 2017 •

edited

Loading

UsoHolger commented Mar 11, 2017 •

edited

Loading

sej7278 commented Mar 12, 2017 •

edited

Loading

UsoHolger commented Mar 13, 2017 •

edited

Loading

UsoHolger commented Mar 13, 2017 •

edited

Loading

ladislas commented Apr 25, 2017 •

edited

Loading

NVieville commented Jul 21, 2017 •

edited

Loading

sej7278 commented Jul 21, 2017 •

edited

Loading

sej7278 commented Jul 21, 2017 •

edited

Loading

sej7278 commented Jul 21, 2017 •

edited

Loading

sej7278 commented Jul 22, 2017 •

edited

Loading