W dniu środa, 24 maja 2017 14:50:27 UTC+2 użytkownik Przemysław Sobala napisał: > > Hi, under some stress (10 downlaoding requests per sec) my program > (described in this thread) occasionally crashes with segmentation fault > (SIGSEGV). > > Can you help me resolve this issue? > > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7f58cffff700 (LWP 10505) 0x00007f58ea4a8765 in raise () > from /lib64/libc.so.6 > 2 Thread 0x7f58ec434980 (LWP 10496) 0x00007f58ea842bd0 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > 3 Thread 0x7f58e6e56700 (LWP 10500) 0x00007f58ea577307 in > epoll_pwait () from /lib64/libc.so.6 > 4 Thread 0x7f58e7e58700 (LWP 10498) 0x00007f58ea845afd in > __lll_lock_wait () from /lib64/libpthread.so.0 > 5 Thread 0x7f58e8659700 (LWP 10497) 0x00007f58ea577307 in > epoll_pwait () from /lib64/libc.so.6 > 6 Thread 0x7f58cf7fe700 (LWP 10506) 0x00007f58ea56722d in write () > from /lib64/libc.so.6 > 7 Thread 0x7f58e7657700 (LWP 10499) 0x00007f58ea577307 in > epoll_pwait () from /lib64/libc.so.6 > 8 Thread 0x7f58e6655700 (LWP 10501) 0x00007f58ea577307 in > epoll_pwait () from /lib64/libc.so.6 > 9 Thread 0x7f58e5e54700 (LWP 10502) 0x00007f58ea577307 in > epoll_pwait () from /lib64/libc.so.6 > 10 Thread 0x7f58e4e52700 (LWP 10504) 0x00007f58ea577307 in > epoll_pwait () from /lib64/libc.so.6 > 11 Thread 0x7f58e5653700 (LWP 10503) 0x00007f58ea577307 in > epoll_pwait () from /lib64/libc.so.6 > > thread 1 stack: > #0 0x00007f58ea4a8765 in raise () from /lib64/libc.so.6 > #1 0x00007f58ea4aa483 in abort () from /lib64/libc.so.6 > #2 0x00000000004b7a23 in MagickPanicSignalHandler (signo=11) at > magick/magick.c:835 > #3 <signal handler called> > #4 0x0000000000813162 in heap_remove (less_than=0x812fc0 > <timer_less_than>, node=0x7ffddd63ec98, heap=0xc28a28 > <default_loop_struct+520>) at ./src/heap-inl.h:187 > #5 uv_timer_stop (handle=0x7ffddd63ec30) at src/unix/timer.c:97 > #6 0x000000000081341d in uv_timer_start (handle=0xffffffffffffff98, > cb=<optimized out>, timeout=<optimized out>, repeat=<optimized out>) at > src/unix/timer.c:87 > #7 0x00007ffddd63ebf0 in ?? () > #8 0x0000000000417c74 in > imageresizer::engine::FileDownloader::start_timeout (this=0x1f1, > multi=0x7f58eb73ca60, timeout_ms=140019881360094) at > src/engine/FileDownloader.cpp:249 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > In the same project I'm using GraphicsMagick that registers its own signal > handler hence frame #2, but still it looks like uv_timer_stop throws > SIGSEGV > > thread 2 is gRPC server thread, thread 3 is gRPC's completion queue thread > > thread 4 is locked on curl multi handle during on_timeout callback: > (gdb) bt > #0 0x00007f58ea845afd in __lll_lock_wait () from /lib64/libpthread.so.0 > #1 0x00007f58ea83fa0d in pthread_mutex_lock () from /lib64/libpthread.so.0 > #2 0x0000000000416d81 in __gthread_mutex_lock (__mutex=0x7ffddd63ed70) at > /usr/include/c++/6.3.1/x86_64-redhat-linux/bits/gthr-default.h:748 > #3 0x0000000000418032 in std::mutex::lock (this=0x7ffddd63ed70) at > /usr/include/c++/6.3.1/bits/std_mutex.h:101 > #4 0x0000000000418209 in imageresizer::util::Lock::Lock > (this=0x7f58e7e57a70, m=...) at ./src/util/Lock.h:21 > #5 0x0000000000417b77 in imageresizer::engine::FileDownloader::on_timeout > (this=0x7ffddd63ebf0, handle=0x7ffddd63ec30) at > src/engine/FileDownloader.cpp:230 > #6 0x0000000000417b48 in > imageresizer::engine::FileDownloader::on_timeout_cb (handle=0x7ffddd63ec30) > at src/engine/FileDownloader.cpp:223 > #7 0x0000000000813515 in uv__run_timers (loop=0x7ffddd63ed70) at > src/unix/timer.c:159 > #8 0x000000000080bf3c in uv__update_time (loop=0xc28820 > <default_loop_struct>) at src/unix/internal.h:316 > #9 uv_run (loop=0xc28820 <default_loop_struct>, mode=UV_RUN_DEFAULT) at > src/unix/core.c:342 > #10 0x0000000000417474 in imageresizer::engine::FileDownloader::StartLoop > (this=0x7ffddd63ebf0) at src/engine/FileDownloader.cpp:96 > #11 0x000000000041979a in std::__invoke_impl<void, void > (imageresizer::engine::FileDownloader::* const&)(), > imageresizer::engine::FileDownloader*>(std::__invoke_memfun_deref, void > (imageresizer::engine::FileDownloader::* const&)(), image > resizer::engine::FileDownloader*&&) ( > __f=@0x1a323f0: (void (imageresizer::engine::FileDownloader::*)( > imageresizer::engine::FileDownloader * const)) 0x4173e4 <imageresizer:: > engine::FileDownloader::Add(std::__cxx11::basic_string<char, std:: > char_traits<char>, std::allocato > r<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std:: > allocator<char> >, std::function<void ()>, std::function<void ( > imageresizer::DownloadFileError const&)>)+670>, > __t=<unknown type in /opt/WP/imageresizer-worker/dist/Debug/GNU-Linux/ > imageresizer-worker, CU 0x1cd0b, DIE 0x2a784>) at /usr/include/c++/6.3.1/ > functional:227 > #12 0x0000000000419727 in std::__invoke<void > (imageresizer::engine::FileDownloader::* const&)(), > imageresizer::engine::FileDownloader*>(void > (imageresizer::engine::FileDownloader::* const&)(), > imageresizer::engine::FileDownloader*&&) ( > __fn=@0x1a323f0: (void (imageresizer::engine::FileDownloader<span >
I've commented out logging, so they don't interfere, and know i don't know what to say. Just look at this: (gdb) info threads Id Target Id Frame * 1 Thread 0x7f1c5550f700 (LWP 10974) 0x00007f1c57b5f765 in raise () from /lib64/libc.so.6 2 Thread 0x7f1c59aeb980 (LWP 10972) 0x00007f1c57ef9bd0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 0x7f1c55d10700 (LWP 10973) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 4 Thread 0x7f1c4ffff700 (LWP 10976) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 5 Thread 0x7f1c4effd700 (LWP 10978) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 6 Thread 0x7f1c4d7fa700 (LWP 10981) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 7 Thread 0x7f1c4dffb700 (LWP 10980) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 8 Thread 0x7f1c4f7fe700 (LWP 10977) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 9 Thread 0x7f1c4e7fc700 (LWP 10979) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 10 Thread 0x7f1c54d0e700 (LWP 10975) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 11 Thread 0x7f1c4cff9700 (LWP 10982) 0x00007f1c57c2e307 in epoll_pwait () from /lib64/libc.so.6 (gdb) bt #0 0x00007f1c57b5f765 in raise () from /lib64/libc.so.6 #1 0x00007f1c57b61483 in abort () from /lib64/libc.so.6 #2 0x00000000004b7a23 in GetMagickInfoArray (exception=0xc28820 <default_loop_ptr>) at magick/magick.c:548 #3 0x0000000000000000 in ?? () GraphicsMagick is being linked in staticly but no GraphicsMagick code is being invoked during my stress test, only libuv and libcurl functions. Can you tell me what am I missing here? -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
