On Thu, 11 Nov 2010, CHEN Xiaolei A wrote:
please do not top post, because people tend to read from top to bottom not the
other way around!
It cored in the following thread. It seems that libssh2 access already free
memory when call crypt_encrypt.
... but why would libssh2 suddenly do something wrong when you go beyond 20
threads and work fine until then?
----------------- lwp# 2 / thread# 2 -------------------- 00000000 ????????
(1e5638, ff0ffd78, 0, 196310, 0, 0) ff0dce7c crypt_encrypt (1956a8, 196310,
195734, 0, 0, 1e5630) + 24 ff0fb6ac decrypt (1956a8, 1957d0, 1d12fb, 23a0,
3ffc, 1957d0) + d4 ff0fc2d0 _libssh2_transport_read (1956a8, 23b0, ff1011e8,
10, 0, 1957d0) + 6e0 ff0da5a0 _libssh2_channel_read (1a4460, 0, fea7b8f8, 4,
1809f8, 0) + 88 ff0ef870 sftp_packet_read (1a7898, 65, 3, fea7b9f8, fea7ba0c,
1956a8) + a8 ff0eff30 sftp_packet_requirev (1a7898, 2, ff1007e2, 3, fea7b9f8,
fea7ba0c) + c0 ff0f1f3c sftp_read (1dbcb0, b4efc, 4000, 0, 0, 0) + 34c
ff0f2298 libssh2_sftp_read
Is there anything more we can do?
Yes, first you build libssh2 and libcurl with debug symbols present so that
backtraces make sense.
Then you need to start narrowing things down. Like do all the 20 threads need
to transfer things for the bug to happen? Does the 20 threads all succeed in
what they are set out to do? Lots of SSH/SFTP servers limit the number of
simultaneous accesses they allow.
An additional experient would be to build libssh2 with gcrypt and have a go
with that and see if it fails in a similar way (it does require its own set of
mutex callbacks), as then we can truly suspect that the problem is outside of
the crypto layers.
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
