Open virtuald opened 8 months ago
Happening in 2024.2.1, seen in CI. Really hard to reproduce locally, but I caught this:
(gdb) bt #0 ___pthread_mutex_lock (mutex=0x7f5cac038) at pthread_mutex_lock.c:80 #1 0x00007f5cb569a7e0 in __gthread_mutex_lock (__mutex=0x7f5cac038) at /usr/include/x86_64-linux-gnu/c++/11/bits/gthr-default.h:749 #2 std::mutex::lock (this=0x7f5cac038) at /usr/include/c++/11/bits/std_mutex.h:100 #3 std::scoped_lock<std::mutex>::scoped_lock (__m=..., this=<synthetic pointer>) at /usr/include/c++/11/mutex:655 #4 HAL_StopNotifier (notifierHandle=<optimized out>, status=<optimized out>) at /work/hal/src/main/native/sim/Notifier.cpp:200 #5 0x00007f5cb122f541 in (anonymous namespace)::HeartbeatDaemon::Main() () from /home/virtuald/src/frc/robotpy-rev/rev/_rev.cpython-38-x86_64-linux-gnu.so #6 0x00007f5cb5939c4b in operator() (__closure=0x5587df615988) at /work/wpiutil/src/main/native/cpp/SafeThread.cpp:79 #7 std::__invoke_impl<void, wpi::detail::SafeThreadOwnerBase::Start(std::shared_ptr<wpi::SafeThreadBase>)::<lambda()> > (__f=...) at /usr/include/c++/11/bits/invoke.h:61 #8 std::__invoke<wpi::detail::SafeThreadOwnerBase::Start(std::shared_ptr<wpi::SafeThreadBase>)::<lambda()> > (__fn=...) at /usr/include/c++/11/bits/invoke.h:96 #9 std::thread::_Invoker<std::tuple<wpi::detail::SafeThreadOwnerBase::Start(std::shared_ptr<wpi::SafeThreadBase>)::<lambda()> > >::_M_invoke<0> (this=0x5587df615988) at /usr/include/c++/11/bits/std_thread.h:259 #10 std::thread::_Invoker<std::tuple<wpi::detail::SafeThreadOwnerBase::Start(std::shared_ptr<wpi::SafeThreadBase>)::<lambda()> > >::operator() (this=0x5587df615988) at /usr/include/c++/11/bits/std_thread.h:266 #11 std::thread::_State_impl<std::thread::_Invoker<std::tuple<wpi::detail::SafeThreadOwnerBase::Start(std::shared_ptr<wpi::SafeThreadBase>)::<lambda()> > > >::_M_run(void) (this=0x5587df615980) at /usr/include/c++/11/bits/std_thread.h:211 #12 0x00007f5cb54e31e3 in std::execute_native_thread_routine (__p=0x5587df615980) at ../../../../../libstdc++-v3/src/c++11/thread.cc:104 #13 0x00007f5cc36ac897 in start_thread (arg=<optimized out>) at pthread_create.c:444 #14 0x00007f5cc373380c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
If rev had a shutdown function we could just call it as everything is being torn down, and that would likely address this issue.
Happening in 2024.2.1, seen in CI. Really hard to reproduce locally, but I caught this: