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

Path zms message #7

Conversation

knight-of-ni
Copy link

changes to rst files

@connortechnology connortechnology merged commit 501cbe2 into connortechnology:path_zms_message Dec 20, 2016
connortechnology pushed a commit that referenced this pull request Feb 15, 2017
Tell PDO to use real prepared statements.
connortechnology pushed a commit that referenced this pull request May 5, 2017
@knight-of-ni knight-of-ni deleted the path_zms_message branch November 24, 2018 01:55
connortechnology pushed a commit that referenced this pull request May 10, 2021
==8109==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fab9b156480 at pc 0x7fabaebef57b bp 0x7fab9b154640 sp 0x7fab9b153df0
READ of size 32 at 0x7fab9b156480 thread T2
    #0 0x7fabaebef57a  (/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
    #1 0x561c0a9e24eb in bool std::__equal<true>::equal<char>(char const*, char const*, char const*) /usr/include/c++/8/bits/stl_algobase.h:814
    #2 0x561c0a9dfa8e in bool std::__equal_aux<char*, char*>(char*, char*, char*) /usr/include/c++/8/bits/stl_algobase.h:831
    #3 0x561c0a9dd982 in bool std::equal<__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >
, __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >(__gnu_cxx::__normal_iterator<char*,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::c
har_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>
> >) /usr/include/c++/8/bits/stl_algobase.h:1049
    #4 0x561c0a9cf75a in RtspThread::Run() /root/zoneminder/src/zm_rtsp.cpp:411
    #5 0x561c0a9df6e9 in void std::__invoke_impl<void, void (RtspThread::*)(), RtspThread*>(std::__invoke_memfun_deref, void (RtspThread::*&&)(), RtspThread*&
&) /usr/include/c++/8/bits/invoke.h:73
    #6 0x561c0a9dd4ae in std::__invoke_result<void (RtspThread::*)(), RtspThread*>::type std::__invoke<void (RtspThread::*)(), RtspThread*>(void (RtspThread::
*&&)(), RtspThread*&&) (/root/zoneminder/cmake-build-debug-remote/src/zmc+0x1544ae)
    #7 0x561c0a9e6a1a in decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (RtspThread::*)(), RtspThread*> >
::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) /usr/include/c++/8/thread:244
    #8 0x561c0a9e698d in std::thread::_Invoker<std::tuple<void (RtspThread::*)(), RtspThread*> >::operator()() /usr/include/c++/8/thread:253
    #9 0x561c0a9e68ff in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (RtspThread::*)(), RtspThread*> > >::_M_run() /usr/include/c++/8/threa
d:196
    #10 0x7fabaca57b2e  (/lib/x86_64-linux-gnu/libstdc++.so.6+0xbbb2e)
    #11 0x7fabae50dfa2 in start_thread /build/glibc-vjB4T1/glibc-2.28/nptl/pthread_create.c:486
    #12 0x7fabac7354ce in clone (/lib/x86_64-linux-gnu/libc.so.6+0xf94ce)
connortechnology pushed a commit that referenced this pull request Apr 18, 2022
Notifying `mCondition` without taking the lock causes a race condition
in ::process() between checking `mTerminate` and waiting for the
`mCondition`, which causes a dead lock. This commit moves writing to
`mTerminate` and notifying `mCondition` under the lock to eliminate race
condition and dead lock.

This is not theoretical. It has caused zmu to hang at exit on a
Raspberry Pi 4, exhuasting PHP-FPM process pool. The stacks below are
captured when running ZoneMinder 1.36.12-focal1 on Ubuntu 20.04:

(gdb) thread apply all bt

Thread 2 (Thread 0xffff80c1c880 (LWP 259988)):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0xaaaae0584e80 <dbQueue+176>) at ../sysdeps/nptl/futex-internal.h:183
#1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0xaaaae0584e28 <dbQueue+88>, cond=0xaaaae0584e58 <dbQueue+136>) at pthread_cond_wait.c:508
#2  __pthread_cond_wait (cond=0xaaaae0584e58 <dbQueue+136>, mutex=0xaaaae0584e28 <dbQueue+88>) at pthread_cond_wait.c:638
#3  0x0000ffff8700d670 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /lib/aarch64-linux-gnu/libstdc++.so.6
#4  0x0000aaaae0438f08 in zmDbQueue::process (this=0xaaaae0584dd0 <dbQueue>) at ./src/zm_db.cpp:250
#5  0x0000ffff87013fac in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6
#6  0x0000ffff891264fc in start_thread (arg=0xffffe60d84bf) at pthread_create.c:477
#7  0x0000ffff86dd767c in thread_start () at ../sysdeps/unix/sysv/linux/aarch64/clone.S:78

Thread 1 (Thread 0xffff80c23010 (LWP 259987)):
#0  __pthread_clockjoin_ex (threadid=281472841926784, thread_return=0x0, clockid=0, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
#1  0x0000ffff87014240 in std::thread::join() () from /lib/aarch64-linux-gnu/libstdc++.so.6
#2  0x0000aaaae04314d0 in exit_zmu (exit_code=0) at ./src/zmu.cpp:200
#3  0x0000aaaae042f4c8 in main (argc=<optimized out>, argv=<optimized out>) at ./src/zmu.cpp:797
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

Successfully merging this pull request may close these issues.

2 participants