[GCC 7.2.0] -Ofast causes segfault

[solskogen]

On ArchLinux ARM (at least) if -Ofast is used, amiberry will segfault. Changing that to -O2 makes the problem go away.

gcc/g++ is version 7.2.0. (I tried using sdl1-branch)

[solskogen]

This is what gdb tells me:
solskogen@alarmpi amiberry]$ gdb ./amiberry
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7l-unknown-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./amiberry...done.
(gdb) run
Starting program: /home/solskogen/amiberry/amiberry
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Amiberry v2.5, by Dimitris (MiDWaN) Panokostas and TomB

Program received signal SIGSEGV, Segmentation fault.
fixup_prefs (p=p@entry=0x155c3a0 , userconfig=userconfig@entry=true) at src/main.cpp:194
194 if (((p->chipmem_size & (p->chipmem_size - 1)) != 0 && p->chipmem_size != 0x180000)

[midwan]

Strange, I haven't seen this with GCC 6.3 at least (which is what Stretch comes with).
Thanks for reporting it, I'll see if I can recreate it.

[midwan]

@solskogen I tried again today with the current sdl1-dev branch, can't recreate this on Stretch.
I can start the emulator up and boot into environments normally, using the supplied Makefile options.

Maybe it's related to something in the newer version of GCC? Some flag that messes things up?

[solskogen]

Yes, it has probably something to do with GCC (and not Arch Linux as such)

[midwan]

@solskogen Does this still occur with the latest "dev" branch changes?

If so, I'll have to set up an Arch image and test it there, since I can't recreate it under Stretch and the GCC bundled with it.

[solskogen]

Yes, it still do.
I've sent the gcc-help mailing list a mail as well.

[solskogen]

Here's the output from gdb and a clean build (no config files or kickstart files configured)

Thread 1 "amiberry-sdl1-d" received signal SIGSEGV, Segmentation fault.
fixup_prefs (p=0xffff5218, p@entry=0x1a15218 , userconfig=userconfig@entry=true) at src/main.cpp:290
290 if (p->cs_z3autoconfig && p->address_space_24) {

[solskogen]

oh.. Funny development! If I copy kickstart files into kickstart/ and then start amiberry, it works. If I remove then again, it segfaults.

[midwan]

Thanks, that actually helps in investigating this further... Then it's not related to the GCC version at all?

[solskogen]

Well, yes and no.
It's highly likely a bug in the code, and not in the compiler, and somehow a newer gcc triggers that bug, while the older one does not.

[solskogen]

With some help from some extra flags (-fsanitize=bool) I get this from GDB:

Thread 1 "amiberry-sdl1-d" received signal SIGSEGV, Segmentation fault.
fixup_prefs (p=0x1a14318 , userconfig=) at src/main.cpp:197
197 if (((p->chipmem_size & (p->chipmem_size - 1)) != 0 && p->chipmem_size != 0x180000)

[solskogen]

[Thread 0x69dff420 (LWP 19183) exited]

==19180==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7efff87e at pc 0x007d0828 bp 0x7efff764 sp 0x7efff750
WRITE of size 1 at 0x7efff87e thread T0
#0 0x7d0827 in kickstart_fix_checksum(unsigned char*, int) src/rommgr.cpp:1722
#1 0x7b9773 in read_kickstart src/memory.cpp:607
#2 0x7b9773 in read_kickstart_version(uae_prefs*) src/memory.cpp:1151
#3 0x7abd1f in fixup_prefs(uae_prefs*, bool) src/main.cpp:195
#4 0x7abd1f in real_main2 src/main.cpp:678
#5 0x7abd1f in real_main(int, char**) src/main.cpp:784
#6 0x486d3f in main src/osdep/amiberry.cpp:920
#7 0x76232a7f in __libc_start_main (/usr/lib/libc.so.6+0x16a7f)

Address 0x7efff87e is located in stack of thread T0 at offset 158 in frame
#0 0x7b956b in read_kickstart_version(uae_prefs*) src/memory.cpp:1144

This frame has 2 object(s):
[32, 52) 'buffer'
[96, 128) 'mem' <== Memory access at offset 158 overflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions are supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow src/rommgr.cpp:1722 in kickstart_fix_checksum(unsigned char*, int)
Shadow bytes around the buggy address:
0x2fdffeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2fdffec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2fdffed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2fdffee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2fdffef0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x2fdfff00: 00 00 04 f2 f2 f2 f2 f2 00 00 00 00 f3 f3 f3[f3]
0x2fdfff10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2fdfff20: 00 00 00 00 f1 f1 f1 f1 01 f2 f2 f2 00 00 00 00
0x2fdfff30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x2fdfff40: f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00
0x2fdfff50: 00 00 00 00 00 04 f2 f2 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==19180==ABORTING
[Inferior 1 (process 19180) exited with code 01]