On Thu, Jan 21, 2016 at 09:04:11AM +0100, Dan Fandrich wrote:
> I upgraded to the git libssh2 with GnuTLS 3.2.21 on x86 Linux a few days ago
> for my curl autobuilds, and they've been hanging ever since on many libssh2
> tests (e.g. 609, 620, 626, 635, but I suspect it's a race condition on connect
> and the actual test number doesn't make a difference). I haven't spent much
> time looking into it yet, but a high proportion of the tests end up with the
> CPU spinning at 100%. I've attached gdb in a couple of cases and the backtrace
> either looks like this:
>
> #0 0xb7682ee8 in Loop () from /lib/libgcrypt.so.11
> #1 0x07c09aa4 in ?? ()
> #2 0xb76b8000 in ?? () from /lib/libgcrypt.so.11
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> or like this:
>
> #0 0xb761661f in mul_n () from /lib/libgcrypt.so.11
> #1 0xb7616762 in mul_n () from /lib/libgcrypt.so.11
> #2 0xb761647a in mul_n () from /lib/libgcrypt.so.11
> #3 0xb761732d in _gcry_mpih_mul_karatsuba_case () from /lib/libgcrypt.so.11
> #4 0xb7613324 in mul_mod () from /lib/libgcrypt.so.11
> #5 0xb7613baa in _gcry_mpi_powm () from /lib/libgcrypt.so.11
> #6 0xb75c2d94 in gcry_mpi_powm () from /lib/libgcrypt.so.11
> #7 0xb765c3dd in diffie_hellman_sha256 (packet_type_init=<optimized out>,
> packet_type_reply=<optimized out>, exchange_state=<optimized out>, midhash_len=<optimized out>,
> midhash=<optimized out>, group_order=<optimized out>, p=<optimized out>, g=<optimized out>,
> session=<optimized out>) at /home/build/src/libssh2/src/kex.c:757
> #8 kex_method_diffie_hellman_group_exchange_sha256_key_exchange (session=0x9d245f8,
> key_state=0x9d31170) at /home/build/src/libssh2/src/kex.c:1657
> #9 0xb765dc6b in _libssh2_kex_exchange (session=0x9d245f8, reexchange=0, key_state=0x9d31164)
> at /home/build/src/libssh2/src/kex.c:2542
> #10 0xb76647d2 in session_startup (sock=3, session=0x9d245f8)
> at /home/build/src/libssh2/src/session.c:723
> #11 libssh2_session_handshake (session=0x9d245f8, sock=3) at /home/build/src/libssh2/src/session.c:801
> #12 0xb770c0d5 in ssh_statemach_act () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4
> #13 0xb770fcf5 in ssh_multi_statemach () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4
> #14 0xb76f04f3 in Curl_protocol_connecting ()
> from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4
> #15 0xb7703d58 in multi_runsingle () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4
> #16 0xb770487c in curl_multi_perform () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4
> #17 0xb76fbfbc in curl_easy_perform () from /tmp/tmp.95BPIzfHtd/build-29924/lib/.libs/libcurl.so.4
> #18 0x080520f2 in operate_do ()
> #19 0x08053af3 in operate ()
> #20 0x080499d7 in main ()
>
> The couple of times I caught this, everything from level #7 to the bottom was the same.
> I'll try to get a chance to bisect the problem, but in any case, it's not quite
> in a releasable state.
I looked into this and the loop is happening within gcry_mpi_powm due to an
invalid internal condition. I've brought it to the gcrypt devel mailing list.
The code calling this is new in libssh2 (commit fc4a969a) but still, gcrypt
shouldn't be hanging like this.
>>> Dan
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2016-02-06