daily CVS update output

Updating src tree: P src/doc/CHANGES P src/lib/libcurses/newwin.c P src/share/man/man4/ciss.4 P src/sys/arch/macppc/dev/cuda.c P src/sys/arch/macppc/dev/pmu.c P src/sys/arch/macppc/macppc/machdep.c P src/sys/arch/x86/x86/idt.c P src/sys/dev/ic/ciss.c P src/sys/dev/ic/cissreg.h P src/sys/dev/ic/ci

Re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()

Kamil Rytarowski wrote: > On 14.07.2020 06:28, Martin Husemann wrote: > > On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote: > >> Replacing malloc is just as invalid from a strict standard compliance > >> perspective, so *shrug* > > > > Why is that? > > > > We have e.g. shells/s

re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()

Martin Husemann writes: > On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote: > > Replacing malloc is just as invalid from a strict standard compliance > > perspective, so *shrug* > > Why is that? > > We have e.g. shells/standalone-tcsh that does it. Is it broken now? it was, yes

yet another uvm_amap panic

[ 37088.6770221] panic: kernel diagnostic assertion "amap->am_nused < amap->am_maxslot" failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c", line 1505 [ 37088.6870223] cpu4: Begin traceback... [ 37088.6870223] trace fp c0086e1d8a00 [ 37088.6970231] fp c0086e1d8a20 vpanic() at c

Re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()

In article <20200714004900.gb84...@bec.de>, Joerg Sonnenberger wrote: >On Mon, Jul 13, 2020 at 04:28:56PM -0700, Greg A. Woods wrote: >> At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote: >> Subject: Re: recent changes to pthread_fork.c:fork() cause static >linking to fail if the app

Re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()

On 14.07.2020 06:28, Martin Husemann wrote: > On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote: >> Replacing malloc is just as invalid from a strict standard compliance >> perspective, so *shrug* > > Why is that? > > We have e.g. shells/standalone-tcsh that does it. Is it broken

Re: rump bridge fun

On Tue, Jul 14, 2020 at 11:20:24AM +0100, Patrick Welche wrote: > On 9.99.68/amd64, in one xterm: > > $ rump_allserver -sv unix:///tmp/sock > > in another xterm: > > $ export RUMP_SERVER=unix:///tmp/sock > $ rump.ifconfig -a > lo0: flags=0x8049 mtu 33624 > inet 127.0.0.1/8 flags 0 >

rump bridge fun

On 9.99.68/amd64, in one xterm: $ rump_allserver -sv unix:///tmp/sock in another xterm: $ export RUMP_SERVER=unix:///tmp/sock $ rump.ifconfig -a lo0: flags=0x8049 mtu 33624 inet 127.0.0.1/8 flags 0 inet6 ::1/128 flags 0x20 inet6 fe80::1%lo0/64 flags 0 scopeid 0x1 $ rump.i