W dniu środa, 24 maja 2017 15:14:26 UTC+2 użytkownik Przemysław Sobala 
napisał:
>
> 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?
>
 

>  Another stack. Maybe that one will be more clear to you:
(gdb) bt
#0  0x00007efd3665a765 in raise () from /lib64/libc.so.6
#1  0x00007efd3665c483 in abort () from /lib64/libc.so.6
#2  0x00000000004b79b3 in MagickPanicSignalHandler (signo=11) at 
magick/magick.c:840
#3  <signal handler called>
#4  heap_insert (less_than=0x812f40 <timer_less_than>, 
newnode=0x7ffd799e8ab8, heap=0xc28a28 <default_loop_struct+520>) at 
./src/heap-inl.h:140
#5  uv_timer_start (handle=0x7ffd799e8a50, cb=0x417abe 
<imageresizer::engine::FileDownloader::on_timeout_cb(uv_timer_s*)>, 
timeout=<optimized out>, repeat=0) at src/unix/timer.c:84
#6  0x0000000000417c0c in 
imageresizer::engine::FileDownloader::start_timeout (this=0x7ffd799e8a10, 
multi=0x2c0cdd0, timeout_ms=96) at src/engine/FileDownloader.cpp:249
#7  0x0000000000417baf in 
imageresizer::engine::FileDownloader::start_timeout_cb (multi=0x2c0cdd0, 
timeout_ms=96, userp=0x7ffd799e8a10) at src/engine/FileDownloader.cpp:237
#8  0x00000000007c7665 in update_timer ()
#9  0x00000000007cb098 in curl_multi_socket_action ()
#10 0x0000000000417b3f in imageresizer::engine::FileDownloader::on_timeout 
(this=0x7ffd799e8a10, handle=0x7ffd799e8a50) at 
src/engine/FileDownloader.cpp:231
#11 0x0000000000417ae0 in 
imageresizer::engine::FileDownloader::on_timeout_cb (handle=0x7ffd799e8a50) 
at src/engine/FileDownloader.cpp:223
#12 0x00000000008134a5 in uv__run_timers (loop=loop@entry=0xc28820 
<default_loop_struct>) at src/unix/timer.c:165
#13 0x000000000080becc in uv_run (loop=0xc28820 <default_loop_struct>, 
mode=UV_RUN_DEFAULT) at src/unix/core.c:343
#14 0x0000000000417409 in imageresizer::engine::FileDownloader::StartLoop 
(this=0x7ffd799e8a10) at src/engine/FileDownloader.cpp:97


-- 
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.

Reply via email to