wait4() busy endless OR: gcc: Internal error: Trace/BPT trap (program cc1)

2012-03-19 Thread Steffen Daode Nurpmeso
Sorry folks for this shitty report, but i thought it's maybe
better to send it out than not to be able to sleep or so.
I guess it's somehow related to the rthread wait4() path, but of
course i dunno.  Here's what's happened:

As always i did my weekly kernel+userland compilation this noon,
and i was running in an endless loop in wait4() when compiling
insn-attrtab.i (thought preprocessor hung, but it's later).

Note i (yet) use(d) a very primitive compilation approach
- i simply do 'make all', which sometimes requires changes by hand
(e.g. today drop of SO_JUMBO in kdump).  *This* is only a fellow
traveler virtual box, and doing the full rebuild blocks normal
work out some hours longer, so..
I had not yet time to check this on a real box.

Anyway, kernel compilation was successful, and (after reboot) much
of userland (e.g. libC, crypto etc. - one week of work), too.
But then i ran in an endless (busy) wait4() upon compilation of
gnu/usr.bin/cc/cc_int/obj/insn-attrtab:

   68 -rw---  1 steffen  wsrc 68981 Mar 19 16:34 ktrace.out

  1844 gcc  NAMI  /usr/lib/gcc-lib/amd64-unknown-openbsd5.1/4.2.1/cc1
  1844 gcc  RET   access 0
  1844 gcc  CALL  sigprocmask(SIG_BLOCK,~0)
  1844 gcc  RET   sigprocmask 0
  1844 gcc  CALL  mprotect(0x72f000,0x2000,0x3PROT_READ|PROT_WRITE)
  1844 gcc  RET   mprotect 0
  1844 gcc  CALL  mprotect(0x72f000,0x2000,0x1PROT_READ)
  1844 gcc  RET   mprotect 0
  1844 gcc  CALL  sigprocmask(SIG_SETMASK,0)
  1844 gcc  RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
  1844 gcc  CALL  vfork()
  1844 gcc  RET   vfork 24913/0x6151
  1844 gcc  CALL  sigprocmask(SIG_BLOCK,~0)
  1844 gcc  RET   sigprocmask 0
  1844 gcc  CALL  mprotect(0x72f000,0x2000,0x3PROT_READ|PROT_WRITE)
  1844 gcc  RET   mprotect 0
  1844 gcc  CALL  mprotect(0x72f000,0x2000,0x1PROT_READ)  1844 gcc  
RET   mprotect 0
  1844 gcc  CALL  sigprocmask(SIG_SETMASK,0)
  1844 gcc  RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
  1844 gcc  CALL  sigprocmask(SIG_BLOCK,~0)
  1844 gcc  RET   sigprocmask 0
  1844 gcc  CALL  mprotect(0x20c61,0x2000,0x3PROT_READ|PROT_WRITE)
  1844 gcc  RET   mprotect 0
  1844 gcc  CALL  mprotect(0x20c61,0x2000,0x1PROT_READ)
  1844 gcc  RET   mprotect 0
  1844 gcc  CALL  sigprocmask(SIG_SETMASK,0)
  1844 gcc  RET   sigprocmask ~0x10100SIGKILL|SIGSTOP
  1844 gcc  CALL  wait4(0x6151,0x208e980d0,0,0)
 ENDLESS BUSY LOOP, ^C HERE 
  1844 gcc  PSIG  SIGINT caught handler=0x40b210 mask=0
  1844 gcc  RET   wait4 RESTART
  1844 gcc  CALL  sigaction(SIGINT,0x7f7f0e10,0x7f7f0e00)

I've moved the fresh libC to /usr/lib, but that results in the
very same problem.  Ditto last week's kernel.
Puke!  I had to run a debugger :-((:

  (gdb) break vfork
  Breakpoint 1 at 0x401a50
  (gdb) run
  Starting program: /usr/bin/gcc -O2 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=/usr 
-I/home/src/gnu/usr.bin/cc/cc_int/obj/../cc_tools 
-I/home/src/gnu/usr.bin/cc/cc_int/../cc_tools 
-I/home/src/gnu/usr.bin/cc/cc_int/../../../gcc/gcc 
-I/home/src/gnu/usr.bin/cc/cc_int/../../../gcc/gcc/config 
-I/home/src/gnu/usr.bin/cc/cc_int/../../../gcc/include 
-I/home/src/gnu/usr.bin/cc/cc_int/../../../gcc/libcpp/include 
-I/home/src/gnu/usr.bin/cc/cc_int/../../../gcc/libdecnumber -c 
../cc_tools/insn-attrtab.c -o insn-attrtab.o.o
  Breakpoint 1 at 0x2088b0f90

  Breakpoint 1, 0x0002088b0f90 in vfork () from /usr/lib/libc.so.62.0
  (gdb) step
  Single stepping until exit from function vfork, 
  which has no line number information.
  gcc: Internal error: Trace/BPT trap (program cc1)
  Please submit a full bug report.
  See URL:http://gcc.gnu.org/bugs.html for instructions.

  Program exited with code 01.

The old libc.so.62.0 is from monday last week, the new from today.
I'll append a dmesg of this VirtualBox.

Well; unless there is interest in something i'll do a complete
cleanup and recompile tomorrow.
I would report if the problem remains, then.
(I use my own homebrew environment since a decade, and have no
experiences with - spew - debuggers.  Just for info.)

--steffen
Forza Figa!

OpenBSD 5.1-current (GENERIC) #13: Mon Mar 19 12:13:01 CET 2012
sdaoden@obsd.sherwood:/home/src/sys/arch/amd64/compile/GENERIC
real mem = 133103616 (126MB)
avail mem = 107405312 (102MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (5 entries)
bios0: vendor innotek GmbH version VirtualBox date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P7550 @ 2.26GHz, 1974.41 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,MWAIT,SSSE3,NXE,LONG,LAHF
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: apic clock running 

Re: wait4() busy endless OR: gcc: Internal error: Trace/BPT trap (program cc1)

2012-03-19 Thread Philip Guenther
On Mon, Mar 19, 2012 at 2:30 PM, Steffen Daode Nurpmeso
sdao...@googlemail.com wrote:
 Sorry folks for this shitty report, but i thought it's maybe
 better to send it out than not to be able to sleep or so.
 I guess it's somehow related to the rthread wait4() path, but of
 course i dunno.  Here's what's happened:
...
 Note i (yet) use(d) a very primitive compilation approach
 - i simply do 'make all', which sometimes requires changes by hand
 (e.g. today drop of SO_JUMBO in kdump).  *This* is only a fellow
 traveler virtual box, and doing the full rebuild blocks normal
 work out some hours longer, so..
 I had not yet time to check this on a real box.

I don't know whether it's your non-standard build procedure, a virtual
machine that lies, or something else, but I'm certainly not seeing the
wait4() looping problem you show when I try it on real hardware using
the standard build procedure.

If you can reproduce it on real hardware with the standard build
procedure, then please report it here.



 Puke!  I had to run a debugger :-((:

  (gdb) break vfork
  Breakpoint 1 at 0x401a50
...
  Breakpoint 1, 0x0002088b0f90 in vfork () from /usr/lib/libc.so.62.0
  (gdb) step
  Single stepping until exit from function vfork,
  which has no line number information.

Single-stepping past vfork?  Has that *ever* worked?


  gcc: Internal error: Trace/BPT trap (program cc1)
  Please submit a full bug report.

This may be a side-effect of the work that's in process for adding
thread support to ptrace(), but seems odd.  shurg


 Well; unless there is interest in something i'll do a complete
 cleanup and recompile tomorrow.
 I would report if the problem remains, then.

If it works on real hardware, then you should have a conversation with
the support channel for your virtual hardware.


Philip Guenther