Re: pkg_add/pkg_delete: include PID in syslog messages

2012-03-19 Thread Marc Espie
On Wed, Mar 07, 2012 at 12:31:48AM -0500, Lawrence Teo wrote:
 This simple diff makes pkg_add and pkg_delete include their PID when
 logging to syslog. This is useful when trying to determine whether
 several packages were added (or removed) by the same pkg_add (or
 pkg_delete) process.
 
 Here is some sample output:
 
 Mar  3 22:15:17 obsd-amd64 pkg_add[3530]: Added nano-2.2.6 
 Mar  3 22:15:26 obsd-amd64 pkg_delete[21136]: Removed nano-2.2.6 
 Mar  3 22:16:51 obsd-amd64 pkg_add[30666]: Added redland-1.0.8p1 
 Mar  3 22:16:54 obsd-amd64 pkg_add[30666]: Added mozilla-dicts-en-GB-1.3 
 Mar  3 22:16:56 obsd-amd64 pkg_add[30666]: Added hunspell-1.2.12 
 Mar  3 22:23:22 obsd-amd64 pkg_add[30666]: Added libreoffice-3.4.5.2v0 
 Mar  3 23:33:23 obsd-amd64 pkg_add[5948]: Added kdiff3-0.9.96p1 
 
 Comments?

The more I think about it, the more I fail to see the value.
Consider that any pkg_add/pkg_delete that actually changes installed
packages *will* lock the database anyways, so by nature, all relevant
runs of pkg_add/pkg_delete will happen in sequence.

Hence, there's totally no ambiguity in the log lines. If I remove the pids
in there, I still have no trouble figuring out what happened.

When I look at those logs, I usually have to look at the time anyways,
so in the above case, figuring out that libreoffice and kdiff3 are
different runs of pkg_add is not that hard...

I won't say I can't be swayed, but you'll have to give me a concrete case
where the pid offers some actual advantage over no pid.



утро доброе мой красиввый!)

2012-03-19 Thread Леночка Кругликова
Ophbeer D`x` lme qjhmsk` }kejrpnmm{i `dpeq rbni..)) 
g`k`g| m` ln~ qrp`mhwjs zmuljno.pop3.ruHg`aekknwj`uJnqrnl`pnb` ln8 hl r`l! 
eqkh reae g`unwerq nayemh!!! 



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