On Fri, Sep 11, 2020 at 09:09:39AM -0000, Stuart Henderson wrote: > On 2020-09-10, Ashlen <euryd...@riseup.net> wrote: > > doesn't do anything to fix the issue, so it doesn't seem to be > > a problem caused by my configs.
Been like that for years on all installations here. Never taken time to investigate, so thanks for the initiative. > First thing to look for when there's a core dump is to see if you can > get a useful backtrace. How does the output look from this? > > pkg_add gdb > egdb ncmpcpp ncmpcpp.core > bt (gdb) bt #0 _libc_pthread_mutex_unlock (mutexp=<optimized out>) at /usr/src/lib/libc/thread/rthread_mutex.c:246 #1 0x00000ea982e20277 in std::__1::__libcpp_mutex_unlock (__m=0xea9c55edb98) at /usr/src/lib/libcxx/include/__threading_support:266 #2 std::__1::mutex::unlock (this=0xea9c55edb98) at /usr/src/lib/libcxx/src/mutex.cpp:45 #3 0x00000ea77d9fb21d in ?? () #4 0x00000ea77da587b5 in ?? () #5 0x00000ea77db3e808 in ?? () #6 0x00000ea77daafdf3 in ?? () #7 0x00000ea77db140d0 in ?? () #8 0x00000ea77d9b9a21 in ?? () #9 0x0000000000000000 in ?? () (gdb) > If the lines output from "bt" don't have function names in, > rebuild ncmpcpp with "make clean; DEBUG=-g make repackage reinstall" > and try again. Does rebuild suggestion still apply based on gdb output above? Erling
