[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: instability
[Thread Prev] | [Thread Next]
- Subject: Re: instability
- From: Aris Adamantiadis <aris@xxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Tue, 24 May 2011 10:07:51 +0200
- To: libssh@xxxxxxxxxx
Hi Jeetu, No problem, as long as you mutex your ssh_bind stuff. If it is in its own thread (only one parallel execution), there is no problem. The crash you got is typical of a missing standalone ssh_init(); before calling ssh_connect and friends in threads. If you are using server support, I strongly recommend that you use libssh 0.5rc1, in which we fixed many bugs for servers. In that case, please read http://api.libssh.org/master/libssh_tutor_threads.html for more info on threading. Kr, Aris Le 24/05/11 05:47, jeetu.golani@xxxxxxxxx a écrit : > Hi Aris, > >>With libssh 0.5, it's a little different, you have to initialize libssh > threads and call ssh_init(). (libssh does the dirty work of > initilalizing >libcrypto or libgcrypt). > > Just want to clarify if what I'm doing for my libssh server is all > right. In principle I have a new ssh_session created for each new > connection into the server. > > My ssh_bind is common for all threads and I call ssh_bind_listen. I have > a ssh_session *session (therefore session is a pointer to a pointer) and > I init this pointer first with an session = ssh_new().....I then move > into a loop where I init an individual session element such as > session[session_count] = ssh_new and then move onto waiting to accept a > connection with a ssh_bind_option...authenticating user...and finally if > authenticated create a new glib thread for that server > session....incremenet session_count.... and this loops. > > Sorry for trying to describe code instead of pasting the relevant > snippet here but I don't have access to my comp with the code right now. > > Does the above seem in principle to be acceptable and in line with > libssh's threading model....or would ppl recommend a better way to have > a multi-threaded server. > > Thanks, > > Bye > > > On Tue, May 24, 2011 at 2:54 AM, Paulo Panhoto <paulo.panhoto@xxxxxxxxx > <mailto:paulo.panhoto@xxxxxxxxx>> wrote: > > There are several threads running but each session is only accessed > by one thread. > > Sure, it does help. thanks. > > > On Mon, May 23, 2011 at 6:22 PM, Aris Adamantiadis > <aris@xxxxxxxxxxxx <mailto:aris@xxxxxxxxxxxx>> wrote: > > Hi Paulo, > > Are you using libssh in several threads ? Libssh is threadsafe > under two conditions : call ssh_init() outside of threads and > initialize threading in the crypto library > (http://www.openssl.org/support/faq.html#PROG1). > With libssh 0.5, it's a little different, you have to initialize > libssh threads and call ssh_init(). (libssh does the dirty work > of initilalizing libcrypto or libgcrypt). > > Hope this helps, > > Aris > > Le 23/05/11 21:41, Paulo Panhoto a écrit : > > Hello, > > I'm writing a Qt app with libssh. The best approach I've got > was this: > wrap ssh in a QThread that emits signals to other components. > > > session = ssh_new(); > > if (session == NULL) > { > throw SSHException(tr("ssh_new failed")); > } > const std::string & stdHost = host.toStdString(); > ssh_options_set(session, SSH_OPTIONS_HOST, > stdHost.c_str()); > ssh_options_set(session, SSH_OPTIONS_PORT, &port); > ssh_options_set(session, SSH_OPTIONS_SSH1, &disabled); > ssh_options_set(session, SSH_OPTIONS_SSH2, &enabled); > > emit stateChanged(CONNECTING); > emit debugInfo(tr("Conecting to > %0:%1").arg(host).arg(port)); > if (ssh_connect(session) != SSH_OK) > { > throw SSHException(QString("ssh_connect: > %1").arg(ssh_get_error(session))); > } > > This piece of code is causing me trouble: I'm running it on > a opensuse > 11.3 and tested it with libssh 0.4.2 (the "branding" > release) and 0.4.8. > > When I compile it against OpenSSL, I get aborts due to > double free > inside libcrypto: works most of the time when I run it natively. > Nevertheless, when the program is run via xming server, the > error rate > is almost 100% > libopenssl 1.0.0-6.7.1 - x86_64 > > #0 0x00007ffff5aca9e5 in raise () from /lib64/libc.so.6 > #1 0x00007ffff5acbee6 in abort () from /lib64/libc.so.6 > #2 0x00007ffff5b05c53 in __libc_message () from > /lib64/libc.so.6 > #3 0x00007ffff5b0b226 in malloc_printerr () from > /lib64/libc.so.6 > #4 0x00007ffff5b0e8e3 in _int_realloc () from /lib64/libc.so.6 > #5 0x00007ffff5b10142 in realloc () from /lib64/libc.so.6 > #6 0x00007ffff4ca6d4f in CRYPTO_realloc () from > /lib64/libcrypto.so.1.0.0 > #7 0x00007ffff4d0d2a8 in lh_insert () from > /lib64/libcrypto.so.1.0.0 > #8 0x00007ffff4ca980c in OBJ_NAME_add () from > /lib64/libcrypto.so.1.0.0 > #9 0x00007ffff4d1a66b in OpenSSL_add_all_digests () from > /lib64/libcrypto.so.1.0.0 > #10 0x00007ffff7bac3cc in ssh_crypto_init () at > /home/paulo/Downloads/oss-src/libssh-0.4.8/libssh/dh.c:144 > #11 0x00007ffff7bae8f1 in ssh_init () at > /home/paulo/Downloads/oss-src/libssh-0.4.8/libssh/init.c:47 > #12 0x00007ffff7ba929c in ssh_connect (session=0xc3b8e0) > > If I compile it against libgcrypt, it fails all the time due > to an > assertion failure -- ath.c:193: _gcry_ath_mutex_lock: > Assertion `*lock > == ((ath_mutex_t) 0)' failed. > libgcrypt 1.4.4-6.1 - x86-64 > > #0 0x00007ffff5ac79e5 in raise () from /lib64/libc.so.6 > #1 0x00007ffff5ac8ee6 in abort () from /lib64/libc.so.6 > #2 0x00007ffff4fdcaa8 in ?? () from /lib64/libgcrypt.so.11 > #3 0x00007ffff4fdd1c7 in ?? () from /lib64/libgcrypt.so.11 > #4 0x00007ffff4fd75f6 in ?? () from /lib64/libgcrypt.so.11 > #5 0x00007ffff4fd7792 in ?? () from /lib64/libgcrypt.so.11 > #6 0x00007ffff7ba8f7b in ssh_crypto_init () > at > /home/paulo/Downloads/oss-src/libssh-0.4.8/libssh/dh.c:115 > #7 0x00007ffff7bab961 in ssh_init () > at > /home/paulo/Downloads/oss-src/libssh-0.4.8/libssh/init.c:47 > #8 0x00007ffff7ba5ebc in ssh_connect (session=0xccf260) > at > /home/paulo/Downloads/oss-src/libssh-0.4.8/libssh/client.c:516 > > Am I missing any steps?? Is openSSL the best library to > compile with?? > > Any idea is appreciated. > > Regards, > > Paulo. > > > >
Re: instability | "jeetu.golani@xxxxxxxxx" <jeetu.golani@xxxxxxxxx> |
instability | Paulo Panhoto <paulo.panhoto@xxxxxxxxx> |
Re: instability | Aris Adamantiadis <aris@xxxxxxxxxxxx> |
Re: instability | Paulo Panhoto <paulo.panhoto@xxxxxxxxx> |
Re: instability | "jeetu.golani@xxxxxxxxx" <jeetu.golani@xxxxxxxxx> |