port-i386/50553: gcc (g++) failure on pkgsrc/x11/wxGTK30

[Manuel.Bouyer%lip6.fr@localhost]

>Number:         50553
>Category:       port-i386
>Synopsis:       gcc (g++) failure on pkgsrc/x11/wxGTK30
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 14 13:10:00 +0000 2015
>Originator:     Manuel Bouyer
>Release:        NetBSD 7.0_STABLE
>Organization:
>Environment:
Build information:
          Build date Sat Dec 12 02:42:15 UTC 2015
	  Built by   builds%b41.netbsd.org@localhost
	  Build ID   201512120030Z
Architecture: i386
Machine: i386
>Description:
	Building pkgsrc/x11/wxGTK30 on i386/7.0, cc1plus loops forever in
	kernel mode (as shown by top: 100% CPU in system). a ktrace shows that
	the last syscalls before the loop are:
  3344      1 cc1plus  1450096724.461796811 RET   mmap -1321205760/0xb1400000
  3344      1 cc1plus  1450096724.487412469 CALL  mmap(0,0x100000,3,0x14001002,0
xffffffff,0,0,0)
  3344      1 cc1plus  1450096724.487430070 RET   mmap -1322254336/0xb1300000
  3344      1 cc1plus  1450096724.520984095 CALL  mmap(0,0x100000,3,0x14001002,0
xffffffff,0,0,0)
  3344      1 cc1plus  1450096724.521001696 RET   mmap -1323302912/0xb1200000
  3344      1 cc1plus  1450096724.620029445 CALL  mmap(0xb0000000,0x4153000,3,0x
12,4,0,0,0)
  3344      1 cc1plus  1450096724.628955674 RET   mmap -1342177280/0xb0000000
  3344      1 cc1plus  1450096724.628979979 CALL  munmap(0xb0000000,0x4153000)
  3344      1 cc1plus  1450096724.628993389 RET   munmap 0
  3344      1 cc1plus  1450096724.629007916 CALL  mmap(0,0x500000,3,0x14001002,0
xffffffff,0,0,0)
  3344      1 cc1plus  1450096724.629019371 RET   mmap -1279262720/0xb3c00000
  3344      1 cc1plus  1450096724.629043397 PSIG  SIGSEGV caught handler=0x82af0
99 mask=(11): code=SEGV_MAPERR, addr=0xb1900000, trap=6)
  3344      1 cc1plus  1450096724.629054851 CALL  __sigaction_sigtramp(SIGSEGV,0
xbfbfc81c,0xbfbfc834,0xbb9c8030,2)
  3344      1 cc1plus  1450096724.629065188 RET   __sigaction_sigtramp 0
  3344      1 cc1plus  1450096724.629140339 CALL  issetugid
  3344      1 cc1plus  1450096724.629148999 RET   issetugid 0
  3344      1 cc1plus  1450096724.629195096 CALL  open(0xbfbfbb74,0x400000,0xbfbfbacc)
  3344      1 cc1plus  1450096724.629211299 NAMI  "/usr/share/nls/nls.alias.db"
  3344      1 cc1plus  1450096724.629240633 RET   open -1 errno 2 No such file or directory
  3344      1 cc1plus  1450096724.629250411 CALL  open(0xbba4bdf2,0x400000,0xbbad3c00)
  3344      1 cc1plus  1450096724.629260190 NAMI  "/usr/share/nls/nls.alias"
  3344      1 cc1plus  1450096724.629277790 RET   open 5
  3344      1 cc1plus  1450096724.629287289 CALL  __fstat50(5,0xbfbfbf00)
  3344      1 cc1plus  1450096724.629298743 RET   __fstat50 0
  3344      1 cc1plus  1450096724.629307683 CALL  mmap(0,0x5f0,1,2,5,0,0,0)
  3344      1 cc1plus  1450096724.629321093 RET   mmap -1148190720/0xbb900000
  3344      1 cc1plus  1450096724.629334782 CALL  close(5)
  3344      1 cc1plus  1450096724.629345398 RET   close 0
  3344      1 cc1plus  1450096724.629408536 CALL  munmap(0xbb900000,0x5f0)
  3344      1 cc1plus  1450096724.629426416 RET   munmap 0
  3344      1 cc1plus  1450096724.629436753 CALL  open(0xbfbfc3f3,0,0xbb9585d0)
  3344      1 cc1plus  1450096724.629446531 NAMI  "/usr/share/nls/C/libc.cat"
  3344      1 cc1plus  1450096724.629464131 RET   open 5
  3344      1 cc1plus  1450096724.629472792 CALL  __fstat50(5,0xbfbfbf44)
  3344      1 cc1plus  1450096724.629482849 RET   __fstat50 0
  3344      1 cc1plus  1450096724.629492348 CALL  mmap(0,0x10be,1,1,5,0,0,0)
  3344      1 cc1plus  1450096724.629505199 RET   mmap -1236049920/0xb6536000
  3344      1 cc1plus  1450096724.629514139 CALL  close(5)
  3344      1 cc1plus  1450096724.629523917 RET   close 0
  3344      1 cc1plus  1450096724.629564426 CALL  munmap(0xb6536000,0x10be)
  3344      1 cc1plus  1450096724.629579792 RET   munmap 0
  [hang at 100% CPU in system]

  [notice the SEGV in the trace, caught by a signal handler ]

  ddb trace for the looping process shows 
db{0}>  mach cpu 2               
using CPU 2
db{0}> tr
hypercall_page(0,0,c224ae10,da79bf60,103,0,da79be9c,c0248862,c1af7e00,2) at netb
sd:hypercall_page+0x227
pool_cache_get_paddr(c1af7e00,2,0,c29dfa34,0,da79bedc,c02494d8,c29dfa34,da79bf60
,2) at netbsd:pool_cache_get_paddr+0x60
ksiginfo_alloc(c29dfa34,da79bf60,2,c04141bd,0,1,79beec,b,0,c05278c2) at netbsd:k
siginfo_alloc+0x42
kpsignal2(c29dfa34,da79bf60,da79bf0c,c0235c64,c2a208c0,c2a07110,b,c290f000,106,d
a79bf90) at netbsd:kpsignal2+0x458
trapsignal(c290f000,da79bf60,1,0,9,da79bf90,da79bf94,da79bf6c,0,da79bfa8) at net
bsd:trapsignal+0x96
trap() at netbsd:trap+0x7e7
--- trap (number 6) ---
bb5de308:

(this is on a Xen guest, but I get the exact same behavior on bare metal).

I tried building with -O0 or -O1 but this doesn't change anything.


>How-To-Repeat:
	cd pkgsrc/x11/wxGTK30 && make
>Fix:
	no workaround found