#186: libssh gets stuck at kex_method_diffie_hellman_groupGP_sha1_key_exchange.
CPU utilization goes upto 100%
---------------------------------------------------------------------------------------+
Reporter: www.google.com/accounts/o8/id?id=aitoawlhggg_yplkl7grwwpbbum-omtqud4rmna | Owner: bagder
Type: defect | Status: assigned
Priority: normal | Milestone: 1.2.8
Component: crypto | Version: 1.2.2
Resolution: | Keywords:
Blocks: | Blocked By:
---------------------------------------------------------------------------------------+
Comment (by www.google.com/accounts/o8/id?id=aitoawlhggg_yplkl7grwwpbbum-omtqud4rmna):
Replying to [comment:4 stuge]:
My apologies for the late reply.
> Replying to [comment:3 www.google.com/accounts/o8/id?id
=aitoawlhggg_yplkl7grwwpbbum-omtqud4rmna]:
> > It gets stuck in the gcrypt's , gcry_mpi_copy () function, with the
cpu utilization going to 100% and staying that way till we terminate the
process.
>
> Are you positive that it is really stuck inside the libgcrypt function,
and that the problem is not that the function is called over and over?
>
Yes, please see below
> Can you work with gdb when it gets stuck? Step through? What does it
actually do in that function? Also, it would be helpful to build a
libgcrypt which includes debugging symbols.
>
I did this and now the backtrace is
(gdb) bt
#0 gcry_mpi_powm (res=0x14ba5d10, base=<value optimized out>, expo=<value
optimized out>, mod=<value optimized out>)
at mpi-pow.c:241
#1 0x00007f4a30c8eb77 in
kex_method_diffie_hellman_groupGP_sha1_key_exchange (session=0x1473b040,
g=0x137d1050,
p=0x137d31c0, group_order=129, packet_type_init=32 ' ',
packet_type_reply=33 '!', midhash=0x14156241 "",
midhash_len=138, exchange_state=0x1473f440) at kex.c:108
#2 0x00007f4a30c9033c in
kex_method_diffie_hellman_group_exchange_sha1_key_exchange
(session=0x1473b040,
key_state=0x1473f428) at kex.c:881
#3 0x00007f4a30c90fb0 in libssh2_kex_exchange (session=0x1473b040,
reexchange=<value optimized out>, key_state=0x1473f410)
at kex.c:1761
#4 0x00007f4a30c98b7e in libssh2_session_startup (session=0x1473b040,
sock=18) at session.c:594
#5 0x00000000005a780d in SSHSession::issueSSHLibCmd ()
#6 0x00000000005a8315 in SSHSession::issueEagainLibCmds ()
#7 0x00000000005a891c in SSHSession::fdWriteReady ()
#8 0x00000000009df413 in Scheduler::run ()
#9 0x0000000000651434 in main ()
I can further confirm that its spinning in a loop inside gcry_mpi_powm. I
set a breakpoint in libssh2 code just after this offending call. Even
after a very long time control does not return there, so
(gdb) b kex.c:113
Note: breakpoint 11 also set at pc 0x7f4a30c8eb77.
Breakpoint 12 at 0x7f4a30c8eb77: file kex.c, line 113.
(gdb) c
Continuing.
The breakpoint never gets hit.
> If it really does get stuck inside libgcrypt then maybe the problem
isn't actually with libssh2. (Though it could also be a problem in libssh2
that gives libgcrypt bogus data and causes it to run off and do something
silly.)
Is there a way to find out which case this maybe. I can possibly
dissassmble the code and tell you the values of the arguements (which got
optimized out to be passed in registers) passed to the gcrypt function
(although I guess those could have been smashed as well, libgcrypt is
relying on a ton of handwritten assembly code).
Thanks for your help.
Jasmeet Bagga
-- Ticket URL: <http://trac.libssh2.org/ticket/186#comment:5> libssh2 <http://trac.libssh2.org/> C library for writing portable SSH2 clients _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2011-02-16