On Mon, Jun 23, 2014 at 2:14 PM, Apollon Oikonomopoulos <[email protected]> wrote: > Hi, > > (Please Cc me on reply, I'm not subscribed to the list. Thanks.) > I'm trying to debug a (rather painful) issue that apparently lies either in > libcurl, or GnuTLS 3.2. It all started out with Debian bug #751886 [1], > where the software at hand (Ganeti) uses Haskell's FFI to call libcurl, which > in Debian is currently linked with GnuTLS 3.2. [...] > I managed to obtain a few meaningful backtraces from the segfaulting > instances, > all of them consistently happening during the handshake and all of them > with the same call trace like the one at the bottom of this message. Also, > debug output from a corrupted and a crashed handshake follow.
Hello Apollon, Could you get a valgrind trace of the failed instance (with crash or not)? I suspect there is a memory corruption somewhere and valgrind may be better than the debugger identifying it. > - With the same version of libcurl (7.37.0) linked against gnutls 2.12, luxid > works reliably. Actually the bug appeared when Debian switched to a gnutls > 3.2-linked version of libcurl. I tried out different combinations of > libcurl and GnuTLS versions, the only failing combinations were with > GnuTLS 3.2. Andreas mentioned a bug sometime ago that depended on having an application linked with both gnutls28 and gnutls26. Could that be the issue in that case too? regards, Nikos _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
