I think licq crashed while displaying the passphrase dialog for GPG. I was away for half an hour, and then licq had crashed.
Originally reported 2008-04-15 as trac ticket #1626.
Commented 2008-04-22:
Yup, this is definitely reproduceable. This always happens when the passphrase dialog is not answered quickly enough. I guess it happens when some other event is coming in or something. Friend of mine has the same problem with a slightly older licq svn version.
Commented 2008-04-22:
First, you and your contact have to use the GPG functionality of Licq. Also you will most probably be using the qt-pinentry passphrase dialog of GPG.
Now, the first time you get a GPG message, qt-pinentry will pop up, called by libgpgme, and ask for the passphrase. Parts of Licq will be blocked during this call.
If you do not answer fast enough -- Segfault! After the first passphrase entry my GPG agent caches the passphrase for quite a while, so that the problem does not show again.
I think that's as detailed as I can get...
Commented 2009-03-15:
r6645 implements a partial workaround. The user mutex will be released before calling the GPG decryption function. This allows other threads to continue working.
However, the socket monitor thread will still be blocked causing incoming events to be queued until the GPG passphrase input is done. This will probably cause timeouts and other problems so I'm leaving this ticket open until a proper fix is implemented.
I think licq crashed while displaying the passphrase dialog for GPG. I was away for half an hour, and then licq had crashed.
Originally reported 2008-04-15 as trac ticket #1626.
Commented 2008-04-22: Yup, this is definitely reproduceable. This always happens when the passphrase dialog is not answered quickly enough. I guess it happens when some other event is coming in or something. Friend of mine has the same problem with a slightly older licq svn version.
Commented 2008-04-22: First, you and your contact have to use the GPG functionality of Licq. Also you will most probably be using the qt-pinentry passphrase dialog of GPG. Now, the first time you get a GPG message, qt-pinentry will pop up, called by libgpgme, and ask for the passphrase. Parts of Licq will be blocked during this call. If you do not answer fast enough -- Segfault! After the first passphrase entry my GPG agent caches the passphrase for quite a while, so that the problem does not show again. I think that's as detailed as I can get...
Commented 2009-03-15: r6645 implements a partial workaround. The user mutex will be released before calling the GPG decryption function. This allows other threads to continue working. However, the socket monitor thread will still be blocked causing incoming events to be queued until the GPG passphrase input is done. This will probably cause timeouts and other problems so I'm leaving this ticket open until a proper fix is implemented.