Hide Forgot
abrt version: 1.1.14 architecture: x86_64 Attached file: backtrace cmdline: /usr/bin/pidgin --session 10a5fe32451a7f8c82129527879826077700000015080036 --display :0.0 component: pidgin crash_function: sighandler executable: /usr/bin/pidgin kernel: 2.6.35.6-48.fc14.x86_64 package: pidgin-2.7.9-1.fc14 rating: 3 reason: Process /usr/bin/pidgin was killed by signal 6 (SIGABRT) release: Fedora release 14 (Laughlin) time: 1295469860 uid: 500 How to reproduce ----- 1.Don't know exactly, I was using Firefox when the crash occured. 2. 3.
Created attachment 474354 [details] File: backtrace
Package: pidgin-2.7.9-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Leave it overnight 2. 3.
Package: pidgin-2.7.9-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- I detached a conversation tab (there were two open at the time) and started typing. Protocol used in both tabs was msn, while the other tab was OTR-encrypted.
Package: pidgin-2.7.9-1.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Shutdown 2. crash 3.
Package: pidgin-2.7.9-1.fc14 Architecture: i686 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. shutdown GNOME 2. 3.
Package: pidgin-2.7.9-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. When sending or recieving a message to/from one particular MSN contact, Pidgin crashes. 2. 3. Comment ----- I can't tell why it is doing this, the only thing I can think of is that this person has Japanese characters in his MSN friendly name.
Package: pidgin-2.7.9-1.fc14 Architecture: x86_64 OS Release: Fedora release 14 (Laughlin) How to reproduce ----- 1. Configure an MSN account 2. Open conversation window with a specific buddy 3. Send a message 4. when the response arrive, it crashes.
Stu -- it doesn't look like it's crashing in pidgin-sipe, or am I looking in the wrong place?
(In reply to comment #8) > Stu -- it doesn't look like it's crashing in pidgin-sipe, or am I looking in > the wrong place? I assigned it to pidgin-sipe because from the backtrace it's crashing in http_conn_error() http-conn.c:251 in frame #5, and that appears to be part of pidgin-sipe. I didn't look closely, but I assume it is pidgin-sipe that sets up the callback too.
Stefan, can you take a look?
I'm a little bit mystified. None of the reporters mentions setting up a "Office Communicator" account, which is the only way how pidgin-sipe gets involved. @reporters: if you *do* have set up a "Office Communicator" account, could you please attach the output of "pidgin --debug"? Looking at the code this could only happen if our user data gets corrupted by libpurple. 1. http_conn.c/http_conn_setup( http_conn [!= NULL, initialized], ....) { sipe_connect_setup setup = { ... http_conn, [sipe_connect_setup.user_data] ... http_conn_error [sipe_connect_setup.error] }; ... [http_conn->callback is NULL or valid function pointer] return(sipe_backend_transport_connect(sipe_public, &setup)); 2. purple-transport.c/sipe_backend_transport_connect(..., setup) { struct sipe_transport_purple *transport = g_new0(struct sipe_transport_purple, 1); ... transport->public.user_data = setup->user_data; ... transport->error = setup->error; ... if (purple_ssl_connect(account, ... transport_ssl_connect_failure, transport) == NULL) { [user_data] ... [http_conn->callback is set up after this returns to NULL or valid function pointer] (back to Pidgin/libpurple code after this, libpurple sets up SSL connection, our code gets called later when the SSL handshake fails) 3. purple-transport.c/transport_ssl_connect_failure(..., data) { struct sipe_transport_purple *transport = data; /* If the connection is already disconnected then we don't need to do anything else */ if (!PURPLE_CONNECTION_IS_VALID(transport->gc)) return; transport->socket = -1; transport->gsc = NULL; transport->error(SIPE_TRANSPORT_CONNECTION, purple_ssl_strerror(error)); 4. http_conn.c/http_conn_error(struct sipe_transport_connection *conn, const gchar *msg) { HttpConn *http_conn = HTTP_CONN; [transport->public.user_data] if (http_conn->callback) { Line 251: (*http_conn->callback)(HTTP_CONN_ERROR, NULL, NULL, http_conn, http_conn->data); } http_conn_close(http_conn, msg); } So, in the error case transport, transport->error & http_conn seem to be correct. Furthermore http_conn->callback seems to be != NULL, but an illegal value although our code only sets up valid function pointers????
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping