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 address : 0x8106ab40 type : spin [ 127.5863237] initialized : 0x80b0bbb9 [ 127.5863237] shared holds : 0 exclusive: 1 [ 127.5963238] shares wanted: 0 exclusive: 1 [ 127.6063236] relevant cpu : 1 last held: 0 [ 127.6163235] relevant lwp : 0x8d419a07f20 [ 127.6163235] last locked* : 0x80a7d2f5 unlocked : 0x80a7d2e6 [ 127.6263235] curcpu holds : 0 wanted by: 0x8d419a07f200 [ 127.6363234] panic: LOCKDEBock,244: spinout [ 127.6363234] cpu1: Begin traceback... [ 127.6463233] vpanic() at netbsd:vpanic+0x152 [ 127.6463233] snprintf() at netbsd:snprintf [ 127.6563232] lockdebug_more() at netbsd:lockdebug_more [ 127.6563232] _kernel_lock() at netbsd:_kernel_lock+0x244 [ 127.6663231] ip_slowtimo() at netbsd:ip_slowtimo+0x1a [ 127.6763231] pfslowtimo() at netbsd:pfslowtimo+0x34 [ 127.6763231] callout_softclock() at netbsd:callout_softclock+0x10f [ 127.6863230] softint_disph+0x108 [ 127.6863230] DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xa4825d02eff0 [ 127.6963230] Xsoftintr() at netbsd:Xsoftintr+0x4f [ 127.7063229] --- interrupt --- [ 127.706322traceback... 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 If the panic can reappear, could you show "show all locks/t" of ddb? Thanks, -- // Internet Initiative Japan Inc. Device Engineering Section, Product Development Department, Product Division, Technology Unit Kengo NAKAHARA
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.fnt.uue U src/share/wscons/fonts/spleen-32x64.fnt.uue U src/share/wscons/fonts/spleen-5x8.fnt.uue U src/share/wscons/fonts/spleen-8x16.fnt.uue P src/sys/arch/arm/ti/omap3_dss.c P src/sys/arch/ia64/include/mcontext.h P src/sys/arch/ia64/include/setjmp.h P src/sys/arch/mips/mips/mips_machdep.c P src/sys/compat/common/vfs_syscalls_20.c P src/sys/ddb/db_output.h P src/sys/dev/cadence/if_cemac.c P src/sys/stand/efiboot/Makefile.efiboot P src/sys/stand/efiboot/boot.c cvs update: `src/sys/stand/efiboot/efienv.c' is no longer in the repository cvs update: `src/sys/stand/efiboot/efienv.h' is no longer in the repository P src/sys/stand/efiboot/exec.c P src/sys/stand/efiboot/version P src/usr.bin/make/cond.c P src/usr.bin/make/unit-tests/Makefile U src/usr.bin/make/unit-tests/cond-short.exp U src/usr.bin/make/unit-tests/cond-short.mk Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38967651 Jun 29 03:16 ls-lRA.gz
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_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/pkg/gcc8/libexec/gcc/i486--netbsdelf/8.3.0/lto-wrapper
Target: i486--netbsdelf
Configured with: ../gcc-8.3.0/configure --disable-libstdcxx-pch
--with-system-zlib --enable-nls --with-libiconv-prefix=/usr
--enable-__cxa_atexit --with-gxx-include-dir=/usr/pkg/gcc8/include/c++/
--disable-libssp --enable-languages='c obj-c++ objc fortran c++'
--enable-shared --enable-long-long --with-local-prefix=/usr/pkg/gcc8
--enable-threads=posix --with-boot-ldflags='-static-libstdc++
-static-libgcc -Wl,-R/usr/pkg/lib ' --with-gnu-ld --with-ld=/usr/bin/ld
--with-gnu-as --with-as=/usr/bin/as --with-arch=i486 --with-tune=i486
--prefix=/usr/pkg/gcc8 --build=i486--netbsdelf --host=i486--netbsdelf
--infodir=/usr/pkg/gcc8/info --mandir=/usr/pkg/gcc8/man
--enable-option-checking=yes
Thread model: posix
gcc version 8.3.0 (GCC)
Building top of tree, I've been getting this error for a while:
# compile libprop/prop_kern.lo
cc -O -I/usr/src8/src/tools/libprop/../compat
-I/usr/src8/src/tools/libprop/../../common/include
-I/usr/src8/src/./BUILD_TOOL/include/compat
-I/usr/src8/src/./BUILD_TOOL/include/nbinclude -DHAVE_NBTOOL_CONFIG_H=1
-D_FILE_OFFSET_BITS=64 -I/usr/src8/src/./BUILD_TOOL/include
-I/usr/src8/src/./BUILD_TOOL/include/nbinclude -c -o prop_kern.lo.o
/usr/src8/src/tools/libprop/../../common/lib/libprop/prop_kern.c
In file included from
/usr/src8/src/tools/libprop/../../common/include/prop/proplib.h:35:0,
from
/usr/src8/src/tools/libprop/../../common/lib/libprop/prop_kern.c:37:
/usr/src8/src/tools/libprop/../../common/include/prop/prop_array.h:150:7:
error: unknown type name 'intptr_t'
intptr_t *);
^
/usr/src8/src/tools/libprop/../../common/include/prop/prop_array.h:152:7:
error: unknown type name 'uintptr_t'
uintptr_t *);
^
/usr/src8/src/tools/libprop/../../common/include/prop/prop_array.h:154:7:
error: unknown type name 'intptr_t'
intptr_t);
^
/usr/src8/src/tools/libprop/../../common/include/prop/prop_array.h:156:7:
error: unknown type name 'uintptr_t'
uintptr_t);
^
/usr/src8/src/tools/libprop/../../common/include/prop/prop_array.h:214:43:
error: unknown type name 'intptr_t'
bool prop_array_add_intptr(prop_array_t, intptr_t);
^
/usr/src8/src/tools/libprop/../../common/include/prop/prop_array.h:215:44:
error: unknown type name 'uintptr_t'
bool prop_array_add_uintptr(prop_array_t, uintptr_t);
^
In file included from
/usr/src8/src/tools/libprop/../../common/include/prop/proplib.h:38:0,
from
/usr/src8/src/tools/libprop/../../common/lib/libprop/prop_kern.c:37:
/usr/src8/src/tools/libprop/../../common/include/prop/prop_dictionary.h:180:9:
error: unknown type name 'intptr_t'
intptr_t *);
^
/usr/src8/src/tools/libprop/../../common/include/prop/prop_dictionary.h:182:10:
error: unknown type name 'uintptr_t'
uintptr_t *);
^
/usr/src8/src/tools/libprop/../../common/include/prop/prop_dictionary.h:184:9:
error: unknown type name 'intptr_t'
intptr_t);
^
/usr/src8/src/tools/libprop/../../common/include/prop/prop_dictionary.h:186:10:
error: unknown type name 'uintptr_t'
uintptr_t);
^
*** Failed target: prop_kern.lo
*** Failed command: cc -O -I/usr/src8/src/tools/libprop/../compat
-I/usr/src8/src/tools/libprop/../../common/include
-I/usr/src8/src/./BUILD_TOOL/include/compat
-I/usr/src8/src/./BUILD_TOOL/include/nbinclude -DHAVE_NBTOOL_CONFIG_H=1
-D_FILE_OFFSET_BITS=64 -I/usr/src8/src/./BUILD_TOOL/include
-I/usr/src8/src/./BUILD_TOOL/include/nbinclude -c -o prop_kern.lo.o
/usr/src8/src/tools/libprop/../../common/lib/libprop/prop_kern.c
*** Error code 1
Stop.
nbmake[3]: stopped in /usr/src8/src/tools/libprop
*** Failed target: dependall
*** Failed command: cd "/usr/src8/src/tools/libprop";
/usr/src8/src/./BUILD_TOOL/bin/nbmake realall
*** Error code 1
*** Failed target: dependall-libprop
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift;
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/usr/src8/src/tools" ;; *) this="${dir}/";
real="/usr/src8/src/tools/${dir}" ;; esac; show=${this:-.}; echo "${target}
===> ${show%/}${1:+ (with: $@)}"; cd "${real}" &&
/usr/src8/src/./BUILD_TOOL/bin/nbmake _THISDIR_="${this}" "$@" ${target};
}; _makedirtarget libprop dependall
*** Error code 1
*** Failed target: build_install
*** Failed command: _makedirtarget() { dir="$1"; shift; target="$1"; shift;
case "${dir}" in /*) this="${dir}/"; real="${dir}" ;; .) this="";
real="/usr/src8/src/tools" ;; *) this="${dir}/";
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 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 world disagrees and NetBSD is different for no good reason. >>> >>> You sound like a broken record. Have you *thought* about the reasons at >>> all? Like for example the very definition of atexit: "Run a handler at >>> process exit". The Linux variant does not do that. Heck, they only >>> document it as a side note. >>> >> >> atexit is implemented today as 'The atexit() function registers the >> function pointed to by func to be called without arguments on normal >> termination of the program or when the object defining the function is >> unloaded.' for around 20 years now. >> >> NetBSD is a leftover with a broken implementation. > > Funny, neither POSIX nor ISO C agree with you, but I guess neither is > the relevant standard. But I'll stop here. It isn't productive. > There is no disagreement, but a field not specified. This behavior is suggested in Itanium C++ ABI with so called reasonable treatment of atexit handlers upon dlclose). I've submitted in 2018 a request to Itanium C++ ABI people to clarify the wording, but they redirected me to POSIX. POSIX kind of intends to support no-op dlclose, but perhaps I will need to try to reach them. So this is a dominant convention (Linux, FreeBSD, Solaris) and we will keep observing recurring NetBSD-specific behavior crashes. > Joerg > signature.asc Description: OpenPGP digital signature
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 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 world disagrees and NetBSD is different for no good reason. > > > > You sound like a broken record. Have you *thought* about the reasons at > > all? Like for example the very definition of atexit: "Run a handler at > > process exit". The Linux variant does not do that. Heck, they only > > document it as a side note. > > > > atexit is implemented today as 'The atexit() function registers the > function pointed to by func to be called without arguments on normal > termination of the program or when the object defining the function is > unloaded.' for around 20 years now. > > NetBSD is a leftover with a broken implementation. Funny, neither POSIX nor ISO C agree with you, but I guess neither is the relevant standard. But I'll stop here. It isn't productive. Joerg
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 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 world disagrees and NetBSD is different for no good reason. > > You sound like a broken record. Have you *thought* about the reasons at > all? Like for example the very definition of atexit: "Run a handler at > process exit". The Linux variant does not do that. Heck, they only > document it as a side note. > atexit is implemented today as 'The atexit() function registers the function pointed to by func to be called without arguments on normal termination of the program or when the object defining the function is unloaded.' for around 20 years now. NetBSD is a leftover with a broken implementation. >> We shall add support for this. > > We shall not. It is a bad design. > The world standardized on integration with dlclose(3). >> On 28.06.2020 23:29, Joerg Sonnenberger wrote: >>> The code should be using either a C dtor with the appropiate attribute >>> or __cxa_atexit directly, but the former is preferable. >> >> This replacement forces to use a hack with a GCC extension (destructor >> attribute) instead of C complaint code. > > So what? It can be spelled out differently and the library here > certainly contains enough dependencies on GCC extensions already. > Destructor is a C++ feature, available in C as a GCC extension. >> __cxa_atexit is a C++ thing so another hack for our atexit(3). > > Where the heck did you arrive at the conclusion that __cxa_atexit is a > C++ thing? It is support infrastructure having dynamic cleanup handlers > on a per DSO base. Just because C++ was the first language to desire > that doesn't mean it is C++ only. In fact, the above extension is using > exactly the same code. > __cxa_atexit is an internal symbol in Itanium C++ ABI, nothing to do with C. > Joerg > signature.asc Description: OpenPGP digital signature
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's exactly that, a costly hack. The > > most common way this triggers is a segfault, actually. > > The world disagrees and NetBSD is different for no good reason. You sound like a broken record. Have you *thought* about the reasons at all? Like for example the very definition of atexit: "Run a handler at process exit". The Linux variant does not do that. Heck, they only document it as a side note. > We shall add support for this. We shall not. It is a bad design. > On 28.06.2020 23:29, Joerg Sonnenberger wrote: > > The code should be using either a C dtor with the appropiate attribute > > or __cxa_atexit directly, but the former is preferable. > > This replacement forces to use a hack with a GCC extension (destructor > attribute) instead of C complaint code. So what? It can be spelled out differently and the library here certainly contains enough dependencies on GCC extensions already. > __cxa_atexit is a C++ thing so another hack for our atexit(3). Where the heck did you arrive at the conclusion that __cxa_atexit is a C++ thing? It is support infrastructure having dynamic cleanup handlers on a per DSO base. Just because C++ was the first language to desire that doesn't mean it is C++ only. In fact, the above extension is using exactly the same code. Joerg
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 segfault, actually. The world disagrees and NetBSD is different for no good reason. We shall add support for this. On 28.06.2020 23:29, Joerg Sonnenberger wrote: > The code should be using either a C dtor with the appropiate attribute > or __cxa_atexit directly, but the former is preferable. This replacement forces to use a hack with a GCC extension (destructor attribute) instead of C complaint code. __cxa_atexit is a C++ thing so another hack for our atexit(3). signature.asc Description: OpenPGP digital signature
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: > > > > > > 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. > > > 4. main thread exit()s. > > > 5. atexit() handler obtains its lock, 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. libavformat's atexit handling gets called, which tries to obtain the > > >same lock that was already obtained, in a different thread, in step > > >5. > > > 8. deadlock. > > > > > > Who is in the wrong here? > > > > libavformat. Never use atexit() with a handler in a library that can be > > closed. > > 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. Joerg
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. libavformat establishes an atexit() handler. > > 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, 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. libavformat's atexit handling gets called, which tries to obtain the > >same lock that was already obtained, in a different thread, in step > >5. > > 8. deadlock. > > > > Who is in the wrong here? > > libavformat. Never use atexit() with a handler in a library that can be > closed. 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. */ > Joerg -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 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 thread, and registers an atexit() >handler to clean up that thread. > 4. main thread exit()s. > 5. atexit() handler obtains its lock, 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. libavformat's atexit handling gets called, which tries to obtain the >same lock that was already obtained, in a different thread, in step >5. > 8. deadlock. > > Who is in the wrong here? libavformat. Never use atexit() with a handler in a library that can be closed. Joerg
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. 4. main thread exit()s. 5. atexit() handler obtains its lock, 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. libavformat's atexit handling gets called, which tries to obtain the same lock that was already obtained, in a different thread, in step 5. 8. deadlock. Who is in the wrong here? Some stack traces for illustration. A more extensive version of this can be found at the bugtracker of VICE: https://sourceforge.net/p/vice-emu/bugs/1243/ See Thread 9 frame #3 versus Thread 1 frame #4 the "new thread": Thread 9 (LWP 9 of process 2731): #0 0x75e643aa1f7a in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x75e6440095a6 in pthread__mutex_lock_slow (ptm=ptm@entry=0x75e643fe1780 <__atexit_mutex>, ts=ts@entry=0x0) at /usr/src/lib/libpthread/pthread_mutex.c:384 #2 0x75e6440099b5 in pthread_mutex_lock (ptm=ptm@entry=0x75e643fe1780 <__atexit_mutex>) at /usr/src/lib/libpthread/pthread_mutex.c:208 #3 0x75e643b43a14 in __cxa_finalize (dso=0x75e638e145e0 <__dso_handle>) at /usr/src/lib/libc/stdlib/atexit.c:198 #4 0x75e638a397f8 in ?? () from /usr/pkg/lib/ffmpeg4/libavformat.so.58 #5 0x75e64b546160 in ?? () #6 0x75e638b8aed9 in _fini () from /usr/pkg/lib/ffmpeg4/libavformat.so.58 #7 0x in ?? () the main thread: Thread 1 (LWP 1 of process 2731): #0 0x75e643aa1f7a in ___lwp_park60 () from /usr/lib/libc.so.12 #1 0x75e64400a71f in pthread_cond_timedwait (cond=0x75e62dd910c0, mutex=0x75e62dd91018, abstime=0x0) at /usr/src/lib/libpthread/pthread_cond.c:168 #2 0x75e64400c2c8 in pthread_join (thread=0x75e62dd91000, valptr=valptr@entry=0x0) at /usr/src/lib/libpthread/pthread.c:724 #3 0x004312ec in vice_thread_shutdown () at ../../vice/src/main.c:350 #4 0x75e643b43ac0 in __cxa_finalize (dso=dso@entry=0x0) at /usr/src/lib/libc/stdlib/atexit.c:222 #5 0x75e643b437b3 in exit (status=status@entry=0) at /usr/src/lib/libc/stdlib/exit.c:60 #6 0x00445998 in archdep_vice_exit (excode=excode@entry=0) at ../../../../vice/src/arch/shared/archdep_atexit.c:119 #7 0x005ca086 in ui_exit () at ../../../../vice/src/arch/gtk3/ui.c:2051 #8 0x005cb4e4 in ui_close_callback (widget=, user_data=) at ../../../../vice/src/arch/gtk3/uicommands.c:226 #9 0x75e64878550c in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from /usr/pkg/lib/libgtk-3.so.0 #10 0x75e645c12352 in g_closure_invoke () from /usr/pkg/lib/libgobject-2.0.so.0 #11 0x75e645c233f0 in signal_emit_unlocked_R () from /usr/pkg/lib/libgobject-2.0.so.0 #12 0x75e645c2d61e in g_signal_emit_valist () from /usr/pkg/lib/libgobject-2.0.so.0 #13 0x75e645c2e3cc in g_signal_emit () from /usr/pkg/lib/libgobject-2.0.so.0 #14 0x75e6484f906f in gtk_accel_group_activate () from /usr/pkg/lib/libgtk-3.so.0 #15 0x75e6484fa6a6 in gtk_accel_groups_activate () from /usr/pkg/lib/libgtk-3.so.0 #16 0x75e648759a9a in gtk_window_activate_key () from /usr/pkg/lib/libgtk-3.so.0 #17 0x005c8453 in kbd_event_handler (w=0x75e64b450260, report=0x75e64cc7bd00, gp=) at ../../../../vice/src/arch/gtk3/kbd.c:366 #18 0x75e648784873 in _gtk_marshal_BOOLEAN__BOXED () from /usr/pkg/lib/libgtk-3.so.0 #19 0x75e645c12352 in g_closure_invoke () from /usr/pkg/lib/libgobject-2.0.so.0 #20 0x75e645c233f0 in signal_emit_unlocked_R () from /usr/pkg/lib/libgobject-2.0.so.0 #21 0x75e645c2d61e in g_signal_emit_valist () from /usr/pkg/lib/libgobject-2.0.so.0 #22 0x75e645c2e3cc in g_signal_emit () from /usr/pkg/lib/libgobject-2.0.so.0 #23 0x75e648738907 in gtk_widget_event_internal () from /usr/pkg/lib/libgtk-3.so.0 #24 0x75e64861332c in propagate_event () from /usr/pkg/lib/libgtk-3.so.0 #25 0x75e648614f44 in gtk_main_do_event () from /usr/pkg/lib/libgtk-3.so.0 #26 0x75e64802c9ae in _gdk_event_emit () from /usr/pkg/lib/libgdk-3.so.0 #27 0x75e64805ac44 in gdk_event_source_dispatch () from /usr/pkg/lib/libgdk-3.so.0 #28 0x75e645849543 in g_main_context_dispatch () from /usr/pkg/lib/libglib-2.0.so.0 #29 0x75e6458496fc in g_main_context_iterate.isra () from /usr/pkg/lib/libglib-2.0.so.0 #30 0x75e64584997a in g_main_loop_run () from /usr/pkg/lib/libglib-2.0.so.0 #31 0x75e6486142f2 in gtk_main () from /usr/pkg/lib/libgtk-3.so.0 #32 0x00634b7c in main (argc=1, argv=0x7f7fff1e0628) at ../../../../vice/src/arch/gtk3/gtk3main.c:91 signature.asc Description: PGP signature
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 on libgomp, thus every gd-using package >is now G.D. broke)! > >I propose that the rule documented in src/distrib/lists/base/shl.mi be >far more strictly observed, even for libraries that appear and disappear >between releases (i.e. for -current), at least for the ".major" link and >the file it points to. If they were never there in a release, never >mentioning them as obsolete in releases should be just fine (i.e. they >were never there, so never mentioning them is the correct thing to do). > >On the other hand we could first fix postinstall to be more careful by >getting it to fetch all the "REQUIRED" values from package BUILD_INFO >like this: > > pkg_info -a -Q REQUIRES | sort -u > >and then have it noisily refuse to remove any obsolete file still in >this "required" list. This would allow us to mention all old/upgraded >shared libraries as obsolete, including those from between releases. Of >course this only protects things installed via pkgsrc, and there's still >the risk of subsequently needing to install a binary package built for >an older release which needs one of these "obsolete" files, but at least >pkg_add can (be made to if it doesn't already) notice this and abort. That is a good idea. Perhaps even pkg_info -a -Q REQUIRES | fgrep -v /usr/pkg | sort -u christos
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 traceback... [ 153620.7534934] trace fp c008414bfb30 [ 153620.7814018] fp c008414bfb50 vpanic() at c04adf4c netbsd:vpanic+0x15c [ 153620.7934242] fp c008414bfbc0 kern_assert() at c07ccdec netbsd:kern_assert+0x5c [ 153620.8014956] fp c008414bfc50 amap_wipeout() at c040bc94 netbsd:amap_wipeout+0xf4 [ 153620.8315156] fp c008414bfc90 uvm_unmap_detach() at c041c454 netbsd:uvm_unmap_detach+0x6c [ 153620.8453990] fp c008414bfcd0 uvmspace_free() at c041ef08 netbsd:uvmspace_free+0xd8 [ 153620.8544258] fp c008414bfd00 exit1() at c0452bcc netbsd:exit1+0x174 [ 153620.8544258] fp c008414bfdf0 sys_exit() at c0453498 netbsd:sys_exit+0x38 [ 153620.9044388] fp c008414bfe20 syscall() at c008c384 netbsd:syscall+0x18c [ 153620.9044388] tf c008414bfed0 el0_trap() at c008a994 netbsd:el0_trap [ 153620.9197358] trapframe 0xc008414bfed0 (304 bytes) [ 153620.9272872] pc=f4aa7d931478, spsr=8000 [ 153620.9272872]esr=5601,far=f4aa7cab5048
