On Fri, Sep 11, 2020 at 09:09:39AM -0000, Stuart Henderson wrote:
> On 2020-09-10, Ashlen <eurydice@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
No comments:
Post a Comment