Gaim quits after unsuccessful file transfer

Bug #15375 reported by Kylepenner
10
Affects Status Importance Assigned to Milestone
gaim (Ubuntu)
Fix Released
Medium
Ubuntu Desktop Bugs

Bug Description

If Gaim takes too long to try and transfer a file, and the transfer is aborted,
it suddenly quits. I don't know what else to say...this is on Hoary, Gaim
v1.1.4, and it's happened several times.

https://sourceforge.net/tracker/index.php?func=detail&aid=1195300&group_id=235&atid=100235: https://sourceforge.net/tracker/index.php?func=detail&aid=1195300&group_id=235&atid=100235

Revision history for this message
Luke Schierer (lschiere) wrote :

msn transfer? or others as well?

can you get a backtrace as per gaim.sf.net/gdb.php ? (see the notes about
getting a useful backtrace on debian, they will apply to ubuntu as well)

Revision history for this message
Kylepenner (kylepenner) wrote :

(In reply to comment #1)
> msn transfer? or others as well?
>
> can you get a backtrace as per gaim.sf.net/gdb.php ? (see the notes about
> getting a useful backtrace on debian, they will apply to ubuntu as well)

This is an AIM transfer.
This time, the crash was a little different, but here's the output:
kyle@rees:~$ gdb gaim
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library
"/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) handle SIGPIPE nostop
Signal Stop Print Pass to program Description
SIGPIPE No Yes Yes Broken pipe
(gdb) run
Starting program: /usr/bin/gaim
[Thread debugging using libthread_db enabled]
[New Thread -1218106688 (LWP 10465)]
[New Thread -1234682960 (LWP 10480)]
art_render_invoke: no image source given
[New Thread -1243833424 (LWP 10481)]
[New Thread -1244099664 (LWP 10482)]
[New Thread -1244365904 (LWP 10483)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1218106688 (LWP 10465)]
0xb7a906a9 in g_markup_escape_text () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0 0xb7a906a9 in g_markup_escape_text () from /usr/lib/libglib-2.0.so.0
#1 0x0807dac9 in gaim_xfer_cancel_remote (xfer=0x83938a8) at ft.c:984
#2 0xb6b3ad3c in oscar_sendfile_connected (data=0x83938a8, source=-1,
    condition=GAIM_INPUT_READ) at oscar.c:3132
#3 0x0808c9d5 in try_connect (phb=0x8410c48) at proxy.c:1685
#4 0x0808a6e4 in no_one_calls (data=0x8410c48, source=33, cond=3)
    at proxy.c:805
#5 0x080d4076 in gaim_gtk_io_invoke (source=0x83ce2d0, condition=24,
    data=0x839ca58) at gtkeventloop.c:61
#6 0xb7aadeb1 in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#7 0xb7a8ad0f in g_main_depth () from /usr/lib/libglib-2.0.so.0
#8 0xb7a8bcb5 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#9 0xb7a8bfd7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#10 0xb7a8c51e in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#11 0xb7d4810f in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x081048fe in main (argc=1, argv=0xbffff964) at main.c:961

Is this what you're looking for?

Revision history for this message
Sebastien Bacher (seb128) wrote :

thanks for the backtrace. I'm not sure if there is a bug upstream about this,
not easy to search for a backtrace with the sourceforge bug tracker. I've opened
a bug about this:
https://sourceforge.net/tracker/index.php?func=detail&aid=1195300&group_id=235&atid=100235

Revision history for this message
Phil Bull (philbull) wrote :

Upstream report fix released in gaim 2.0.0beta1.

Our latest version is 1:1.5.0+1.5.1cvs20051015-1ubuntu6

Changed in gaim:
status: Unconfirmed → Fix Committed
Revision history for this message
Sebastien Bacher (seb128) wrote :

fixed to edgy

Changed in gaim:
assignee: seb128 → desktop-bugs
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.