abrt detected a crash. Comment: This just happens randomly about once a day on average, apparently only when the mail check plugin is turned on. Attached file: backtrace cmdline: gkrellm component: gkrellm executable: /usr/bin/gkrellm kernel: 2.6.31.5-127.fc12.x86_64 package: gkrellm-2.3.2-6.fc12 rating: 4 reason: Process was terminated by signal 6
Created attachment 374158 [details] File: backtrace
The crash seems to be inside libssl, changing component to openssl. Can you please check your openssl version, by doing from the cmdline: rpm -q openssl And if it is < 1.0.0-0.13.beta4.fc12, please upgrade it and see if this fixes things ?
From the backtrace it seems like gkrellm is calling openssl incorrectly. It should initialize it once in the main thread before the other threads are spawned and not do the initialization in each thread separately.
(In reply to comment #3) > From the backtrace it seems like gkrellm is calling openssl incorrectly. It > should initialize it once in the main thread before the other threads are > spawned and not do the initialization in each thread separately. Tomas, Thanks for the info, I assume that you mean that SSL_CTX_new() should be called only once. What gkrellm is currently doing is: -spawn thread -SSL_CTX_new() -stuff -SSL_CTX_free() -spawn thread -repeat And it does not spawn the next thread until the previous thread is done. Should this be safe ? I must add a note to this, that it does this *per mailbox*, so if there are 2 mailboxes configured, it could have 2 threads running at the same time, resulting in SSL_CTX_new() being called while another context already exists, I assume this would be a problem ? Dan, Do you have more then one remote account using ssl configured in the mail check plugin ?
No the problem is not calling SSL_CTX_new() multiple times but calling SSL_library_init() in one thread simultaneously with SSL_CTX_new() in another thread. Also note that there should be proper calls to CRYPTO_set_locking_callback() and so on if you want to use openssl in multiple threads simultaneously. See man CRYPTO_set_locking_callback.
gkrellm is not calling SSL_library_init() at all, does this get called automatically by SSL_CTX_new() when not done yet ? I'll look at CRYPTO_set_locking_callback().
Well it definitely should be explicitely calling SSL_library_init() if it wants to use libssl.
(In reply to comment #7) > Well it definitely should be explicitely calling SSL_library_init() if it wants > to use libssl. My bad, gkrellm was calling SSLeay_add_ssl_algorithms(), which is equivalent to calling SSL_library_init(), and it indeed was doing that in a threaded context, where the same call could be made simultaneous twice. Dan, I have made a build which fixes the ssl thread locking in the way Tomas describes and hopefully fixes your issue, can you please download gkrellm from here and see if that fixes things for you: http://koji.fedoraproject.org/koji/taskinfo?taskID=1833585 Thanks, Hans
Thank you all for your rapid response! My openssl version is openssl-1.0.0-0.13.beta4.fc12.x86_64 and yes, I am querying two remote mailboxes. I've installed your fixed build and am running it now. This bug only shows up randomly once a day on average (sometimes twice in a day, sometimes not for two days) so it will take a bit for me to tell you whether it seems to be working. Thanks again, Dan
*** Bug 543313 has been marked as a duplicate of this bug. ***
The new version appears to be stable. Thanks!
(In reply to comment #11) > The new version appears to be stable. Thanks! Thanks, I'll make an official update out of this then.
gkrellm-2.3.2-7.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gkrellm-2.3.2-7.fc12
gkrellm-2.3.2-7.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/gkrellm-2.3.2-7.fc11
gkrellm-2.3.2-7.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
gkrellm-2.3.2-7.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.