Re: HEADS-UP: /bin/sh memory management bug fixes committed
Date:Mon, 19 Jun 2017 05:39:28 + From:"Thomas Mueller" Message-ID: <92.EA.01815.89367495@dnvrco-omsmta03> | I suspect sh bug might have been at fault at least in part for | pkg_rolling-replace strange behavior, That is possible. | "make deinstall install". I generally do pkg_delete rather than make deinstall (had no idea such an option existed). But otherwise, right. | I have to consider the likelihood that many installed packages will no | longer work after updating kernel and userland from 7.99.15 to 7.99.71 | to 8.99.1 because shared libraries figure to be out of sync. That should not be a problem, the only things that should need recompiling are things that depend upon osabi - usually I think that is far too strict, but in this case there's really no way it can know that nothing much has changed since (at least high) 7.99.nn versions and 8.99.1 There might be an isolated package that uses one of the rarer libraries which might have been updated (particularly since 7.99.15) which you can solve either by recompiling (it, and everything else it depends upon which also might use the changed library) or you can just copy the lib.so.N.M file from the old system to the new one (and perhaps the libxxx.so.N symlink which points at that one - I've never been sure exactly when that one is used). Just beware of mixing object files (which includes .so files) compiled and or linked using different versions of what is intended to be the same thing. That leads to havoc. Apart from that I regularly run ancient compiled packages on newer systems, NetBSD people generally work very hard to make sure that remains possible. In fact, I usually compile all my packages against the N.0 RELEASE version (for whichever NetBSD version (N) I am using at the time) - that way one set of binary packages are all that are needed for all systems (of the same architecture, naturally) whatever actual N.p.q version I actually install on them.) kre
Seg Faults building devel/gobject-inspection with latest 8.0_BETA
I just upgraded my desktop from 7.1_STABLE to 8.0_BETA, and I'm
in the process of rebuilding all packages using pkg_rolling-replace.
However, I'm getting consistent failures trying to build
devel/gobject-inspection:
NetBSD capo.xnet.duzan.org 8.0_BETA NetBSD 8.0_BETA (GENERIC) #2: Sun Jun 18
18:18:17 EDT 2017
r...@bldr.6net.duzan.org:/usr/build/netbsd-8/obj/usr/build/netbsd-8/src/sys/arch/amd64/compile/GENERIC
amd64
[...]
GEN g-ir-scanner
GEN g-ir-annotation-tool
GISCAN GLib-2.0.gir
/usr/pkg/include/glib/glib-2.0/glib/glib-autocleanups.h:41: syntax error,
unexpected typedef-name, expecting identifier or '(' in 'typedef GAsyncQueue
*GAsyncQueue_autoptr;' at 'GAsyncQueue_autoptr'
/usr/pkg/include/glib/glib-2.0/glib/glib-autocleanups.h:42: syntax error,
unexpected typedef-name, expecting identifier or '(' in 'typedef GBookmarkFile
*GBookmarkFile_autoptr;' at 'GBookmarkFile_autoptr'
/usr/pkg/include/glib/glib-2.0/glib/glib-autocleanups.h:43: syntax error,
unexpected typedef-name, expecting identifier or '(' in 'typedef GBytes
*GBytes_autoptr;' at 'GBytes_autoptr'
/usr/pkg/include/glib/glib-2.0/glib/glib-autocleanups.h:44: syntax error,
unexpected typedef-name, expecting identifier or '(' in 'typedef GChecksum
*GChecksum_autoptr;' at 'GChecksum_autoptr'
/usr/pkg/include/glib/glib-2.0/glib/glib-autocleanups.h:45: syntax error,
unexpected typedef-name, expecting identifier or '(' in 'typedef GDateTime
*GDateTime_autoptr;' at 'GDateTime_autoptr'
[...]
/usr/pkg/include/glib/glib-2.0/glib/glib-autocleanups.h:86: syntax error,
unexpected typedef-name, expecting identifier or '(' in 'typedef GVariantDict
*GVariantDict_autoptr;' at 'GVariantDict_autoptr'
/usr/pkg/include/glib/glib-2.0/glib/glib-autocleanups.h:88: syntax error,
unexpected typedef-name, expecting identifier or '(' in 'typedef GVariantType
*GVariantType_autoptr;' at 'GVariantType_autoptr'
Command
'[u'/usr/pkgsrc/devel/gobject-introspection/work/gobject-introspection-1.50.0/tmp-introspectm6Wk6w/GLib-2.0',
u'--introspect-dump=/usr/pkgsrc/devel/gobject-introspection/work/gobject-introspection-1.50.0/tmp-introspectm6Wk6w/functions.txt,/usr/pkgsrc/devel/gobject-introspection/work/gobject-introspection-1.50.0/tmp-introspectm6Wk6w/dump.xml']'
returned non-zero exit status -11
[1] Segmentation fault (core dumped) CPPFLAGS="-I/usr...
Makefile:3520: recipe for target 'GLib-2.0.gir' failed
[...]
GLib-2.0.core: ELF 64-bit LSB core file x86-64, version 1 (SYSV),
NetBSD-style, from 'GLib-2.0', pid=9686, uid=0, gid=0, nlwps=1, lwp=1 (signal
11/code 32767)
python2.7.core: ELF 64-bit LSB core file x86-64, version 1 (SYSV),
NetBSD-style, from 'python2.7', pid=27916, uid=0, gid=0, nlwps=1, lwp=1 (signal
11/code 32767)
The python stack (what there is of it) looks like:
#0 0x793f79805663 in ?? ()
#1 0x793f79400585 in ?? () from /usr/pkg/lib/libgthread-2.0.so.0
#2 0x793f849fa140 in ?? ()
#3 0x793f79400669 in _fini () from /usr/pkg/lib/libgthread-2.0.so.0
#4 0x in ?? ()
The other core appears to be from some temporary executable
which got cleaned up, so there is even less information in its
stack trace.
#0 0x70f568605663 in ?? ()
#1 0x70f568200585 in ?? ()
#2 0x70f56c2a4e80 in ?? ()
#3 0x70f568200669 in ?? ()
#4 0x in ?? ()
Can anyone else recreate this?
Thanks.
Gary Duzan
Re: Seg Faults building devel/gobject-inspection with latest 8.0_BETA
On Mon, Jun 19, 2017 at 06:49:59AM -0400, Gary Duzan wrote: >Can anyone else recreate this? Could be another instance of the elusive PR 51266. Thomas
Re: Seg Faults building devel/gobject-inspection with latest 8.0_BETA
=> On Mon, Jun 19, 2017 at 06:49:59AM -0400, Gary Duzan wrote: =>>Can anyone else recreate this? => => Could be another instance of the elusive PR 51266. => Thomas => It certainly looks like it. I'll try the workaround and see how it goes. Thanks. Gary Duzan
Re: pkg/51266: Seg Faults building devel/gobject-inspection with latest 8.0_BETA
=> => On Mon, Jun 19, 2017 at 06:49:59AM -0400, Gary Duzan wrote: => =>>Can anyone else recreate this? => => => => Could be another instance of the elusive PR 51266. => => Thomas => => => =>It certainly looks like it. I'll try the workaround and see how it => goes. That does appear to have fixed it. If the problem is with glib gio modules, would it make sense to fix the issue by extending buildlink? It looks like GIO_MODULE_DIR can be used to override the directory location, so buildlink could set up links to the required modules, ignoring the others, and use the link directory. I'm sure it is more complicated than that, but does it sound like a reasonable approach? Gary Duzan
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2017.06.19.19.58.24.
An extract from the build.sh output follows:
--- releasekern-XEN3PAE_DOM0 ---
--- releasekern-XEN3PAE_DOMU ---
--- releasekern-XEN3_DOM0 ---
--- releasekern-XEN3_DOMU ---
--- kernset-LEGACY ---
echo netbsd | GZIP=-9\ -n
/tmp/bracket/build/2017.06.19.19.58.24-i386/tools/bin/nbpax
--use-compress-program gzip -O -w -M -N
/tmp/bracket/build/2017.06.19.19.58.24-i386/src/etc -f
/bracket/i386/test/2017.06.19.19.58.24/release/i386/binary/sets/kern-LEGACY.tgz
--- kernset-XEN3PAE_DOM0 ---
echo netbsd | GZIP=-9\ -n
/tmp/bracket/build/2017.06.19.19.58.24-i386/tools/bin/nbpax
--use-compress-program gzip -O -w -M -N
/tmp/bracket/build/2017.06.19.19.58.24-i386/src/etc -f
/bracket/i386/test/2017.06.19.19.58.24/release/i386/binary/sets/kern-XEN3PAE_DOM0.tgz
--- kernset-MONOLITHIC ---
echo netbsd | GZIP=-9\ -n
/tmp/bracket/build/2017.06.19.19.58.24-i386/tools/bin/nbpax
--use-compress-program gzip -O -w -M -N
/tmp/bracket/build/2017.06.19.19.58.24-i386/src/etc -f
/bracket/i386/test/2017.06.19.19.58.24/release/i386/binary/sets/kern-MONOLITHIC.tgz
--- kernset-GENERIC ---
echo netbsd | GZIP=-9\ -n
/tmp/bracket/build/2017.06.19.19.58.24-i386/tools/bin/nbpax
--use-compress-program gzip -O -w -M -N
/tmp/bracket/build/2017.06.19.19.58.24-i386/src/etc -f
/bracket/i386/test/2017.06.19.19.58.24/release/i386/binary/sets/kern-GENERIC.tgz
--- kernset-XEN3PAE_DOMU ---
echo netbsd | GZIP=-9\ -n
/tmp/bracket/build/2017.06.19.19.58.24-i386/tools/bin/nbpax
--use-compress-program gzip -O -w -M -N
/tmp/bracket/build/2017.06.19.19.58.24-i386/src/etc -f
/bracket/i386/test/2017.06.19.19.58.24/release/i386/binary/sets/kern-XEN3PAE_DOMU.tgz
--- kernset-XEN3_DOMU ---
echo netbsd | GZIP=-9\ -n
/tmp/bracket/build/2017.06.19.19.58.24-i386/tools/bin/nbpax
--use-compress-program gzip -O -w -M -N
/tmp/bracket/build/2017.06.19.19.58.24-i386/src/etc -f
/bracket/i386/test/2017.06.19.19.58.24/release/i386/binary/sets/kern-XEN3_DOMU.tgz
--- kernset-XEN3_DOM0 ---
echo netbsd | GZIP=-9\ -n
/tmp/bracket/build/2017.06.19.19.58.24-i386/tools/bin/nbpax
--use-compress-program gzip -O -w -M -N
/tmp/bracket/build/2017.06.19.19.58.24-i386/src/etc -f
/bracket/i386/test/2017.06.19.19.58.24/release/i386/binary/sets/kern-XEN3_DOM0.tgz
--- kernset-XEN3_DOMU ---
pax: line 3: ./${DTS:.dts=.dtb}: mode not specified
*** [kernset-XEN3_DOMU] Error code 1
nbmake[1]: stopped in /tmp/bracket/build/2017.06.19.19.58.24-i386/src/etc
The following commits were made between the last successful build and
the failed build:
2017.06.19.19.02.16 joerg src/sys/kern/exec_subr.c,v 1.80
2017.06.19.19.58.24 christos src/usr.bin/make/main.c,v 1.272
2017.06.19.19.58.24 christos src/usr.bin/make/make.1,v 1.267
Log files can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2017.06.html#2017.06.19.19.58.24
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2017.06.19.20.10.18 christos src/etc/Makefile,v 1.431 2017.06.19.20.12.34 christos src/external/bsd/elftosb/usr.sbin/elftosb/Makefile,v 1.5 2017.06.19.20.12.34 christos src/external/bsd/mdocml/bin/mandoc/Makefile,v 1.12 2017.06.19.20.52.20 mlelstv src/sys/dev/scsipi/scsipi_base.c,v 1.177 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2017.06.html#2017.06.19.20.52.20
daily CVS update output
Updating src tree: P src/bin/sh/eval.c P src/bin/sh/mknodenames.sh P src/distrib/sets/lists/comp/mi P src/etc/Makefile P src/external/bsd/elftosb/usr.sbin/elftosb/Makefile P src/external/bsd/mdocml/bin/mandoc/Makefile P src/libexec/ld.elf_so/Makefile P src/libexec/ld.elf_so/map_object.c P src/libexec/ld.elf_so/rtld.h P src/libexec/ld.elf_so/symbol.c P src/libexec/ld.elf_so/arch/aarch64/mdreloc.c P src/libexec/ld.elf_so/arch/alpha/alpha_reloc.c P src/libexec/ld.elf_so/arch/arm/mdreloc.c P src/libexec/ld.elf_so/arch/hppa/hppa_reloc.c P src/libexec/ld.elf_so/arch/i386/mdreloc.c P src/libexec/ld.elf_so/arch/m68k/mdreloc.c P src/libexec/ld.elf_so/arch/mips/mips_reloc.c P src/libexec/ld.elf_so/arch/or1k/mdreloc.c P src/libexec/ld.elf_so/arch/powerpc/ppc_reloc.c P src/libexec/ld.elf_so/arch/riscv/mdreloc.c P src/libexec/ld.elf_so/arch/sh3/mdreloc.c P src/libexec/ld.elf_so/arch/sparc/mdreloc.c P src/libexec/ld.elf_so/arch/sparc64/mdreloc.c P src/libexec/ld.elf_so/arch/vax/mdreloc.c P src/libexec/ld.elf_so/arch/x86_64/mdreloc.c P src/sbin/route/route.8 P src/share/man/man4/pxagpio.4 P src/sys/arch/arm/samsung/exynos5422_clock.c P src/sys/arch/arm/samsung/exynos_dwcmmc.c P src/sys/arch/arm/samsung/exynos_sscom.c P src/sys/arch/arm/samsung/exynos_sysmmu.c P src/sys/arch/evbarm/conf/EXYNOS P src/sys/dev/ic/dwc_mmc.c P src/sys/dev/ic/dwc_mmc_reg.h P src/sys/dev/ic/dwc_mmc_var.h P src/sys/dev/pad/pad.c P src/sys/dev/pci/if_wm.c P src/sys/dev/scsipi/scsipi_base.c P src/sys/kern/exec_subr.c P src/sys/netinet/tcp_input.c P src/sys/sys/Makefile cvs update: `src/sys/sys/user.h' is no longer in the repository P src/sys/ufs/lfs/lfs_subr.c P src/tests/net/net_common.sh P src/tests/net/arp/t_arp.sh P src/tests/net/ipsec/t_ipsec_misc.sh P src/tests/net/ndp/t_ndp.sh P src/usr.bin/make/main.c P src/usr.bin/make/make.1 Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Tue Jun 20 03:01:43 2017 SUP Scan for current completed at Tue Jun 20 03:02:04 2017 SUP Scan for mirror starting at Tue Jun 20 03:02:04 2017 SUP Scan for mirror completed at Tue Jun 20 03:04:58 2017 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 56460378 Jun 20 03:07 ls-lRA.gz
Re: HEADS-UP: /bin/sh memory management bug fixes committed
from Robert Elz: >Date:Mon, 19 Jun 2017 05:39:28 + > From:"Thomas Mueller" > Message-ID: <92.EA.01815.89367495@dnvrco-omsmta03> > | I suspect sh bug might have been at fault at least in part for > | pkg_rolling-replace strange behavior, > That is possible. > | "make deinstall install". > I generally do pkg_delete rather than make deinstall (had no idea such > an option existed). But otherwise, right. > | I have to consider the likelihood that many installed packages will no > | longer work after updating kernel and userland from 7.99.15 to 7.99.71 > | to 8.99.1 because shared libraries figure to be out of sync. > That should not be a problem, the only things that should need > recompiling are things that depend upon osabi - usually I think that is > far too strict, but in this case there's really no way it can know that > nothing much has changed since (at least high) 7.99.nn versions and 8.99.1 > There might be an isolated package that uses one of the rarer libraries > which might have been updated (particularly since 7.99.15) which you can > solve either by recompiling (it, and everything else it depends upon > which also might use the changed library) or you can just copy the > lib.so.N.M file from the old system to the new one (and perhaps > the libxxx.so.N symlink which points at that one - I've never been sure > exactly when that one is used). > Just beware of mixing object files (which includes .so files) compiled > and or linked using different versions of what is intended to be the same > thing. That leads to havoc. > Apart from that I regularly run ancient compiled packages on newer > systems, NetBSD people generally work very hard to make sure that remains > possible. > In fact, I usually compile all my packages against the N.0 RELEASE version > (for whichever NetBSD version (N) I am using at the time) - that way one > set of binary packages are all that are needed for all systems (of the same > architecture, naturally) whatever actual N.p.q version I actually install on > them.) I updated NetBSD-current i386 successfully, but running pkg_rolling-replace failed miserably. One barrier was package security/sudo, whether run from pkg_rolling-replace or from security/sudo directory: ln -s sudo.8 /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/man/man8/sudoedit.8 /bin/sh ../mkinstalldirs /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo for f in ./pam.conf ./sudo.conf ./sudoers ./syslog.conf; do /bin/sh ../install-sh -c -m 0644 $f /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo; done /usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/doc/UPGRADE /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/doc/sudo /usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/plugins/sudoers/sudoers /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo/sudoers /usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/README /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/doc/sudo => Automatic manual page handling => Generating post-install file lists /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/group_file.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB) /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/sudo_noexec.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB) /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/sudoers.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB) /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/system_group.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB) => Checking file-check results for sudo-1.8.20p2 ERROR: ERROR: The following files are in /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg but not in the PLIST: ERROR: /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/hu/LC_MESSAGES/sudo.mo ERROR: /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/ko/LC_MESSAGES/sudo.mo ERROR: /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/ko/LC_MESSAGES/sudoers.mo ERROR: /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/nn/LC_MESSAGES/sudo.mo *** Error code 1 Stop. make[2]: stopped in /BETA1/pkgsrc/security/sudo *** Error code 1 Stop. make[1]: stopped in /BETA1/pkgsrc/security/sudo *** Error code 1 Stop. make: stopped in /BETA1/pkgsrc/security/sudo I don't know if this would do any better on amd64. I suppose I could try editing the PLIST and then "make install"? But then I guess th
