daily CVS update output

[NetBSD source update]

Updating src tree:
P src/distrib/sets/lists/comp/mi
P src/distrib/sets/lists/debug/ad.arm
P src/doc/CHANGES
P src/external/cddl/osnet/dev/dtrace/arm/dtrace_isa.c
P src/external/cddl/osnet/dev/sdt/sdt.c
P src/external/cddl/osnet/dist/uts/common/sys/dtrace.h
P src/external/cddl/osnet/sys/sys/sdt.h
P src/lib/libc/sys/nanosleep.2
P src/share/man/man9/Makefile
P src/share/man/man9/pci.9
P src/share/misc/airport
P src/sys/arch/algor/pci/vtpbc.c
P src/sys/arch/alpha/pci/apecs_pci.c
P src/sys/arch/alpha/pci/cia_pci.c
P src/sys/arch/alpha/pci/dwlpx_pci.c
P src/sys/arch/alpha/pci/irongate_pci.c
P src/sys/arch/alpha/pci/lca_pci.c
P src/sys/arch/alpha/pci/mcpcia_pci.c
P src/sys/arch/alpha/pci/tsp_pci.c
P src/sys/arch/alpha/pci/ttwoga_pci.c
P src/sys/arch/amiga/pci/cv3dpb.c
P src/sys/arch/amiga/pci/em4k.c
P src/sys/arch/amiga/pci/empb.c
P src/sys/arch/amiga/pci/mppb.c
P src/sys/arch/amiga/pci/p5pb.c
P src/sys/arch/arc/pci/necpb.c
P src/sys/arch/arm/allwinner/awin_gpio.c
P src/sys/arch/arm/broadcom/bcm53xx_pax.c
P src/sys/arch/arm/footbridge/footbridge_pci.c
P src/sys/arch/arm/gemini/gemini_pci.c
P src/sys/arch/arm/ixp12x0/ixp12x0_pci.c
P src/sys/arch/arm/marvell/pci_machdep.c
P src/sys/arch/arm/nvidia/tegra_pcie.c
P src/sys/arch/arm/s3c2xx0/s3c2800_pci.c
P src/sys/arch/arm/xscale/becc_pci.c
P src/sys/arch/arm/xscale/i80312_pci.c
P src/sys/arch/arm/xscale/i80321_pci.c
P src/sys/arch/arm/xscale/ixp425_pci.c
P src/sys/arch/atari/pci/pci_hades.c
P src/sys/arch/atari/pci/pci_milan.c
P src/sys/arch/cobalt/pci/pci_machdep.c
P src/sys/arch/dreamcast/dev/g2/gapspci_pci.c
P src/sys/arch/evbarm/ifpga/ifpga_pci.c
P src/sys/arch/evbmips/loongson/dev/glx.c
P src/sys/arch/evbmips/malta/dev/gt.c
P src/sys/arch/hpcmips/dev/plum.c
P src/sys/arch/hpcmips/vr/vrc4172pci.c
P src/sys/arch/hpcmips/vr/vrpciu.c
P src/sys/arch/hppa/dev/dino.c
P src/sys/arch/hppa/dev/elroy.c
P src/sys/arch/ia64/pci/pci_machdep.c
P src/sys/arch/macppc/pci/bandit.c
P src/sys/arch/macppc/pci/grackle.c
P src/sys/arch/macppc/pci/u3.c
P src/sys/arch/macppc/pci/uninorth.c
P src/sys/arch/mips/adm5120/dev/admpci.c
P src/sys/arch/mips/alchemy/dev/aupci.c
P src/sys/arch/mips/atheros/dev/arpci.c
P src/sys/arch/mips/bonito/bonito_pci.c
P src/sys/arch/mips/rmi/rmixl_pcie.c
P src/sys/arch/mips/rmi/rmixl_pcix.c
P src/sys/arch/mips/sibyte/pci/sbbrz_pci.c
P src/sys/arch/powerpc/booke/pci/pq3pci.c
P src/sys/arch/powerpc/ibm4xx/pci/pci_machdep.c
P src/sys/arch/powerpc/pci/pciconf_indirect.c
P src/sys/arch/powerpc/pci/pciconf_ofmethod.c
P src/sys/arch/prep/pci/prep_pciconf_direct.c
P src/sys/arch/sandpoint/pci/pci_machdep.c
P src/sys/arch/sgimips/gio/pci_gio.c
P src/sys/arch/sgimips/mace/pci_mace.c
P src/sys/arch/sh3/dev/shpcic.c
P src/sys/arch/sparc/sparc/pci_machdep.c
P src/sys/arch/sparc/stand/ofwboot/Makefile
P src/sys/arch/sparc64/dev/psycho.c
P src/sys/arch/sparc64/dev/pyro.c
P src/sys/arch/sparc64/dev/schizo.c
P src/sys/arch/x86/acpi/acpi_machdep.c
P src/sys/arch/x86/pci/pci_machdep.c
P src/sys/dev/acpi/acpi.c
U src/sys/dev/acpi/acpi_mcfg.c
U src/sys/dev/acpi/acpi_mcfg.h
P src/sys/dev/acpi/files.acpi
P src/sys/dev/marvell/gtpci.c
P src/sys/dev/marvell/mvpex.c
P src/sys/dev/pci/pci.c
P src/sys/dev/pci/pci_subr.c
P src/sys/dev/pci/pcireg.h
P src/sys/dev/pci/pcivar.h
P src/sys/kern/kern_exec.c
P src/sys/kern/kern_exit.c
P src/sys/kern/kern_fork.c
P src/sys/kern/kern_lwp.c
P src/sys/kern/kern_sdt.c
P src/sys/kern/kern_sig.c
P src/sys/kern/kern_time.c
P src/sys/kern/sys_sig.c
P src/sys/kern/syscalls.master
P src/sys/kern/vfs_cache.c
P src/sys/net/if.h
P src/sys/sys/sdt.h
P src/usr.sbin/tadpolectl/tadpolectl.c

