Hi, Did you include the configuration option, "--enable-threaded-resolver" ? I had such a problem, but fixed after building with the option.
Good luck. 2017-01-25 6:27 GMT+09:00 Pawel Veselov <[email protected]>: > Hi. > > I've been seeing libcurl failing, somewhat consistently, at > Curl_resolv_timeout. > > The "data" local variable seems to come up changed after longjmp returns. > > (gdb) bt > #0 Curl_resolv_timeout (conn=0x7ffe5002d770, hostname=0x7ffff6efb3c0 > <X509_NAME_ENTRY_it> "\001", port=0x7fff, entry=0x7ffe50013930, > timeoutms=0x7ffff6b9b4dd) at hostip.c:622 > ... > (gdb) print data > $10 = (struct Curl_easy *) 0x770000006e > (gdb) print *data > Cannot access memory at address 0x770000006e > (gdb) print conn->data > $12 = (struct Curl_easy *) 0x7ffe5002db40 > (gdb) print &data > $13 = (struct Curl_easy **) 0x7ffe68ff8380 > (gdb) print *(void**)0x7ffe68ff8380 > $14 = (void *) 0x770000006e > (gdb) info registers > rax 0x1 0x1 > rbx 0x7fff30017e7c 0x7fff30017e7c > rcx 0x7ffff659b8a0 0x7ffff659b8a0 > rdx 0x7ffff7b35a76 0x7ffff7b35a76 > rsi 0x1 0x1 > rdi 0x7ffff7ddac60 0x7ffff7ddac60 > rbp 0x7ffe68ff83a0 0x7ffe68ff83a0 > rsp 0x7ffe68ff81f0 0x7ffe68ff81f0 > r8 0x7ffe68ff81f0 0x7ffe68ff81f0 > r9 0x7ffe68ff83a0 0x7ffe68ff83a0 > r10 0x8 0x8 > r11 0x246 0x246 > r12 0x1 0x1 > r13 0x7ffe68ff99c0 0x7ffe68ff99c0 > r14 0x7ffe68ff9700 0x7ffe68ff9700 > r15 0x0 0x0 > rip 0x7ffff7b35a7a 0x7ffff7b35a7a <Curl_resolv_timeout+285> > eflags 0x202 [ IF ] > cs 0x33 0x33 > ss 0x2b 0x2b > ds 0x0 0x0 > es 0x0 0x0 > fs 0x0 0x0 > gs 0x0 0x0 > > I quite don't like the fact that the signal seems to interrupt the "wrong" > thread. Or interrupted the thread too late: > > (gdb) bt > #0 Curl_resolv_timeout (conn=0x7ffe5002d770, hostname=0x7ffff6efb3c0 > <X509_NAME_ENTRY_it> "\001", port=0x7fff, entry=0x7ffe50013930, > timeoutms=0x7ffff6b9b4dd) at hostip.c:622 > #1 0x00007ffe68ff9700 in ?? () > #2 0x000000000000007c in ?? () > #3 0x00007ffff7baf833 in ?? () from /mnt/xl4/100k/runtime/curl/ > lib/libcurl.so > #4 0x0000000000000001 in ?? () > #5 0x00007ffff71b83da in xmlCharEncInput () from /usr/lib64/libxml2.so.2 > #6 0x00007ffff6c163a2 in int_thread_release (hash=0x1d5f6c13f51) at > err.c:469 > #7 0x00007ffff6c166b5 in int_thread_del_item (d=<optimized out>) at > err.c:542 > #8 0x00007ffff6c170cd in ERR_remove_thread_state (id=<optimized out>) > at err.c:994 > #9 0x00007ffe68ff9700 in ?? () > #10 0x00007ffe68ff8760 in ?? () > #11 0x00007ffff7b6f1c1 in curl_dofree (ptr=0xffffffffffffffff, > line=0xffffffff, source=0xffffffffffffffff <Address 0xffffffffffffffff > out of bounds>) at memdebug.c:337 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > There are no threads that have their stack traces in Curl_resolv, which > should be the location when the alarm goes off. Note that I compiled > libcurl > without thread resolver. The same exact problem happens when thread > resolver > is on, however. The stack trace typically leads into some other thread as > well. > > This failure is consistent, that is if I break inside the setjmp return, > it always fails (the value of 'data' pointer is wrong) > > This is on 4.4.41-35.53 kernel, 2.17-106.168 glibc (AWS Linux). The same > happens on my Fedora desktop, different kernel/glibc versions. > > It also looks that the whole alarm functionality, even if threaded resolver > is used, is not MT safe because of shared setjmp buffer, and the fact that > the waiting (actual setjmp/longjmp calls) is done on the calling thread. Or > am I missing something here? > > Thank you, > Pawel. > ------------------------------------------------------------------- > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library > Etiquette: https://curl.haxx.se/mail/etiquette.html -- *원 태환*ㅣ 부사장/COO (주)솔박스 서울특별시 서초구 서초대로 77길 55 에이프로스퀘어 13층 *T* 02-2182-3600 *F* 02-2058-2651 *M* 010-3335-8258 *E* [email protected]
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
