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 2020.06.30.00.26.12. An extract from the build.sh output follows: cat /tmp/bracket/build/2020.06.30.00.26.12-i386/src/tests/bin/sh/t_redircloexec.sh >>t_redircloexec.tmp chmod +x t_redircloexec.tmp mv -f t_redircloexec.tmp t_redircloexec --- t_set_e --- # build sh/t_set_e echo '#! /usr/bin/atf-sh' >t_set_e.tmp cat /tmp/bracket/build/2020.06.30.00.26.12-i386/src/tests/bin/sh/t_set_e.sh >>t_set_e.tmp chmod +x t_set_e.tmp mv -f t_set_e.tmp t_set_e --- t_shift --- # build sh/t_shift echo '#! /usr/bin/atf-sh' >t_shift.tmp cat /tmp/bracket/build/2020.06.30.00.26.12-i386/src/tests/bin/sh/t_shift.sh >>t_shift.tmp chmod +x t_shift.tmp --- dependall-dev --- cc1: all warnings being treated as errors --- dependall-bin --- mv -f t_shift.tmp t_shift --- t_syntax --- --- dependall-dev --- *** [t_cgd_adiantum.o] Error code 1 --- dependall-share --- --- ucs%georgian-acad...@oldcapital.mps --- The following commits were made between the last successful build and the failed build: 2020.06.29.23.31.41 riastradh src/sys/arch/aarch64/aarch64/cpu.c,v 1.49 2020.06.29.23.31.41 riastradh src/sys/arch/aarch64/conf/files.aarch64,v 1.23 2020.06.29.23.31.41 riastradh src/sys/crypto/aes/arch/arm/aes_armv8.c,v 1.1 2020.06.29.23.31.41 riastradh src/sys/crypto/aes/arch/arm/aes_armv8.h,v 1.1 2020.06.29.23.31.41 riastradh src/sys/crypto/aes/arch/arm/aes_armv8_64.S,v 1.1 2020.06.29.23.31.41 riastradh src/sys/crypto/aes/arch/arm/files.aesarmv8,v 1.1 2020.06.29.23.32.24 riastradh src/sys/arch/i386/conf/files.i386,v 1.404 2020.06.29.23.32.24 riastradh src/sys/arch/i386/pci/glxsb.c,v 1.16 2020.06.29.23.33.05 riastradh src/sys/conf/files,v 1.1270 2020.06.29.23.33.05 riastradh src/sys/dev/cgd_crypto.c,v 1.24 2020.06.29.23.33.46 riastradh src/sys/uvm/files.uvm,v 1.35 2020.06.29.23.33.46 riastradh src/sys/uvm/uvm_swap.c,v 1.194 2020.06.29.23.34.48 riastradh src/sys/opencrypto/aesxcbcmac.c,v 1.3 2020.06.29.23.34.48 riastradh src/sys/opencrypto/aesxcbcmac.h,v 1.2 2020.06.29.23.34.48 riastradh src/sys/opencrypto/cryptosoft.c,v 1.56 2020.06.29.23.34.48 riastradh src/sys/opencrypto/cryptosoft_xform.c,v 1.29 2020.06.29.23.34.48 riastradh src/sys/opencrypto/files.opencrypto,v 1.30 2020.06.29.23.34.48 riastradh src/sys/opencrypto/gmac.c,v 1.4 2020.06.29.23.34.48 riastradh src/sys/opencrypto/gmac.h,v 1.3 2020.06.29.23.34.48 riastradh src/sys/opencrypto/xform.c,v 1.30 2020.06.29.23.35.26 riastradh src/sys/dev/cgd.c,v 1.136 2020.06.29.23.36.06 riastradh src/sys/dev/cgd.c,v 1.137 2020.06.29.23.36.06 riastradh src/sys/dev/cgd_crypto.c,v 1.25 2020.06.29.23.36.06 riastradh src/sys/dev/cgd_crypto.h,v 1.13 2020.06.29.23.36.59 riastradh src/sys/crypto/aes/aes_bear.h,v 1.2 2020.06.29.23.36.59 riastradh src/sys/crypto/aes/aes_ct.c,v 1.2 2020.06.29.23.36.59 riastradh src/sys/crypto/aes/aes_ct_dec.c,v 1.2 2020.06.29.23.36.59 riastradh src/sys/crypto/aes/aes_impl.c,v 1.2 2020.06.29.23.38.02 riastradh src/sys/arch/x86/conf/files.x86,v 1.113 2020.06.29.23.38.02 riastradh src/sys/arch/x86/include/via_padlock.h,v 1.10 2020.06.29.23.38.02 riastradh src/sys/arch/x86/x86/via_padlock.c,v 1.30 2020.06.29.23.39.30 riastradh src/sys/arch/x86/conf/files.x86,v 1.114 2020.06.29.23.39.30 riastradh src/sys/arch/x86/x86/identcpu.c,v 1.109 2020.06.29.23.39.30 riastradh src/sys/crypto/aes/arch/x86/aes_via.c,v 1.1 2020.06.29.23.39.30 riastradh src/sys/crypto/aes/arch/x86/aes_via.h,v 1.1 2020.06.29.23.39.30 riastradh src/sys/crypto/aes/arch/x86/files.aesvia,v 1.1 2020.06.29.23.40.28 riastradh src/sys/uvm/uvm_swap.c,v 1.195 2020.06.29.23.41.35 riastradh src/sys/crypto/aes/arch/x86/aes_via.c,v 1.2 2020.06.29.23.44.01 riastradh src/distrib/sets/lists/debug/mi,v 1.320 2020.06.29.23.44.01 riastradh src/distrib/sets/lists/tests/mi,v 1.863 2020.06.29.23.44.01 riastradh src/sys/conf/files,v 1.1271 2020.06.29.23.44.01 riastradh src/sys/crypto/adiantum/adiantum.c,v 1.1 2020.06.29.23.44.01 riastradh src/sys/crypto/adiantum/adiantum.h,v 1.1 2020.06.29.23.44.01 riastradh src/sys/crypto/adiantum/adiantum_selftest.c,v 1.1 2020.06.29.23.44.01 riastradh src/sys/crypto/adiantum/files.adiantum,v 1.1 2020.06.29.23.44.01 riastradh src/sys/dev/cgd_crypto.c,v 1.26 2020.06.29.23.44.01 riastradh src/sys/rump/kern/lib/libcrypto/Makefile,v 1.8 2020.06.29.23.44.01 riastradh src/tests/dev/cgd/Makefile,v 1.11 2020.06.29.23.44.01 riastradh src/tests/dev/cgd/t_cgd_adiantum.c,v 1.1 2020.06.29.23.47.54 riastradh src/sys/arch/x86/conf/files.x86,v 1.115 2020.06.29.23.47.54 riastradh src/sys/arch/x86/x86/identcpu.c,v 1.110
Re: atexit(), dlclose() and more atexit()
> On Jun 29, 2020, at 5:13 PM, Kamil Rytarowski wrote: > >> >> The atexit() function shall register the function pointed to by func, to be >> called without arguments at normal program termination. At normal program >> termination, all functions registered by the atexit() function shall be >> called, in the reverse order of their registration, except that a function >> is called after any previously registered functions that had already been >> called at the time it was registered. Normal termination occurs either by a >> call to exit() or a return from main(). >> >> >> My reading of the standard here is that atexit() handlers are called at >> "normal program termination", and that "normal program termination" is >> explicitly defined as either a call to exit() or returning from main(), and >> thus any other call to atexit() handlers is expressly forbidden by the >> standard. >> > > There is no word "only", so it's unspecified. Sorry, but that seems like a huge stretch. Everything seems tied to the process "exit" path in the description of atexit(). Even in the APPLICATION USAGE section, they have the following informative text: All functions registered by the atexit() function are called at normal process termination, which occurs by a call to the exit() function or a return from main() or on the last thread termination, when the behavior is as if the implementation called exit() with a zero argument at thread termination time. ...specifically, the "is as if" qualifier. In my reading, if the enclosing program is not terminating, then atexit() handlers should not be called. dlclose() does not initiate "normal program termination" (it's also specified in Issue 7, so I double-checked!), nor does it mention anything about being considered "normal program termination" from the perspective of the shared object that is being closed. Can you point to another place in the standard that uses the "only" type wording to justify your reading of atexit()? -- thorpej
daily CVS update output
Updating src tree: P src/distrib/sets/lists/debug/mi P src/distrib/sets/lists/tests/mi P src/doc/CHANGES P src/external/bsd/kyua-cli/tests/kyua-cli/bootstrap/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/cli/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/engine/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/engine/drivers/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/examples/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/integration/helpers/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/store/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/cmdline/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/config/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/format/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/fs/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/logging/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/process/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/signals/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/sqlite/Makefile P src/external/bsd/kyua-cli/tests/kyua-cli/utils/text/Makefile P src/external/gpl3/gcc/usr.bin/cc1/Makefile P src/external/gpl3/gcc/usr.bin/cc1obj/Makefile P src/external/gpl3/gcc/usr.bin/cc1plus/Makefile P src/external/gpl3/gcc/usr.bin/lto-wrapper/Makefile P src/share/wscons/fonts/spleen-5x8.fnt.uue P src/sys/arch/aarch64/aarch64/cpu.c P src/sys/arch/aarch64/aarch64/fpu.c P src/sys/arch/aarch64/conf/files.aarch64 P src/sys/arch/aarch64/include/cpu.h P src/sys/arch/aarch64/include/machdep.h P src/sys/arch/amd64/amd64/amd64_trap.S P src/sys/arch/amd64/conf/ALL P src/sys/arch/amd64/include/param.h P src/sys/arch/arm/arm32/cpu.c P src/sys/arch/arm/conf/files.arm P src/sys/arch/arm/include/cpu.h U src/sys/arch/arm/include/fpu.h P src/sys/arch/arm/vfp/vfp_init.c P src/sys/arch/i386/conf/files.i386 P src/sys/arch/i386/pci/glxsb.c P src/sys/arch/ia64/include/mcontext.h P src/sys/arch/powerpc/ibm4xx/pmap.c P src/sys/arch/x86/conf/files.x86 P src/sys/arch/x86/include/via_padlock.h P src/sys/arch/x86/x86/identcpu.c P src/sys/arch/x86/x86/via_padlock.c P src/sys/arch/xen/xen/xbd_xenbus.c P src/sys/conf/files U src/sys/crypto/adiantum/adiantum.c U src/sys/crypto/adiantum/adiantum.h U src/sys/crypto/adiantum/adiantum_selftest.c U src/sys/crypto/adiantum/files.adiantum U src/sys/crypto/aes/aes.h U src/sys/crypto/aes/aes_bear.c U src/sys/crypto/aes/aes_bear.h U src/sys/crypto/aes/aes_ct.c U src/sys/crypto/aes/aes_ct_dec.c U src/sys/crypto/aes/aes_ct_enc.c U src/sys/crypto/aes/aes_impl.c U src/sys/crypto/aes/aes_rijndael.c U src/sys/crypto/aes/aes_selftest.c U src/sys/crypto/aes/files.aes U src/sys/crypto/aes/arch/arm/aes_armv8.c U src/sys/crypto/aes/arch/arm/aes_armv8.h U src/sys/crypto/aes/arch/arm/aes_armv8_64.S U src/sys/crypto/aes/arch/arm/aes_neon.c U src/sys/crypto/aes/arch/arm/aes_neon.h U src/sys/crypto/aes/arch/arm/aes_neon_32.S U src/sys/crypto/aes/arch/arm/aes_neon_impl.c U src/sys/crypto/aes/arch/arm/aes_neon_impl.h U src/sys/crypto/aes/arch/arm/aes_neon_subr.c U src/sys/crypto/aes/arch/arm/arm_neon.h U src/sys/crypto/aes/arch/arm/files.aesarmv8 U src/sys/crypto/aes/arch/arm/files.aesneon U src/sys/crypto/aes/arch/x86/aes_ni.c U src/sys/crypto/aes/arch/x86/aes_ni.h U src/sys/crypto/aes/arch/x86/aes_ni_64.S U src/sys/crypto/aes/arch/x86/aes_sse2.c U src/sys/crypto/aes/arch/x86/aes_sse2.h U src/sys/crypto/aes/arch/x86/aes_sse2_dec.c U src/sys/crypto/aes/arch/x86/aes_sse2_enc.c U src/sys/crypto/aes/arch/x86/aes_sse2_impl.c U src/sys/crypto/aes/arch/x86/aes_sse2_impl.h U src/sys/crypto/aes/arch/x86/aes_sse2_subr.c U src/sys/crypto/aes/arch/x86/aes_ssse3.c U src/sys/crypto/aes/arch/x86/aes_ssse3.h U src/sys/crypto/aes/arch/x86/aes_ssse3_impl.c U src/sys/crypto/aes/arch/x86/aes_ssse3_impl.h U src/sys/crypto/aes/arch/x86/aes_ssse3_subr.c U src/sys/crypto/aes/arch/x86/aes_via.c U src/sys/crypto/aes/arch/x86/aes_via.h U src/sys/crypto/aes/arch/x86/files.aesni U src/sys/crypto/aes/arch/x86/files.aessse2 U src/sys/crypto/aes/arch/x86/files.aee3 U src/sys/crypto/aes/arch/x86/files.aesvia U src/sys/crypto/aes/arch/x86/immintrin.h U src/sys/crypto/aes/arch/x86/immintrin_ext.h cvs update: `src/sys/crypto/rijndael/files.rijndael' is no longer in the repository cvs update: `src/sys/crypto/rijndael/rijndael-alg-fst.c' is no longer in the repository cvs update: `src/sys/crypto/rijndael/rijndael-api-fst.c' is no longer in the repository cvs update: `src/sys/crypto/rijndael/rijndael.c' is no longer in the repository cvs update: `src/sys/crypto/rijndael/rijndael_local.h' is no longer in the repository P src/sys/dev/cgd.c P src/sys/dev/cgd_crypto.c P src/sys/dev/cgd_crypto.h P src/sys/dev/i2c/sdtemp.c P src/sys/dev/microcode/aic7xxx/Makefile P src/sys/dev/scsipi/if_se.c P src/sys/dev/wsfont/spleen5x8.h P src/sys/opencrypto/aesxcbcmac.c P src/sys/opencrypto/aesxcbcmac.h P src/sys/opencrypto/cryptosoft.c P
Re: atexit(), dlclose() and more atexit()
On 29.06.2020 21:36, Jason Thorpe wrote: > >> On Jun 29, 2020, at 9:09 AM, Rhialto wrote: >> >> But I wonder if there is any standards text that >> describes whether this particular scenario is supposed to work. > > Quoting from "The Open Group Base Specifications Issue 7, 2018 edition" > > > The atexit() function shall register the function pointed to by func, to be > called without arguments at normal program termination. At normal program > termination, all functions registered by the atexit() function shall be > called, in the reverse order of their registration, except that a function is > called after any previously registered functions that had already been called > at the time it was registered. Normal termination occurs either by a call to > exit() or a return from main(). > > > My reading of the standard here is that atexit() handlers are called at > "normal program termination", and that "normal program termination" is > explicitly defined as either a call to exit() or returning from main(), and > thus any other call to atexit() handlers is expressly forbidden by the > standard. > There is no word "only", so it's unspecified. > -- thorpej > signature.asc Description: OpenPGP digital signature
Re: Failure to build gobject-introspection
FWIW I just rebuilt it on today's -current amd64 and -current pkgsrc; it wasn't rebuilt during the last rolling-replace, so the package was from early May; today it was also built right away. I've had various troubles in the past building this package; at one stage it would not build unless DISPLAY was set to a working X server... (that problem was resolved at the time). On Mon, 29 Jun 2020 at 23:32, Robert Swindells wrote: > > > I wrote: > >What is wrong with the idea that you have run out of memory ? > > OTOH, running top(1) at the same time as building it doesn't show > any particularly large processes. --
Re: Failure to build gobject-introspection
I wrote: >What is wrong with the idea that you have run out of memory ? OTOH, running top(1) at the same time as building it doesn't show any particularly large processes.
Re: Failure to build gobject-introspection
On Mon, Jun 29, 2020 at 11:43:55PM +0200, Riccardo Mottola wrote: > Hi Maya! > > m...@netbsd.org wrote: > > > > distutils.errors.CompileError: command 'cpp' terminated by signal 11 > > > Usually any GCC crashes on widely used architectures are running out of > > > RAM. > > See `dmesg |tail` to see some messages related to out-of-RAM GCC > > components killed. > > dmesg does not report anything suspect since boot.. and I did try to rerun > the build twice, so I should see two crashes. > The laptop has 4GB of ram and the same swap this even is enough to build > geck and more or less rust... what's with gobject? > > any better ideas? :-) > > true is that we have now changed GCC in base now.. and 8.4.0 is giving me > other issues... I was about to write that the usual failure for gobject-introspection is that /usr/pkg or pkgsrc is a symlink, before seeing "signal 11" which is SIGSEGV.
Re: Failure to build gobject-introspection
Riccardo Mottola wrote: >m...@netbsd.org wrote: distutils.errors.CompileError: command 'cpp' terminated by signal 11 >>> Usually any GCC crashes on widely used architectures are running out of >>> RAM. >> See `dmesg |tail` to see some messages related to out-of-RAM GCC >> components killed. > >dmesg does not report anything suspect since boot.. and I did try to >rerun the build twice, so I should see two crashes. >The laptop has 4GB of ram and the same swap this even is enough to >build geck and more or less rust... what's with gobject? What have you set MAKE_JOBS to ? >any better ideas? :-) What is wrong with the idea that you have run out of memory ? Other people can build gobject-introspection fine, me included.
Re: Failure to build gobject-introspection
Hi Maya! m...@netbsd.org wrote: distutils.errors.CompileError: command 'cpp' terminated by signal 11 Usually any GCC crashes on widely used architectures are running out of RAM. See `dmesg |tail` to see some messages related to out-of-RAM GCC components killed. dmesg does not report anything suspect since boot.. and I did try to rerun the build twice, so I should see two crashes. The laptop has 4GB of ram and the same swap this even is enough to build geck and more or less rust... what's with gobject? any better ideas? :-) true is that we have now changed GCC in base now.. and 8.4.0 is giving me other issues... Riccardo
Re: atexit(), dlclose() and more atexit()
> On Jun 29, 2020, at 9:09 AM, Rhialto wrote: > > But I wonder if there is any standards text that > describes whether this particular scenario is supposed to work. Quoting from "The Open Group Base Specifications Issue 7, 2018 edition" The atexit() function shall register the function pointed to by func, to be called without arguments at normal program termination. At normal program termination, all functions registered by the atexit() function shall be called, in the reverse order of their registration, except that a function is called after any previously registered functions that had already been called at the time it was registered. Normal termination occurs either by a call to exit() or a return from main(). My reading of the standard here is that atexit() handlers are called at "normal program termination", and that "normal program termination" is explicitly defined as either a call to exit() or returning from main(), and thus any other call to atexit() handlers is expressly forbidden by the standard. -- thorpej
Re: atexit(), dlclose() and more atexit() (with reproducer)
I made a small program reproducing the problem, also with a base system
library. I randomly chose /usr/lib/libtermcap.so as default, but I think
everything that turns up by grep _fini /usr/lib/*.so will do.
Actual output:
$ ./dl
main thread 0x706e490a2800: calling exit()
main thread 0x706e490a2800: telling thread to exit
main thread 0x706e490a2800: calling pthread_join()
worker thread 0x706e4909f000: calling dlclose()
(deadlock)
Expected output:
$ ./dl
main thread 0x706d25e35800: calling exit()
main thread 0x706d25e35800: telling thread to exit
main thread 0x706d25e35800: calling pthread_join()
worker thread 0x706d25e32000: calling dlclose()
worker thread 0x706d25e32000: dlclose() returned
worker thread 0x706d25e32000: exiting
main thread 0x706d25e35800: pthread_join() returned
$
dl.c: (compile with "sh dl.c")
--><>---cut here---<><--
# /*
cc dl.c -o dl -pthread -ggdb
exit $?
*/
#include
#include
#include
#include
#include
void *library_handle;
pthread_t worker_thread = 0;
int worker_thread_should_exit = 0;
void cleanup_from_main_thread()
{
printf("main thread %p: telling thread to exit\n", pthread_self());
worker_thread_should_exit = 1;
printf("main thread %p: calling pthread_join()\n", pthread_self());
pthread_join(worker_thread, NULL);
printf("main thread %p: pthread_join() returned\n", pthread_self());
}
void *worker_thread_main(void *arg)
{
/* Do useful work */
while (!worker_thread_should_exit) {
sleep(1);
}
printf("worker thread %p: calling dlclose()\n", pthread_self());
dlclose(library_handle);
printf("worker thread %p: dlclose() returned\n", pthread_self());
printf("worker thread %p: exiting\n", pthread_self());
pthread_exit(NULL);
}
int
main(int argc, char **argv)
{
char *library = "/usr/lib/libtermcap.so";
if (argc > 1) {
library = argv[1];
}
library_handle = dlopen(library, RTLD_LAZY|RTLD_LOCAL);
pthread_create(_thread, NULL, worker_thread_main, NULL);
atexit(cleanup_from_main_thread);
/* Do useful work */
sleep(1);
printf("main thread %p: calling exit()\n", pthread_self());
exit(0);
}
--><>---cut here---<><--
-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
signature.asc
Description: PGP signature
Re: wm0 panic
On Mon, Jun 29, 2020 at 12:53:23PM +0900, Kengo NAKAHARA wrote:
> It seems some other code have held KERNEL_LOCK too long time.
> Could you show the function of last locked address?
> # e.g. addr2line -e "your kernel image" -f 0x80a7d2f5
With Jun 28 14:26 code
# addr2line -e netbsd.3.gdb -f 0x80a4c526
doifioctl
/usr/src/sys/arch/amd64/compile/QUANTZDBG/../../../../net/if.c:3403
(discriminator 3)
> If the panic can reappear, could you show "show all locks/t" of ddb?
It is nicely reproducible (boot single user, type "ifconfig wm0 up"),
I have a core dump and a serial console, but debugging locking issues
is "interesting"!
Thanks,
Patrick
type : spin
initialized : 0x80ada119
shared holds : 0 exclusive: 1
shares wanted: 0 exclusive: 3
relevant cpu : 1 last held: 0
relevant lwp : 0xf1c63767f200 last held: 0xf1c6387c8a40
last locked* : 0x80a4c526 unlocked : 0x80a4c517
curcpu holds : 0 wanted by: 0xf1c63767f200
db{1}> show all locks /t
[Locks tracked through LWPs]
** LWP 330.330 (ifconfig) @ 0xf1c6387c8a40, l_stat=7
*** Locks held:
* Lock 0 (ick address : 0xf1c637a4e380 type : sleep/adaptive
initialized : 0x80a475fd
shared holds : 0 exclusive: 1
shares wanted: 0 exclusive: 0
relevant cpu : 0 last held: 0
relevant lwp : 0xf1c6388a40
last locked* : 0x80a4bf94 unlocked : 0x80a4c02b
owner field : 0xf1c6387c8a40 wait/spin:0/0
Turnstile: no active turnstile for this lock.
*** Loczed at module_hook_init)
lock address : 0x8106a800 type : sleep/adaptive
initialized : 0x80952c6e
shared holds : 0 exclusive: 0
shares wanted: 0 exclusive: 0
relevant cpu : 0 last held: 0
relevant lwp : 0xf1c6387c8a40 last held: 00
last locked : 00 unlocked*: 00
owner field : 00 wait/spin:0/0
Turnstile: no active turnstile for this lock.
*** Traceback:
trace: pid 330 lid 330 at 0x8
address 0x283 is invalid
?() at 283
address 0x10 is invalid
address 0x8 is invalid
db_printf() at netbsd:db_printf
** LWP 0.402 (iic1) @ 0xf1c637f1aa40, l_stat=7
*** Locks held: none
*** Locks wanted:
* Lock 0 (initialized at main)
lock address : 0x8106a700 type :0x80ada119
shared holds : 0 exclusive: 1
shares wanted: 0 exclusive: 3
relevant cpu : 2 last hellwp : 0xf1c637f1aa40 last held:
0xf1c6387c8a40
last locked* : 0x80a4c526 unlocked : 0x80a4c517
curcpu holds : 0 wanted by: 0xf1c63767f200
*** 02 at 0xb0025da16ec0
sleepq_block() at netbsd:sleepq_block+0x211
iic_smbus_intr_thread() at netbsd:iic_smbus_intr_thread+0x52
** LWP 0.401 (iic0) @ 0xf1c637f1a600, l_stat=7
*** Locks held: none
*** Locks wanted:
* Lock 0 (initiax8106a700 type : spin
initialized : 0x80ada119
shared holds : 0 exclusive: 1
shares wanted: 0 exclusive: 3
relevant cpu : 1 last held: 0
relevant lwp : 0xf1c637f1a600 last held: 0xf1c6387c8a40
last locked* : 0x80a4c526 unlocked : 0x80a4c517
curcpu holds : 0 wanted by: 0xf1c63767f200
*** Traceback:
trace: pid 0 lid 401 at 0xb0025da11ec0
sleepq_block() at netbsd:sleepq_block+0x211
iic_smbus_intr_thread() at netbsd:iic_smbus_intr_thread+0x52
** LWP 0.23 (softclk/1) @ 0xf1c63767f200, l_stat=7
*** Locks held:
* Lock 0 (initialized at soinit)
lock address : 0xf1cd177e3080 type : sleep/adaptive
initialed holds : 0 exclusive: 1
shares wanted: 0 exclusive: 0
relevant cpu : 1 last held: 1
r last held: 0xf1c63767f200
last locked* : 0x806c3e65 unlocked : 0x806d5ebd
owner field : 0xf1c63767f200 wait/spin:0/0
Turnstile: no active turnstileted:
* Lock 0 (initialized at main)
lock address : 0x8106a700 type : spin
initialized : 0x80ada119
shared holds : 0 exclusive: 1
shares wanted: 0 exclusive: 3
relevant cpu : 1 last held: 0
relevant lwp : 0xf1c63767f200 last held: 0xf1c6387c8a40
last locked* : 0x80a4c526 unlocked :
Re: atexit(), dlclose() and more atexit()
On Mon 29 Jun 2020 at 09:55:10 +0200, Rhialto wrote: > I've looked at __cxa_finalize a bit better, and it seems that the lock > mutex_lock(&__atexit_mutex); isn't just used to protect running the > atexit handlers, but even to protect looking at the list of handlers: > atexit_handler_stack. > So the fact that libavformat establishes a handler may be a red herring. > I will try to test this later today somehow. So I did a small experiment. Since VICE dlopens several of the ffmpeg's shared libraries, I changed the order that it is closing them. I get now: ffmpegdrv_shutdown: entered; calling ffmpeglib_close(); ffmpeglib_close: free_avcodec() vice_dynlib_close: pthread=0x72abf78b8000 ffmpeglib_close: free_avutil() vice_dynlib_close: pthread=0x72abf78b8000 ffmpeglib_close: free_swscale() vice_dynlib_close: pthread=0x72abf78b8000 ^C^\Quit (core dumped) meaning that it managed to dlclose libavcodec, libavutil, and hangs during libswscale. None of those contain calls to atexit that I could find in the source; only libavformat/avisynth.c refers to atexit. With my revised chain of events, I was expecting that it would deadlock while dlclosing the first shared library, which is now libavcodec. Instead it deadlocks at the third. I'm not sure yet what to make of that. I can only say that in gdb, breaking on __cxa_finalize, the first two libraries don't seem to get there at all and the first library to get there is Thread 9 "" hit Breakpoint 2, __cxa_finalize ( dso=0x7b02ccc7b940 <__dso_handle>) at /usr/src/lib/libc/stdlib/atexit.c:192 (gdb) bt #0 __cxa_finalize (dso=0x7b02ccc7b940 <__dso_handle>) at /usr/src/lib/libc/stdlib/atexit.c:192 #1 0x7b02cca02318 in ?? () from /usr/pkg/lib/ffmpeg4/libswscale.so.5 #2 0x7b02e49fe1a0 in ?? () #3 0x7b02cca6c579 in _fini () from /usr/pkg/lib/ffmpeg4/libswscale.so.5 #4 0x in ?? () I'm not sure why this library has a _fini() function which gets called. This would make the chain of events (3rd version): 1. In the original thread, it dlopen()s a library with a _fini function which calls __cxa_finalize(). [what causes this???] 2. There is no 2. 3. The main thread starts a new thread, and registers an atexit() handler to clean up that thread. 3a. Both threads run for a while doing their main jobs. 4. main thread exit()s. 5. atexit() handler obtains its lock (which protects the handler list), and calls the handler established in 3. 6. said handler tells the new thread to clean up and finish. One of the last things the thread does, is to dlclose() libavformat. 7. __cxa_finalize() gets called on behalf of the library, which tries to obtain the same lock that was already obtained, in a different thread, in step 5. 8. deadlock. In this case, the fault cannot be with libavformat or libswscale, right? -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: atexit(), dlclose() and more atexit()
On Mon 29 Jun 2020 at 10:39:45 +0200, Martin Husemann wrote: > On Mon, Jun 29, 2020 at 09:55:10AM +0200, Rhialto wrote: > > 6. said handler tells the new thread to clean up and finish. One of the last > >things the thread does, is to dlclose() libavformat. > > How can an atexit() handler (or a destructor) defer work to a thread > (w/o waiting for the thread to complete, but then the thread makes no > sense)? I'm boiling down things to the essence here. The "new thread" isn't just there to do cleanup. It has been running the CPU emulation of VICE for potentially a long time. When the GTK3 GUI (which runs on the main thread) lets the user choose the Quit menu entry, it starts shutting things down. Part of the shutdown happens in the atexit handler. When this CPU emulating thread gets notified that it should finish up, it also handles the dlclose(), which in turn deadlocks. It is basically an unfortunate distribution of cleanup tasks which causes a deadlock. But I wonder if there is any standards text that describes whether this particular scenario is supposed to work. > Martin -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Failure to build gobject-introspection
On Mon, Jun 29, 2020 at 04:02:43PM +, m...@netbsd.org wrote: > On Mon, Jun 29, 2020 at 12:32:27PM +0200, Riccardo Mottola wrote: > > distutils.errors.CompileError: command 'cpp' terminated by signal 11 > > Usually any GCC crashes on widely used architectures are running out of > RAM. See `dmesg |tail` to see some messages related to out-of-RAM GCC components killed.
Re: Failure to build gobject-introspection
On Mon, Jun 29, 2020 at 12:32:27PM +0200, Riccardo Mottola wrote: > distutils.errors.CompileError: command 'cpp' terminated by signal 11 Usually any GCC crashes on widely used architectures are running out of RAM.
Re: atexit(), dlclose() and more atexit()
On Sun 28 Jun 2020 at 23:29:05 +0200, Joerg Sonnenberger wrote: > On Sun, Jun 28, 2020 at 10:56:01PM +0200, Rhialto wrote: > > The funny thing is that libavformat uses an atexit handler due to issues > > with dynamic (un)loading (or so they claim). This is from their file > > ffmpeg-4.2.2/libavformat/avisynth.c: > > > > /* A conflict between C++ global objects, atexit, and dynamic loading > > requires > > * us to register our own atexit handler to prevent double freeing. */ > > It is fundamentally wrong to use a handler in a library that can be > unloaded. Some systems hack around that problem by looping over all > atexit handlers on dlclose, but that's exactly that, a costly hack. The > most common way this triggers is a segfault, actually. > The code should be using either a C dtor with the appropiate attribute > or __cxa_atexit directly, but the former is preferable. I've looked at __cxa_finalize a bit better, and it seems that the lock mutex_lock(&__atexit_mutex); isn't just used to protect running the atexit handlers, but even to protect looking at the list of handlers: atexit_handler_stack. So the fact that libavformat establishes a handler may be a red herring. I will try to test this later today somehow. This would make the chain of events: 1. In the original thread, it dlopen()s libavformat. 2. There is no 2. 3. The main thread starts a new thread, and registers an atexit() handler to clean up that thread. 4. main thread exit()s. 5. atexit() handler obtains its lock (which protects the handler list), and calls the handler established in 3. 6. said handler tells the new thread to clean up and finish. One of the last things the thread does, is to dlclose() libavformat. 7. __cxa_finalize() gets called on behalf of libavformat (as always happens when a library is unloaded), which tries to obtain the same lock that was already obtained, in a different thread, in step 5. 8. deadlock. In this case, the fault cannot be with libavformat, right? -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
