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/cissvar.h P src/sys/dev/ic/gem.c P src/sys/dev/pci/ciss_pci.c P src/sys/dev/pci/if_bnx.c P src/sys/dev/pci/if_bnxvar.h P src/sys/dev/pci/pcidevs P src/sys/dev/pci/pcidevs.h P src/sys/dev/pci/pcidevs_data.h P src/sys/stand/efiboot/efiboot.h P src/sys/stand/efiboot/efidev.c P src/sys/stand/efiboot/efifile.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.3 P external/bsd/dhcpcd/dist/hooks/01-test P lib/libcurses/newwin.c P sys/dev/pci/vioscsi.c P sys/dev/scsipi/scsiconf.c P sys/dev/usb/ualea.c Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.1 P etc/wscons.conf P external/bsd/dhcpcd/dist/hooks/01-test P lib/libcurses/newwin.c P sbin/wsconsctl/wsconsctl.8 P share/man/man4/pckbd.4 P share/man/man4/wskbd.4 P sys/arch/x86/include/specialreg.h P sys/dev/hid/hidkbdmap.c P sys/dev/pci/vioscsi.c P sys/dev/pckbport/wskbdmap_mfii.c P sys/dev/scsipi/scsiconf.c P sys/dev/usb/ualea.c P sys/dev/wscons/wsksymdef.h Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 41599417 Jul 15 03:10 ls-lRA.gz
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/standalone-tcsh that does it. Is it broken now? > > > > Martin > > > > There are many malloc wrappers or replacements for introspection, so > this should be operational. > > We also deliver gnumalloc in base.. I suspect this also doesn't play well with devel/dmalloc then? Cheers, Simon.
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. i worked around it a few days ago. .mrg.
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 c04b3eac netbsd:vpanic+0x15c [ 37088.6970231] fp c0086e1d8a90 kern_assert() at c07d2eec netbsd:kern_assert+0x5c [ 37088.7070240] fp c0086e1d8b20 amap_add() at c04143cc netbsd:amap_add+0x214 [ 37088.7170234] fp c0086e1d8b60 uvmfault_promote() at c0419a7c netbsd:uvmfault_promote+0x174 [ 37088.7270239] fp c0086e1d8bc0 uvm_fault_internal() at c041b6b0 netbsd:uvm_fault_internal+0xf78 [ 37088.7370250] fp c0086e1d8de0 data_abort_handler() at c008e31c netbsd:data_abort_handler+0x184 [ 37088.7470247] fp c0086e1d8e60 trap_el0_sync() at c008d5bc netbsd:trap_el0_sync+0x35c [ 37088.7570263] tf c0086e1d8ed0 el0_trap() at c008a924 netbsd:el0_trap [ 37088.7570263] trapframe 0xc0086e1d8ed0 (304 bytes) [ 37088.7670355] pc=000200a4f5bc, spsr=2000 [ 37088.7770287]esr=9207,far=fe9bc0431fe0 [ 37088.7770287] x0=0003, x1=000201148000 [ 37088.7870299] x2=0008, x3=0001 [ 37088.7870299] x4=0060, x5=fe9bd8c1d888 [ 37088.7970293] x6=ffbc0710, x7= [ 37088.8070290] x8=000201148000, x9=000201114000 [ 37088.8070290]x10=0001,x11=0001 [ 37088.8170281]x12=000a,x13=ffbbfef8 [ 37088.8170281]x14=0240,x15=0240 [ 37088.8270283]x16=0002010789f8,x17=fe9bd97a7140 [ 37088.8270283]x18=0010,x19=ffbc06a8 [ 37088.8370282]x20=e1e0,x21=fe9bc0423e00 [ 37088.8470286]x22=fe9bc0431fe0,x23=000a [ 37088.8470286]x24=fe9bc2d8e1a0,x25=0002 [ 37088.8570282]x26=fe9bc4188ee0,x27=000200d91060 [ 37088.8570282]x28=, fp=x29=ffbc0490 [ 37088.8670287] lr=x30=000200a4f848, sp=ffbc0490 [ 37088.8770281] [ 37088.8770281] cpu4: End traceback...
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 provides its own malloc() >> > >> > On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote: >> > > I think it is the following change (and perhaps more similar/related >> > > changes) which breaks static linking of applications which wish to >> > > supply their own implementation of malloc(), and which call, e.g., >> > > fork(): >> > >> > I consider it a strong WONTFIX. It's no different from not poviding >> > posix_memalign etc. >> >> >> Well, _malloc_prefork() is explicitly called with an underscore leading >> the identifier name, so strictly speaking it's invalid for an >> application to define it. (and it's not documented, nor in any standard >> that I can find, with or without the leading underscore). > >Replacing malloc is just as invalid from a strict standard compliance >perspective, so *shrug* > >I have absolutely no intention of dealing with more complexity than >necessary for the libc and libpthread interaction for a fringe case. If >it fails explicitly, I would actually consider it an improvement. It is not only _malloc_prefork(), it is also _malloc_postfork() and _malloc_postfork_child(). The easiest way to fix things is to provide them as no-op. christos
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 now? > > Martin > There are many malloc wrappers or replacements for introspection, so this should be operational. We also deliver gnumalloc in base.. signature.asc Description: OpenPGP digital signature
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 > inet6 ::1/128 flags 0x20 > inet6 fe80::1%lo0/64 flags 0 scopeid 0x1 > $ rump.ifconfig bridge0 create > > and watch rump_allserver's cpu use hit 100% (!) Filed as PR kern/55489 Cheers, Patrick
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.ifconfig bridge0 create and watch rump_allserver's cpu use hit 100% (!) Cheers, Patrick
