Re: wm0 panic

Hi, On 2020/06/28 0:24, Patrick Welche wrote: Trying a today's -current/amd64 with DIAGNOSTIC/DEBUG/LOCKDEBUG, I can boot multiuser without a network. If I log in as root, as soon as I hit enter: # ifconfig wm0 inet 10.0.0.62 netmask 0xff00 [ 127.5763268] Kernel lock error 127.5763268] lock

daily CVS update output

Updating src tree: P src/distrib/sets/lists/base/mi P src/distrib/sets/lists/tests/mi P src/etc/mtree/special P src/lib/libc/posix1e/posix1e.3 P src/share/wscons/fonts/COPYRIGHT P src/share/wscons/fonts/Makefile U src/share/wscons/fonts/spleen-12x24.fnt.uue U src/share/wscons/fonts/spleen-16x32.f

libprop build error on top of tree - where did I go wrong?

On this version of NetBSD: [root]: uname -a NetBSD mail.wan.vpn 7.1.2 NetBSD 7.1.2 (GEMINI) #0: Tue Sep 18 13:25:59 PDT 2018 r...@mail.wan.vpn:/usr/src/BUILD_OBJ/sys/arch/i386/compile/GEMINI i386 Using gcc8 [root]: which gcc /usr/pkg/gcc8/bin/gcc [root]: gcc -v Using built-in specs. COLLECT_G

Re: atexit(), dlclose() and more atexit()

On 29.06.2020 00:50, Joerg Sonnenberger wrote: > On Mon, Jun 29, 2020 at 12:34:31AM +0200, Kamil Rytarowski wrote: >> On 28.06.2020 23:57, Joerg Sonnenberger wrote: >>> On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote: On 28.06.2020 23:29, Joerg Sonnenberger wrote: > It is

Re: atexit(), dlclose() and more atexit()

On Mon, Jun 29, 2020 at 12:34:31AM +0200, Kamil Rytarowski wrote: > On 28.06.2020 23:57, Joerg Sonnenberger wrote: > > On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote: > >> On 28.06.2020 23:29, Joerg Sonnenberger wrote: > >>> It is fundamentally wrong to use a handler in a library

Re: atexit(), dlclose() and more atexit()

On 28.06.2020 23:57, Joerg Sonnenberger wrote: > On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote: >> On 28.06.2020 23:29, Joerg Sonnenberger wrote: >>> It is fundamentally wrong to use a handler in a library that can be >>> unloaded. Some systems hack around that problem by looping

Re: atexit(), dlclose() and more atexit()

On Sun, Jun 28, 2020 at 11:48:15PM +0200, Kamil Rytarowski wrote: > On 28.06.2020 23:29, Joerg Sonnenberger wrote: > > 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

Re: atexit(), dlclose() and more atexit()

On 28.06.2020 23:29, Joerg Sonnenberger wrote: > 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 s

Re: atexit(), dlclose() and more atexit()

On Sun, Jun 28, 2020 at 10:56:01PM +0200, Rhialto wrote: > On Sun 28 Jun 2020 at 22:39:28 +0200, Joerg Sonnenberger wrote: > > On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote: > > > I have at hand a program (the current svn trunk of VICE, to be exact) > > > which does the following: > > >

Re: atexit(), dlclose() and more atexit()

On Sun 28 Jun 2020 at 22:39:28 +0200, Joerg Sonnenberger wrote: > On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote: > > I have at hand a program (the current svn trunk of VICE, to be exact) > > which does the following: > > > > 1. In the original thread, it dlopen()s libavformat. > > 2. lib

Re: atexit(), dlclose() and more atexit()

On Sun, Jun 28, 2020 at 10:35:27PM +0200, Rhialto wrote: > I have at hand a program (the current svn trunk of VICE, to be exact) > which does the following: > > 1. In the original thread, it dlopen()s libavformat. > 2. libavformat establishes an atexit() handler. > 3. The main thread starts a new

atexit(), dlclose() and more atexit()

I have at hand a program (the current svn trunk of VICE, to be exact) which does the following: 1. In the original thread, it dlopen()s libavformat. 2. libavformat establishes an atexit() handler. 3. The main thread starts a new thread, and registers an atexit() handler to clean up that thread.

Re: postinstall removed yet another "obsolete" system library that was still used....

In article , Greg A. Woods wrote: >-=-=-=-=-=- > >So I just upgraded a system from an old 8.99 -current to a newer 9.99 >current and "postinstall fix obsolete" removed my /usr/lib/libgomp.so.1* > >However this library was still in use by installed packages (due, I >think, to a dependency of libgd

Another uvm_amap panic in -current

Console output stopped working part-way through the traceback so only part of the trapframe is printed. [ 153620.7406721] panic: kernel diagnostic assertion "anon != NULL && anon->an_ref != 0" failed: file "/home/source/ab/HEAD/src/sys/uvm/uvm_amap.c", line 748 [ 153620.7534934] cpu0: Begin tra