Updating xsrc tree:


Killing core files:


Updating tar files:
src/top-level: collecting... replacing... done
src/bin: collecting... replacing... done
src/common: collecting... replacing... done
src/compat: collecting... replacing... done
src/crypto: collecting... replacing... done
src/dist: collecting... replacing... done
src/distrib: collecting... replacing... done
src/doc: collecting... replacing... done
src/etc: collecting... replacing... done
src/external: collecting... replacing... done
src/extsrc: collecting... replacing... done
src/games: collecting... replacing... done
src/gnu: collecting... replacing... done
src/include: collecting... replacing... done
src/lib: collecting... replacing... done
src/libexec: collecting... replacing... done
src/regress: collecting... replacing... done
src/rescue: collecting... replacing... done
src/sbin: collecting... replacing... done
src/share: collecting... replacing... done
src/sys: collecting... replacing... done
src/tests: collecting... replacing... done
src/tools: collecting... replacing... done
src/usr.bin: collecting... replacing... done
src/usr.sbin: collecting... replacing... done
src/config: collecting... replacing... done
src/x11: collecting...pax: Unable to access src/x11 (No such file or directory)
pax: WARNING! These file names were not selected:
src/x11
 done
src: collecting... replacing... done
xsrc/top-level: 

Problems with gdb?

[Paul Goyette]

In attempts to debug another problem (see the thread about "killing 
zombies"), I've twice forced crash dumps from ddb.  Once with the 'sync' 
command, and once with 'reboot 0x104'.


Both crash dump files appear valid

# file netbsd.4.core
netbsd.4.core: NetBSD kernel core file, amd64 BSD, (headersize = 16, 
segmentsize = 8, segments = 131080)

# file netbsd.5.core
netbsd.5.core: NetBSD kernel core file, amd64 BSD, (headersize = 16, 
segmentsize = 8, segments = 131080)


And crash(8) seems capable of processing them:

# crash -M netbsd.4.core
Crash version 7.99.21, image version 7.99.21.
System panicked: dump forced via kernel debugger
Backtrace from time of crash is available.
crash> show proc 1
init: pid 1 proc fe810f46ecd0 vmspace/map fe810f483e60 flags 
4001

  lwp 1 fe810f476a60 pcb fe810f464000
stat 2 flags 802 cpu 0 pri 43
crash>

Yet, gdb fails to process these files:

# gdb
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show 
copying"

and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target kvm netbsd.4.core
 in ?? ()
(gdb) symbol-file /netbsd.gdb
Reading symbols from /netbsd.gdb...done.
PC register is not available

And trying to examine the "struct proc" for init (using the address from 
crash output) fails miserably!


(gdb) print *(struct proc *)0xfe810f46ecd0
Segmentation fault (core dumped)


Has something recently broken in gdb?

My system is a complete kernel+userland amd64/7.99.21 built from sources 
updated via anoncvs on 2015-09-20 at 02:09:58 UTC.





+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+--+--+-+

Re: Killing a zombie process?

[Robert Elz]

Date:Fri, 2 Oct 2015 15:26:42 +0800 (PHT)
From:Paul Goyette 
Message-ID:  

  | 1. Is it correct for init's p_nstopchild to be zero when it has several
  | children whose p_state is SSTOP?

Depends whether those children have previously been waited for or not.
Stopped children don't go away when they're waited for, so there needs
to be something to prevent wait() returning the same stopped child
over and over again.   That's p_waited ... so you need to check that
value of the stopped children, if it is 0, then something is broken.
If it is 1 (for all of them) then they're irrelevant, and matter not
at all.

  | 2. Is the above code in init correct?  Should we really be leaving the
  | loop when there are more children to examine?

It is an optimisation, and should be correct.

However, it dpes depend upon p_nstoppedchild being maintained correctly.

You didn't say whether your zombie process is actually to be found
(somewhere) on the parent's (ie: init's) list of children.

