Bug 670987

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