Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource deadlock on program termination #137

Open
BenBE opened this issue Jan 24, 2022 · 2 comments
Open

Resource deadlock on program termination #137

BenBE opened this issue Jan 24, 2022 · 2 comments

Comments

@BenBE
Copy link
Collaborator

BenBE commented Jan 24, 2022

Okay, here's another one:

terminate called after throwing an instance of 'std::system_error'
  what():  Verklemmung beim Zugriff auf eine Ressource vermieden
==46880== 
==46880== Process terminating with default action of signal 6 (SIGABRT)
==46880==    at 0x568315B: raise (raise.c:51)
==46880==    by 0x5662858: abort (abort.c:79)
==46880==    by 0x536C910: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==46880==    by 0x537838B: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==46880==    by 0x5377368: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==46880==    by 0x5377D20: __gxx_personality_v0 (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==46880==    by 0x560FBEE: ??? (in /lib/x86_64-linux-gnu/libgcc_s.so.1)
==46880==    by 0x5610280: _Unwind_RaiseException (in /lib/x86_64-linux-gnu/libgcc_s.so.1)
==46880==    by 0x537869B: __cxa_throw (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==46880==    by 0x536F73E: std::__throw_system_error(int) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==46880==    by 0x53A505F: std::thread::join() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==46880==    by 0x12B0DB: drop_background(background_t*) (background.cc:133)
==46880==    by 0x12E2BB: std::_Sp_counted_deleter<background_t*, void (*)(background_t*), std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose() (shared_ptr_base.h:471)
==46880==    by 0x129729: std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() (shared_ptr_base.h:155)
==46880==    by 0x128FA2: std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() (shared_ptr_base.h:730)
==46880==    by 0x128C79: std::__shared_ptr<background_t, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() (shared_ptr_base.h:1169)
==46880==    by 0x128C99: std::shared_ptr<background_t>::~shared_ptr() (shared_ptr.h:103)
==46880==    by 0x12AEA7: read_thread(std::weak_ptr<background_t>) (background.cc:116)
==46880==    by 0x12E5FD: void std::__invoke_impl<void, void (*)(std::weak_ptr<background_t>), std::weak_ptr<background_t> >(std::__invoke_other, void (*&&)(std::weak_ptr<background_t>), std::weak_ptr<background_t>&&) (invoke.h:60)
==46880==    by 0x12E53B: std::__invoke_result<void (*)(std::weak_ptr<background_t>), std::weak_ptr<background_t> >::type std::__invoke<void (*)(std::weak_ptr<background_t>), std::weak_ptr<background_t> >(void (*&&)(std::weak_ptr<background_t>), std::weak_ptr<background_t>&&) (invoke.h:95)
==46880==    by 0x12E49A: void std::thread::_Invoker<std::tuple<void (*)(std::weak_ptr<background_t>), std::weak_ptr<background_t> > >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) (thread:244)
==46880==    by 0x12E42D: std::thread::_Invoker<std::tuple<void (*)(std::weak_ptr<background_t>), std::weak_ptr<background_t> > >::operator()() (thread:251)
==46880==    by 0x12E3BF: std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(std::weak_ptr<background_t>), std::weak_ptr<background_t> > > >::_M_run() (thread:195)
==46880==    by 0x53A4DE3: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28)
==46880==    by 0x5623608: start_thread (pthread_create.c:477)
==46880==    by 0x575F262: clone (clone.S:95)

Stack trace originates from running inside callgrind (for performance measurement), but I saw the same issue also running backscrub plain …

@phlash
Copy link
Collaborator

phlash commented Jan 26, 2022

Hmmn, that seems to be the read_thread trying to join itself because it held the last reference to the shared_ptr.. might want to review the use of shared_ptr (again!)

@BenBE
Copy link
Collaborator Author

BenBE commented Jan 26, 2022

Good hint. Will have a look at this once I pushed the un-related commits from the multipass branch to experimental.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants