-
Notifications
You must be signed in to change notification settings - Fork 0
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
Modify network topology, consistency changes #4
Modify network topology, consistency changes #4
Conversation
Modify network topology, consistency changes
No worries with anything you said there, I didn't deliberately change video to web client, as I drew the image I wanted to show both a mobile client and the standard client and web was the first word that came to mind. And I didn't spend too much time editing your points so never saw the mismatch. I will merge this, you can merge as is to multi-server and then PR any extra changes direct rather than being held up by me being asleep. |
On successful login, tell php to regenerate the session id
==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)
Make sure we don't read past the end of global_edges when i = 0. We are moving the elements backwards so at most n_global_edges - 1 elements can be moved. ==6818==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffff888ae00 at pc 0x7fe4fd7be8ae bp 0x7ffff888ac90 sp 0x7ffff888a440 READ of size 96 at 0x7ffff888ae00 thread T0 #0 0x7fe4fd7be8ad in __interceptor_memmove (/lib/x86_64-linux-gnu/libasan.so.5+0x378ad) #1 0x56524b2dba31 in Image::Fill(unsigned int, int, Polygon const&) /root/zoneminder/src/zm_image.cpp:2514 #2 0x56524af55530 in Monitor::DumpZoneImage(char const*) /root/zoneminder/src/zm_monitor.cpp:1510 #3 0x56524aeb38cb in main /root/zoneminder/src/zmu.cpp:574 #4 0x7fe4fb2b009a in __libc_start_main ../csu/libc-start.c:308 #5 0x56524aeb87a9 in _start (/root/zoneminder/cmake-build-relwithdebinfo-remote/src/zmu+0xf87a9)
Make sure we don't read past the end of global_edges when i = 0. We are moving the elements backwards so at most n_global_edges - 1 elements can be moved. ==6818==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffff888ae00 at pc 0x7fe4fd7be8ae bp 0x7ffff888ac90 sp 0x7ffff888a440 READ of size 96 at 0x7ffff888ae00 thread T0 #0 0x7fe4fd7be8ad in __interceptor_memmove (/lib/x86_64-linux-gnu/libasan.so.5+0x378ad) #1 0x56524b2dba31 in Image::Fill(unsigned int, int, Polygon const&) /root/zoneminder/src/zm_image.cpp:2514 #2 0x56524af55530 in Monitor::DumpZoneImage(char const*) /root/zoneminder/src/zm_monitor.cpp:1510 #3 0x56524aeb38cb in main /root/zoneminder/src/zmu.cpp:574 #4 0x7fe4fb2b009a in __libc_start_main ../csu/libc-start.c:308 #5 0x56524aeb87a9 in _start (/root/zoneminder/cmake-build-relwithdebinfo-remote/src/zmu+0xf87a9) (cherry picked from commit 63cea99)
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
In my opinion, the drawing is a lot easier to read if the lines are kept as straight as possible.
The previous diagram failed to separate the Storage LAN from devices that did not need to be on it. Semantics used in the diagram are keyed to the semantics in the installation instructions. Don't change one without changing the other.