Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1562522

Summary: build of urbackup-server build ends with compiler segfault
Product: [Fedora] Fedora Reporter: Eric Sandeen <esandeen>
Component: gccAssignee: Jakub Jelinek <jakub>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 28CC: aoliva, davejohansen, dmalcolm, esandeen, fweimer, jakub, jwakely, law, mpolacek, msebor, nickc, pbrobinson
Target Milestone: ---   
Target Release: ---   
Hardware: aarch64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-06 16:14:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 245418    
Attachments:
Description Flags
tarball of /tmp/cc*.out files none

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

Building this RPM:

https://download.opensuse.org/repositories/home:/uroni/Fedora_Rawhide/src/urbackup-server-2.2.8.2142-1.20.src.rpm

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


# rpm -q gcc
gcc-8.0.1-0.20.fc28.aarch64

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)