I have no idea how one would discover this (at this point, or given
how long you need to wait for it to happen, perhaps ever) but it would
also be interesting to know whether the zombie was reparented to init
before or after it died.

The common case is for a parent to exit, leaving running children, which
are reparented to init, complete, exit, and init cleans them up.

But it is also possible for a child to die, be ignored by its parent,
which later exit itself, leaving the zombie to be reparented to init.
That's more unusual - does not happen very often, but if that is
what happened here, it is possible that there's some bug in the processing
of that case.

kre

Re: Killing a zombie process?

[Paul Goyette]

On Sun, 4 Oct 2015, Robert Elz wrote:


   Date:Fri, 2 Oct 2015 15:26:42 +0800 (PHT)
   From:Paul Goyette 
   Message-ID:  

 | 1. Is it correct for init's p_nstopchild to be zero when it has several
 | children whose p_state is SSTOP?

Depends whether those children have previously been waited for or not.
Stopped children don't go away when they're waited for, so there needs
to be something to prevent wait() returning the same stopped child
over and over again.   That's p_waited ... so you need to check that
value of the stopped children, if it is 0, then something is broken.
If it is 1 (for all of them) then they're irrelevant, and matter not
at all.


All of those head-of-sibling-list processes were p_stat == SSTOP and 
p_waited=0, and none of them has (p_slflag & PSL_TRACED).  And, since 
init(8) is calling waitpid( ..., ..., 0), the value of options is zero 
so the following code (immediately before the previously-quoted code, at 
src/sys/kern/kern_exit.c:780) doesn't trigger:


if (child->p_stat == SSTOP &&
child->p_waited == 0 &&
(child->p_slflag & PSL_TRACED ||
options & WUNTRACED)) {
if ((options & WNOWAIT) == 0) {
child->p_waited = 1;
parent->p_nstopchild--;
}
break;
}

So "something is broken" ?  :)


The waitpid() call in init is at src/sbin/init/init.c:1506.  Since my 
Zombie does finally die during a transition from multi-user back down to 
single-user, I'm guessing that one of the other calls to waitpid() is 
clearing out the SSTOPed processes at the head of the p_sibling list, 
perhaps the call in single_user() at line 773?


...
requested_transition = 0;
do {
if ((wpid = waitpid(-1, , WUNTRACED)) != -1)
collect_child(wpid, status);
...




 | 2. Is the above code in init correct?  Should we really be leaving the
 | loop when there are more children to examine?

It is an optimisation, and should be correct.

However, it dpes depend upon p_nstoppedchild being maintained correctly.

You didn't say whether your zombie process is actually to be found
(somewhere) on the parent's (ie: init's) list of children.


Yes, the zombie was the eighth entry on init's p_sibling list.

Several of the front-of-list processes appeared to be related to some 
system daemons.  (One was related to consolekit, one to dbus.)  And the 
very first child of init seems to have been another copy of init (based 
on its p_comm[] field)!




I have no idea how one would discover this (at this point, or given
how long you need to wait for it to happen, perhaps ever) but it would
also be interesting to know whether the zombie was reparented to init
before or after it died.

The common case is for a parent to exit, leaving running children, which
are reparented to init, complete, exit, and init cleans them up.

But it is also possible for a child to die, be ignored by its parent,
which later exit itself, leaving the zombie to be reparented to init.
That's more unusual - does not happen very often, but if that is what
happened here, it is possible that there's some bug in the processing
of that case.


Hmmm, probably not possible to differentiate at this point.



+--+--+-+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:   |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org  |
+--+--+-+