daily CVS update output
Updating src tree: P src/lib/libc/sys/getvfsstat.2 P src/lib/libedit/filecomplete.c P src/lib/libedit/filecomplete.h P src/share/man/man4/usb.4 P src/sys/arch/aarch64/include/cpu.h P src/sys/arch/arm/include/cpu.h P src/sys/arch/arm/pic/pic.c P src/sys/arch/arm/pic/pic_splfuncs.c P src/sys/arch/arm/pic/picvar.h P src/sys/dev/vmt/vmt_subr.c P src/sys/dev/vmt/vmtvar.h P src/tests/usr.bin/xlint/lint1/d_c99_complex_split.c P src/tests/usr.bin/xlint/lint1/d_c99_init.c P src/tests/usr.bin/xlint/lint1/d_c99_init.exp P src/tests/usr.bin/xlint/lint1/d_cast_lhs.c P src/tests/usr.bin/xlint/lint1/d_ellipsis_in_switch.c P src/tests/usr.bin/xlint/lint1/d_gcc_compound_statements1.c P src/tests/usr.bin/xlint/lint1/d_nolimit_init.c P src/tests/usr.bin/xlint/lint1/t_integration.sh P src/usr.bin/xlint/common/emit.c P src/usr.bin/xlint/common/inittyp.c P src/usr.bin/xlint/common/tyname.c P src/usr.bin/xlint/lint1/decl.c P src/usr.bin/xlint/lint1/emit1.c P src/usr.bin/xlint/lint1/err.c P src/usr.bin/xlint/lint1/externs1.h P src/usr.bin/xlint/lint1/init.c P src/usr.bin/xlint/lint1/lex.c P src/usr.bin/xlint/lint1/lint1.h P src/usr.bin/xlint/lint1/main1.c P src/usr.bin/xlint/lint1/mem1.c P src/usr.bin/xlint/lint1/tree.c P src/usr.bin/xlint/lint2/msg.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 41367614 Mar 28 03:03 ls-lRA.gz
Re: -current tar(1) breakage
I didn't expect output, but I wanted to look at the pointer data. Does it contain 0xa5 now instead of other random strings? christos > On Mar 27, 2021, at 6:06 PM, Hauke Fath > wrote: > > On Sat, 27 Mar 2021 17:04:58 -0400, Christos Zoulas wrote: >> Maybe we are accessing freed memory? Can you run it with: >> >> env MALLOC_CONF='junk:true' > > No output: > > [hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > env MALLOC_CONF='junk:true' > tar -cf /dev/null . > Segmentation fault (core dumped) > [hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > > > -- > Hauke Fath > Linnéweg 7 > 64342 Seeheim-Jugenheim > Germany signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 17:04:58 -0400, Christos Zoulas wrote: > Maybe we are accessing freed memory? Can you run it with: > > env MALLOC_CONF='junk:true' No output: [hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > env MALLOC_CONF='junk:true' tar -cf /dev/null . Segmentation fault (core dumped) [hauke@i386-pxe] /<6>xemacs-21.4.24/lisp > -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
>> (gdb) print *cv
>> $1 = {cv_shared = 0x6c652e73, cv_closure = 0x761713184050}
>> (gdb) print *cv->shared
>> There is no member named shared.
>> (gdb) print *cv->cv_shared
>> Cannot access memory at address 0x6c652e73
>> (gdb) print *cv->cv_shared->ci_ops
>> Cannot access memory at address 0x6c652e73
>> (gdb)
>
> 0x6c652e73 == "s.el" (ascii) so it sounds like something
> uninitialized/overwritten.
Hmm... I thought there had been made progress to make the
address sanitizer feature of gcc and/or clang work on NetBSD?
(ref. "gcc -fsanitize=address")
However, my previous attempt at using that feature on netbsd-9
was unfortunately not met with success (I tried with gcc) -- I
ended up with "rpl_malloc()" as undefined -- we don't define that
but it's supposedly defined in a Linux-based environment...
I didn't try with clang for the program I was looking at, and
I've also not tried on -current.
In principle, tar ought to be a simpler program to get to run
than the multi-threaded program I was trying to get going...
Regards,
- Håvard
Re: -current tar(1) breakage
Maybe we are accessing freed memory? Can you run it with:
env MALLOC_CONF='junk:true'
christos
> On Mar 27, 2021, at 1:51 PM, Anders Magnusson wrote:
>
>
>> (gdb) print *cv
>> $1 = {cv_shared = 0x6c652e73, cv_closure = 0x761713184050}
>> (gdb) print *cv->shared
>> There is no member named shared.
>> (gdb) print *cv->cv_shared
>> Cannot access memory at address 0x6c652e73
>> (gdb) print *cv->cv_shared->ci_ops
>> Cannot access memory at address 0x6c652e73
>> (gdb)
>
> 0x6c652e73 == "s.el" (ascii) so it sounds like something
> uninitialized/overwritten.
>
> -- R
signature.asc
Description: Message signed with OpenPGP
re: -current tar(1) breakage
> Joerg thinks that this is an nfs issue (a bug with nfs giving incorrect data). even if true, tar shouldn't *core dump*. is there a path to RCE here some where? it's clearly overwriting pointers with strings, so unless someone can clearly show there is no code exec vector here, it seems potentially problematic and should be fixed. .mrg.
Wireguard
Hi, In the light of the recent Wireguard vs. FreeBSD 13 shenanigans, what is the present thinking about the in-kernel NetBSD implementation? I beg your pardon if I have missed some discussion here or elsewhere. Chavdar --
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 18:02:32 +0100, Hauke Fath wrote: > On Sat, 27 Mar 2021 12:27:20 -0400, Christos Zoulas wrote: >> Joerg thinks that this is an nfs issue (a bug with nfs giving >> incorrect data). > > Doesn't do that in other locations, though: [/var/tmp] Maybe it does: [hauke@i386-pxe] /var/log > tar -cvf /dev/null . a . a ./rdist a ./amdlog a ./authlog[hauke@i386-pxe] /var/log > -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
(gdb) print *cv
$1 = {cv_shared = 0x6c652e73, cv_closure = 0x761713184050}
(gdb) print *cv->shared
There is no member named shared.
(gdb) print *cv->cv_shared
Cannot access memory at address 0x6c652e73
(gdb) print *cv->cv_shared->ci_ops
Cannot access memory at address 0x6c652e73
(gdb)
0x6c652e73 == "s.el" (ascii) so it sounds like something
uninitialized/overwritten.
-- R
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 12:27:20 -0400, Christos Zoulas wrote:
> Joerg thinks that this is an nfs issue (a bug with nfs giving
> incorrect data).
Doesn't do that in other locations, though:
[hauke@i386-pxe] /var/tmp > tar -cvf /dev/null .
a .
a ./vi.recover
a ./pkg_rr.out
a ./pizza-etc.tgz
[hauke@i386-pxe] /var/tmp >
> Nevertheless can you
>
> print *cv,
> print *cv->shared
> print *cv->shared->ci_ops
(gdb) print *cv
$1 = {cv_shared = 0x6c652e73, cv_closure = 0x761713184050}
(gdb) print *cv->shared
There is no member named shared.
(gdb) print *cv->cv_shared
Cannot access memory at address 0x6c652e73
(gdb) print *cv->cv_shared->ci_ops
Cannot access memory at address 0x6c652e73
(gdb)
Cheerio,
Hauke
--
Hauke Fath
Linnéweg 7
64342 Seeheim-Jugenheim
Germany
Re: -current tar(1) breakage
Joerg thinks that this is an nfs issue (a bug with nfs giving incorrect data). Nevertheless can you print *cv, print *cv->shared print *cv->shared->ci_ops Thanks, christos > On Mar 27, 2021, at 12:12 PM, Hauke Fath > wrote: > > On Sat, 27 Mar 2021 09:22:16 -0400, Christos Zoulas wrote: >> Can't you just download the pre-build ones? Assuming you are using >> reproducible builds, we might get lucky? > > [...] > Reading symbols from /bin/tar... > Reading symbols from /usr/libdata/debug//bin/tar.debug... > [New process 10317] > Core was generated by `tar'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x7f0a03467866 in _citrus_iconv_convert > (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, > out=0x7f7fff902d90, >inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at > /usr/src/lib/libc/citrus/citrus_iconv.h:61 > 61_DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops && > (gdb) bt > #0 0x7f0a03467866 in _citrus_iconv_convert > (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, > out=0x7f7fff902d90, >inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at > /usr/src/lib/libc/citrus/citrus_iconv.h:61 > #1 _iconv (handle=handle@entry=0x7f0a057c40e0, > in=in@entry=0x7f7fff902d80, szin=szin@entry=0x7f7fff902d88, > out=out@entry=0x7f7fff902d90, >szout=szout@entry=0x7f7fff902d98) at > /usr/src/lib/libc/iconv/iconv.c:97 > #2 0x7f0a05483834 in iconv_strncat_in_locale (as=0x7f0a05762158, > _p=, length=, sc=0x7f0a056eb000) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:2039 > #3 0x7f0a054844ba in archive_strncat_l > (as=as@entry=0x7f0a05762158, _p=, n=, > sc=) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:1998 > #4 0x7f0a0548459a in archive_strncpy_l > (as=as@entry=0x7f0a05762158, _p=, n=, > sc=) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:1944 > #5 0x7f0a054847d9 in archive_mstring_get_mbs_l > (aes=0x7f0a05762110, p=0x7f7fff902eb8, length=0x7f7fff902ee8, > sc=) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:4005 > #6 0x7f0a0547b810 in _archive_entry_pathname_l (entry= out>, p=, len=, sc=) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_entry.c:598 > #7 0x7f0a0541f051 in get_entry_pathname (a=0x7f0a057b6000, > entry=, name=, length=, >sc=) at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_write_set_format_pax.c:428 > #8 0x7f0a0541f5da in archive_write_pax_header (a=0x7f0a057b6000, > entry_original=0x7f0a05761500) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_write_set_format_pax.c:839 > #9 0x7f0a0546a1da in _archive_write_header (_a=0x7f0a057b6000, > entry=0x7f0a05761500) >at > /usr/src/external/bsd/libarchive/dist/libarchive/archive_write.c:650 > #10 0x7b008ac2 in write_entry > (bsdtar=bsdtar@entry=0x7f7fff9037f0, a=a@entry=0x7f0a057b6000, > entry=0x7f0a05761500) >at /usr/src/external/bsd/libarchive/dist/tar/write.c:974 > #11 0x7b008cac in write_file (entry=, > a=0x7f0a057b6000, bsdtar=0x7f7fff9037f0) >at /usr/src/external/bsd/libarchive/dist/tar/write.c:962 > #12 write_hierarchy (bsdtar=bsdtar@entry=0x7f7fff9037f0, > a=a@entry=0x7f0a057b6000, path=path@entry=0x7f7fff9042f2 ".") >at /usr/src/external/bsd/libarchive/dist/tar/write.c:941 > #13 0x7b00907e in write_archive (a=a@entry=0x7f0a057b6000, > bsdtar=bsdtar@entry=0x7f7fff9037f0) >at /usr/src/external/bsd/libarchive/dist/tar/write.c:513 > #14 0x7b0098a4 in tar_mode_c > (bsdtar=bsdtar@entry=0x7f7fff9037f0) at > /usr/src/external/bsd/libarchive/dist/tar/write.c:247 > #15 0x7b00ba4d in main (argc=, argv= out>) at /usr/src/external/bsd/libarchive/dist/tar/bsdtar.c:910 > (gdb) > > HTH, > Hauke > > -- > Hauke Fath > Linnéweg 7 > 64342 Seeheim-Jugenheim > Germany signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 09:22:16 -0400, Christos Zoulas wrote: > Can't you just download the pre-build ones? Assuming you are using > reproducible builds, we might get lucky? Running 'ktrace -di tar -cf /dev/null .' from the same directory (ditors/xemacs-nox11/work/xemacs-21.4.24/lisp): % kdump [...] 14308 14308 tar GIO fd 8 read 1728 bytes ";;; msw-select.el --- Lisp interface to mswindows selections.\n\n;; Copyright (C) 1990, 1997 Free Software Foundation, Inc.\n;; Copyright (C) \ 1995 Sun Microsystems.\n\n;; Maintainer: XEmacs Development Team\n;; Keywords: extensions, dumped\n\n;; This file is part of XEmacs.\n\n;; XEm\ acs is free software; you can redistribute it and/or modify it\n;; under the terms of the GNU General Public License as published by\n;; the F\ ree Software Foundation; either version 2, or (at your option)\n;; any later version.\n\n;; XEmacs is distributed in the hope that it will be \ useful, but\n;; WITHOUT ANY WARRANTY; without even the implied warranty of\n;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the G\ NU\n;; General Public License for more details.\n\n;; You should have received a copy of the GNU General Public License\n;; along with XEmacs;\ see the file COPYING. If not, write to the \n;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,\n;; Boston, MA 02111-1307, USA.\ \n\n;;; Synched up with: Not in FSF\n\n;;; Commentary:\n\n;; This file is dumped with XEmacs (when mswindows support is compiled in).\n;; \ Only copes with copying/pasting text\n\n;;; Code:\n\n(defun mswindows-paste-clipboard ()\n \"Insert the current contents of the mswindows cl\ ipboard at point,\nreplacing the active selection if there is one.\"\n (interactive \"*\")\n (setq last-command nil)\n (setq this-command '\ yank) ; so that yank-pop works.\n (let ((clip (get-clipboard)) (s (mark-marker)) (e (point-marker)))\n(or clip (error \"there is no text \ on the clipboard\"))\n(if s\n (if mouse-track-rectangle-p\n (delete-rectangle s e)\n (delete-region s e)))\n(push-mar\ k)\n(if mouse-track-rectangle-p\n (insert-rectangle clip)\n (insert clip\n\n\n\n\n" 14308 14308 tar RET read 1728/0x6c0 14308 14308 tar CALL close(8) 14308 14308 tar RET close 0 14308 14308 tar CALL fstatat(6,0x761713209062,0x76171320a300,0x200) 14308 14308 tar NAMI "gtk-widget-accessors.el" 14308 14308 tar RET fstatat 0 14308 14308 tar CALL fchdir(6) 14308 14308 tar RET fchdir 0 14308 14308 tar CALL openat(6,0x761713209100,4,0x761710eb0c9a) 14308 14308 tar NAMI "gtk-widget-accessors.el" 14308 14308 tar RET openat 8 14308 14308 tar CALL __acl_get_fd(8,4,0x761712de2000) 14308 14308 tar RET __acl_get_fd -1 errno 45 Operation not supported 14308 14308 tar CALL __acl_get_fd(8,2,0x7617130d8000) 14308 14308 tar RET __acl_get_fd -1 errno 45 Operation not supported 14308 14308 tar CALL extattr_list_fd(8,1,0,0) 14308 14308 tar RET extattr_list_fd -1 errno 45 Operation not supported 14308 14308 tar CALL close(8) 14308 14308 tar RET close 0 14308 14308 tar CALL fchdir(4) 14308 14308 tar RET fchdir 0 14308 14308 tar PSIG SIGSEGV SIG_DFL: code=SEGV_MAPERR, addr=0x6c652e73, trap=6) 14308 14308 tar NAMI "tar.core" % -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: -current tar(1) breakage
On Sat, 27 Mar 2021 09:22:16 -0400, Christos Zoulas wrote: > Can't you just download the pre-build ones? Assuming you are using > reproducible builds, we might get lucky? [...] Reading symbols from /bin/tar... Reading symbols from /usr/libdata/debug//bin/tar.debug... [New process 10317] Core was generated by `tar'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7f0a03467866 in _citrus_iconv_convert (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, out=0x7f7fff902d90, inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at /usr/src/lib/libc/citrus/citrus_iconv.h:61 61 _DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops && (gdb) bt #0 0x7f0a03467866 in _citrus_iconv_convert (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98, out=0x7f7fff902d90, inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at /usr/src/lib/libc/citrus/citrus_iconv.h:61 #1 _iconv (handle=handle@entry=0x7f0a057c40e0, in=in@entry=0x7f7fff902d80, szin=szin@entry=0x7f7fff902d88, out=out@entry=0x7f7fff902d90, szout=szout@entry=0x7f7fff902d98) at /usr/src/lib/libc/iconv/iconv.c:97 #2 0x7f0a05483834 in iconv_strncat_in_locale (as=0x7f0a05762158, _p=, length=, sc=0x7f0a056eb000) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:2039 #3 0x7f0a054844ba in archive_strncat_l (as=as@entry=0x7f0a05762158, _p=, n=, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:1998 #4 0x7f0a0548459a in archive_strncpy_l (as=as@entry=0x7f0a05762158, _p=, n=, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:1944 #5 0x7f0a054847d9 in archive_mstring_get_mbs_l (aes=0x7f0a05762110, p=0x7f7fff902eb8, length=0x7f7fff902ee8, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_string.c:4005 #6 0x7f0a0547b810 in _archive_entry_pathname_l (entry=, p=, len=, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_entry.c:598 #7 0x7f0a0541f051 in get_entry_pathname (a=0x7f0a057b6000, entry=, name=, length=, sc=) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_write_set_format_pax.c:428 #8 0x7f0a0541f5da in archive_write_pax_header (a=0x7f0a057b6000, entry_original=0x7f0a05761500) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_write_set_format_pax.c:839 #9 0x7f0a0546a1da in _archive_write_header (_a=0x7f0a057b6000, entry=0x7f0a05761500) at /usr/src/external/bsd/libarchive/dist/libarchive/archive_write.c:650 #10 0x7b008ac2 in write_entry (bsdtar=bsdtar@entry=0x7f7fff9037f0, a=a@entry=0x7f0a057b6000, entry=0x7f0a05761500) at /usr/src/external/bsd/libarchive/dist/tar/write.c:974 #11 0x7b008cac in write_file (entry=, a=0x7f0a057b6000, bsdtar=0x7f7fff9037f0) at /usr/src/external/bsd/libarchive/dist/tar/write.c:962 #12 write_hierarchy (bsdtar=bsdtar@entry=0x7f7fff9037f0, a=a@entry=0x7f0a057b6000, path=path@entry=0x7f7fff9042f2 ".") at /usr/src/external/bsd/libarchive/dist/tar/write.c:941 #13 0x7b00907e in write_archive (a=a@entry=0x7f0a057b6000, bsdtar=bsdtar@entry=0x7f7fff9037f0) at /usr/src/external/bsd/libarchive/dist/tar/write.c:513 #14 0x7b0098a4 in tar_mode_c (bsdtar=bsdtar@entry=0x7f7fff9037f0) at /usr/src/external/bsd/libarchive/dist/tar/write.c:247 #15 0x7b00ba4d in main (argc=, argv=) at /usr/src/external/bsd/libarchive/dist/tar/bsdtar.c:910 (gdb) HTH, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
Re: firefox in VNC: firefox.core
I wrote: >Thomas Klausner wrote: >>For a couple days/weeks now, whenever I start firefox >>86.0.1/NetBSD-9.99.81/amd64 in a vnc window, I see: >> >>Crash Annotation GraphicsCriticalError: [0][GFX1-]: No GPUs detected via PCI >>(t=0.228558) [GFX-1]: No GPUs detected via PCI >>Crash Annotation Graphicscriticalerror: [0][GFX1-]: No GPUs detected via PCI >>(t=0.228558) [1][GFX1-]: glxtest: process failed (received signal 11) >>(t=0.228639) [GFX1-]: glxtest: process failed (received signal 11) >> >>Except for that warning (and the core dump), firefox seems to work fine. > >The glxtest() function gets run in a forked copy of Firefox, it is the >fork that is dumping core. > >Maybe our pthreads implementation doesn't work across a fork(2). > >I thought that use of TLS had been turned off in Mesa though. > >I had some local patches to disable all of this but the source changed >so they would no longer apply, they disabled WebGL completely. Another approach could be to patch Firefox to disable the call to glxtest() but hard-code it to thinking that the test succeded.
Re: firefox in VNC: firefox.core
Thomas Klausner wrote: >For a couple days/weeks now, whenever I start firefox >86.0.1/NetBSD-9.99.81/amd64 in a vnc window, I see: > >Crash Annotation GraphicsCriticalError: [0][GFX1-]: No GPUs detected via PCI >(t=0.228558) [GFX-1]: No GPUs detected via PCI >Crash Annotation Graphicscriticalerror: [0][GFX1-]: No GPUs detected via PCI >(t=0.228558) [1][GFX1-]: glxtest: process failed (received signal 11) >(t=0.228639) [GFX1-]: glxtest: process failed (received signal 11) > >Except for that warning (and the core dump), firefox seems to work fine. The glxtest() function gets run in a forked copy of Firefox, it is the fork that is dumping core. Maybe our pthreads implementation doesn't work across a fork(2). I thought that use of TLS had been turned off in Mesa though. I had some local patches to disable all of this but the source changed so they would no longer apply, they disabled WebGL completely.
Re: -current tar(1) breakage
Can't you just download the pre-build ones? Assuming you are using reproducible builds, we might get lucky? christos > On Mar 27, 2021, at 9:09 AM, Hauke Fath > wrote: > > On Fri, 26 Mar 2021 20:08:40 +0100, Hauke Fath wrote: >> On Fri, 26 Mar 2021 14:41:56 -0400, Christos Zoulas wrote: >>> Can you install the debug sets? >> >> Will do - have to build them first, though. > > Sorry, the build died. It wants more than 20 GB for objects, which I > currently don't have on that machine... > > Cheerio, > Hauke > > -- > Hauke Fath > Linnéweg 7 > 64342 Seeheim-Jugenheim > Germany signature.asc Description: Message signed with OpenPGP
Re: -current tar(1) breakage
On Fri, 26 Mar 2021 20:08:40 +0100, Hauke Fath wrote: > On Fri, 26 Mar 2021 14:41:56 -0400, Christos Zoulas wrote: >> Can you install the debug sets? > > Will do - have to build them first, though. Sorry, the build died. It wants more than 20 GB for objects, which I currently don't have on that machine... Cheerio, Hauke -- Hauke Fath Linnéweg 7 64342 Seeheim-Jugenheim Germany
zero bytes in files written to NFS
Hi! For a few months now (at least since November) I see broken files when writing from NetBSD-current/amd64 to a Synology (Linux) file server via NFS. I don't have a completely reliable way to reproduce this, but it happens quite a lot when I run pkgsrc/archivers/torrentzip on large files (1-50GB) on file systems that are mounted via NFS. (The torrentzip tool reads the complete zip archive and replaces it with particular zlib settings and zip metadata.) I thought it could be a problem with the NFS server, but I've replaced the server hardware, and it still happens. I thought it could be a bug in the torrentzip tool, but it also happens (very rarely) when downloading files using filezilla (sftp) from a remote server directly to the NFS mounted device. The breakage always looks the same way - a block of zero (NUL) bytes in the middle of the file. The amounts differ, but usually it's a couple of kB of zeroes. So far I have not noticed this issue on local file systems. So I assume it's a bug in NFS and/or UVM. Has anyone else seen something similar? Thomas
firefox in VNC: firefox.core
Hi! For a couple days/weeks now, whenever I start firefox 86.0.1/NetBSD-9.99.81/amd64 in a vnc window, I see: Crash Annotation GraphicsCriticalError: [0][GFX1-]: No GPUs detected via PCI (t=0.228558) [GFX-1]: No GPUs detected via PCI Crash Annotation Graphicscriticalerror: [0][GFX1-]: No GPUs detected via PCI (t=0.228558) [1][GFX1-]: glxtest: process failed (received signal 11) (t=0.228639) [GFX1-]: glxtest: process failed (received signal 11) Except for that warning (and the core dump), firefox seems to work fine. The firefox.core backtrace looks like this: Core was generated by `firefox'. Program terminated with signal SIGSEGV, Segmentation fault. #0 pthread_mutex_lock (ptm=ptm@entry=0x7e9f071b4728) at /usr/src/lib/libpthread/pthread_mutex.c:204 204 pthread__error(EINVAL, "Invalid mutex", [Current thread is 1 (process 856)] (gdb) bt #0 pthread_mutex_lock (ptm=ptm@entry=0x7e9f071b4728) at /usr/src/lib/libpthread/pthread_mutex.c:204 #1 0x7e9ee08be731 in mtx_lock (mtx=0x7e9f071b4728) at /usr/xsrc/external/mit/MesaLib/dist/include/c11/threads_posix.h:223 #2 simple_mtx_lock (mtx=0x7e9f071b4728) at /usr/xsrc/external/mit/MesaLib/dist/src/util/simple_mtx.h:125 #3 _mesa_error (ctx=ctx@entry=0x7e9f071a2870, error=error@entry=1282, fmtString=fmtString@entry=0x7e9ee2c2ba5c "Inside glBegin/glEnd") at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/errors.c:309 #4 0x7e9ee08d8827 in _mesa_GetString (name=) at /usr/xsrc/external/mit/MesaLib/dist/src/mesa/main/getstring.c:124 #5 0x7e9ef30a1ab7 in get_gles_status (eglGetProcAddress=0x7e9ee5812863 , dpy=0x7e9f070e5000) at /scratch/www/firefox/work/firefox-86.0.1/toolkit/xre/glxtest.cpp:486 #6 get_egl_status (native_dpy=native_dpy@entry=0x0, gles_test=gles_test@entry=true) at /scratch/www/firefox/work/firefox-86.0.1/toolkit/xre/glxtest.cpp:574 #7 0x7e9ef30a3bf4 in glxtest () at /scratch/www/firefox/work/firefox-86.0.1/toolkit/xre/glxtest.cpp:810 #8 childgltest () at /scratch/www/firefox/work/firefox-86.0.1/toolkit/xre/glxtest.cpp:1176 #9 0x7e9ef30a3e6b in fire_glxtest_process () at /scratch/www/firefox/work/firefox-86.0.1/toolkit/xre/glxtest.cpp:1213 #10 0x7e9ef3095f02 in XREMain::XRE_mainInit (this=0x7f7fffa23a10, aExitFlag=0x7f7fffa239a0) at /scratch/www/firefox/work/firefox-86.0.1/toolkit/xre/nsAppRunner.cpp:3542 #11 0x7e9ef309e92b in XREMain::XRE_main (this=0x7f7fffa23a10, argc=, argv=, aConfig=...) at /scratch/www/firefox/work/firefox-86.0.1/toolkit/xre/nsAppRunner.cpp:5331 #12 0x7e9ef309efc3 in XRE_main (argc=1, argv=0x7f7fffa23c18, aConfig=...) at /scratch/www/firefox/work/firefox-86.0.1/toolkit/xre/nsAppRunner.cpp:5417 #13 0x0001de806e8c in do_main (envp=, argv=, argc=) at /scratch/www/firefox/work/firefox-86.0.1/browser/app/nsBrowserApp.cpp:220 #14 main (argc=, argv=, envp=) at /scratch/www/firefox/work/firefox-86.0.1/browser/app/nsBrowserApp.cpp:344 (gdb) Is this a bug in Mesa without acceleration? Thomas
