Hi, I managed to reproduce this on amd64 under valgrind!
==18796== Invalid read of size 8 ==18796== at 0x7C41A14: Curl_resolv_timeout (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x3E7: ??? ==18796== Address 0x184e7368 is on thread 1's stack ==18796== ==18796== Invalid write of size 8 ==18796== at 0x7C41A27: Curl_resolv_timeout (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x3E7: ??? ==18796== Address 0x184e7348 is on thread 1's stack ==18796== ==18796== Invalid write of size 1 ==18796== at 0x7C58732: ??? (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x7C58DBC: ??? (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x7C59EB4: curl_mvsnprintf (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x7C4B21E: Curl_failf (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x7C41A2B: Curl_resolv_timeout (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x3E7: ??? ==18796== Address 0x820 is not stack'd, malloc'd or (recently) free'd ==18796== ==18796== ==18796== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==18796== Access not within mapped region at address 0x820 ==18796== at 0x7C58732: ??? (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x7C58DBC: ??? (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x7C59EB4: curl_mvsnprintf (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x7C4B21E: Curl_failf (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x7C41A2B: Curl_resolv_timeout (in /usr/lib/libcurl-gnutls.so.4.2.0) ==18796== by 0x3E7: ??? ==18796== If you believe this happened as a result of a stack ==18796== overflow in your program's main thread (unlikely but ==18796== possible), you can try to increase the size of the ==18796== main thread stack using the --main-stacksize= flag. ==18796== The main thread stack size used in this run was 8388608. ==18796== ==18796== Process terminating with default action of signal 11 (SIGSEGV) ==18796== Access not within mapped region at address 0x184E5BA8 ==18796== at 0x9469A5F: munmap (syscall-template.S:83) ==18796== If you believe this happened as a result of a stack ==18796== overflow in your program's main thread (unlikely but ==18796== possible), you can try to increase the size of the ==18796== main thread stack using the --main-stacksize= flag. ==18796== The main thread stack size used in this run was 8388608. ==18796== ==18796== HEAP SUMMARY: ==18796== in use at exit: 5,156,725 bytes in 29,087 blocks ==18796== total heap usage: 664,392 allocs, 635,305 frees, 480,989,388 bytes allocated ==18796== ==18796== LEAK SUMMARY: ==18796== definitely lost: 106,004 bytes in 2,546 blocks ==18796== indirectly lost: 85,467 bytes in 2,340 blocks ==18796== possibly lost: 3,919,809 bytes in 17,064 blocks ==18796== still reachable: 1,045,445 bytes in 7,137 blocks ==18796== suppressed: 0 bytes in 0 blocks ==18796== Rerun with --leak-check=full to see details of leaked memory ==18796== ==18796== For counts of detected and suppressed errors, rerun with: -v ==18796== Use --track-origins=yes to see where uninitialised values come from ==18796== ERROR SUMMARY: 1461 errors from 6 contexts (suppressed: 7 from 7) Segmentation fault I'll now upgrade foxtrotgps and see if that helps. I think the bug might be in libcurl however. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
