Bug 1562522 - build of urbackup-server build ends with compiler segfault
Summary: build of urbackup-server build ends with compiler segfault
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: 28
Hardware: aarch64
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2018-03-31 15:52 UTC by Eric Sandeen
Modified: 2018-05-06 18:11 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-05-06 16:14:25 UTC

Attachments (Terms of Use)
tarball of /tmp/cc*.out files (42.73 KB, application/x-bzip)
2018-03-31 15:52 UTC, Eric Sandeen
no flags Details

Description Eric Sandeen 2018-03-31 15:52:52 UTC
Created attachment 1415553 [details]
tarball of /tmp/cc*.out files

Building this RPM:


on an aarch64/F28/rpi3+ yielded the same segfault both times I tried to build it.

# rpm -q gcc

I think I have properly collected the cc*.out files, attached.  If not please let me know.

gcc -DHAVE_CONFIG_H -I.    -I/usr/include/fuse -D_FILE_OFFSET_BITS=64  -fstack-protector-strong --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIE -DSQLITE_PREPARE_RETRIES=5 -DNDEBUG  -I/usr/include -I/usr/include -DSQLITE_ENABLE_UNLOCK_NOTIFY -DSQLITE_MAX_MMAP_SIZE=0x10000000000LL  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1  -fasynchronous-unwind-tables -fstack-clash-protection -c -o sqlite/urbackupsrv-sqlite3.o `test -f 'sqlite/sqlite3.c' || echo './'`sqlite/sqlite3.c
during RTL pass: loop2_invariant
sqlite/sqlite3.c: In function 'sqlite3_db_status':
sqlite/sqlite3.c:18823:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.

The bug is not reproducible, so it is likely a hardware or OS problem.

Comment 1 Dave Malcolm 2018-04-11 15:45:30 UTC
(In reply to Eric Sandeen from comment #0)
> Created attachment 1415553 [details]
> tarball of /tmp/cc*.out files


> I think I have properly collected the cc*.out files, attached.  If not
> please let me know.

The tarball contains four cc*.out files, but all of them appear to be assembler output from the compiler, rather than preprocessed source:

$ file *.out
cc9JKo0B.out: assembler source text
ccHlnTun.out: assembler source text
ccHNiapn.out: assembler source text
ccOfGKVj.out: assembler source text

FWIW, two of them are duplicates of each other:

$ md5sum *.out
a906efbb37c107b7ef2bcc90989bf74c  cc9JKo0B.out
b1ba9f4eb445724fb760475b23ccbdd2  ccHlnTun.out
243da8176c8dee0dd2e4bc945ee74926  ccHNiapn.out
b1ba9f4eb445724fb760475b23ccbdd2  ccOfGKVj.out

Are you able to reproduce the ICE and capture the preprocessed source?

Comment 2 Eric Sandeen 2018-05-06 16:14:25 UTC
Sorry for the delay on this; i'll close for now and re-open if I can gather more info, this may be a side effect of other arch issues.

Comment 3 Peter Robinson 2018-05-06 18:11:12 UTC
Eric: could you try the gcc 8.1.1-1.fc28 build (dnf upgrade --enablerepo=updates-testing) as this seems quite like rhbz 1570571 where we were having similar issues building kernels (I think it might be the same issue) and a user there reported it was fixed (I'm testing myself now)

Note You need to log in before you can comment on or make changes to this bug.