Opened 6 years ago

Closed 6 years ago

#6052 closed Bug (invalid)

transmission-gtk segmentation fault

Reported by: jmssil Owned by: jordan
Priority: Normal Milestone: None Set
Component: GTK+ Client Version: 2.84
Severity: Normal Keywords: transmission-gtk segmentation fault
Cc:

Description

I got this error with version 2.82 in Linux Mint. With the help of xn0r in #transmission, and using gdb/valgrind, we found out the bug to probably be cause by this one: https://github.com/miniupnp/miniupnp/commit/3a87aa2f10bd7f1408e1849bdb59c41dd63a9fe9

I tried version 2.84 and valgrind changed the location of the error, which indicates that in this newer version the miniupnp bug above has been solved.

But I still get a segmentation fault either with 2.84 or the svn version. With the svn version, valgrind seems to indicate a first error in libpixman?

(I'll try to attach the config directory later, since I tried to attach it when creating the issue and got an error which made me have to rewrite all this.)

This problem only happens with this config directory. With a clean directory it does not happen.

Please tell me if you need some more info or me to make any tests. Thanks.

Change History (5)

comment:1 Changed 6 years ago by mike.dld

  • Severity changed from Blocker to Normal
  • Version changed from 2.84+ to 2.84

Miniupnp has been updated in 2.83 (r14262). Please attach full backtrace so that we can see where the crash happens.

comment:2 Changed 6 years ago by jmssil

I've tried again and it's not possible to attach a file, I get "Internal Server Error". I can send the config directory by e-mail or so, if useful.

This is the stack trace running in gdb alone:

(gdb) where
#0  0x00007ffff122dc9f in gnutls_x509_crt_import () from /usr/lib/x86_64-linux-gnu/libgnutls.so.26
#1  0x00007ffff6083179 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#2  0x00007ffff6083d2a in ?? () from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#3  0x00007ffff60847f0 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#4  0x00007ffff60480de in ?? () from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#5  0x00007ffff606a7f1 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#6  0x00007ffff606b441 in curl_multi_perform () from /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
#7  0x000000000047e25a in tr_webThreadFunc (vsession=0x798a00) at web.c:484
#8  0x0000000000452ec3 in ThreadFunc (_t=0xadda90) at platform.c:104
#9  0x00007ffff552a182 in start_thread (arg=0x7fffcdc8b700) at pthread_create.c:312
#10 0x00007ffff525747d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

and this is the stack trace running with valgrind:

(gdb) where
#0  0x000000000c833c6c in core_combine_over_u_sse2_mask (w=203, 
    pm=0xffefe6654, ps=0xffefe6324, pd=0x1ed5b3ac)
    at ../../pixman/pixman-sse2.c:584
#1  sse2_combine_over_u (imp=<optimized out>, op=<optimized out>, 
    pd=<optimized out>, ps=<optimized out>, pm=<optimized out>, 
    w=<optimized out>) at ../../pixman/pixman-sse2.c:735
#2  0x000000000c8198ac in general_composite_rect (imp=0x110816f0, 
    info=<optimized out>) at ../../pixman/pixman-general.c:199
#3  0x000000000c7ce841 in pixman_image_composite32 (op=PIXMAN_OP_OVER, 
    src=<optimized out>, mask=<optimized out>, dest=<optimized out>, src_x=31, 
    src_y=17, mask_x=0, mask_y=0, dest_x=26, dest_y=16, width=204, height=1)
    at ../../pixman/pixman.c:707
#4  0x0000000008849c57 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#5  0x000000000888ae24 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#6  0x000000000887dcbc in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#7  0x000000000887e69b in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#8  0x000000000887f597 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#9  0x000000000883db27 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#10 0x000000000884de5f in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#11 0x0000000008882504 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#12 0x000000000884558c in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#13 0x000000000883f0d9 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
#14 0x00000000088389f5 in cairo_fill ()
#15 0x000000001f1daf75 in ?? () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#16 0x000000001f1d7a12 in ?? () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#17 0x000000001f1cf503 in ?? () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#18 0x000000001f1cf583 in ?? () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#19 0x000000001f1cf503 in ?? () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#20 0x000000001f1cf903 in ?? () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#21 0x000000001f1cf503 in ?? () from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#22 0x000000001f1dbac3 in rsvg_handle_render_cairo_sub ()
   from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#23 0x000000001f1dbef4 in rsvg_handle_get_pixbuf_sub ()
   from /usr/lib/x86_64-linux-gnu/librsvg-2.so.2
#24 0x000000001efafe46 in ?? ()
   from /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so
#25 0x0000000005a021fb in gdk_pixbuf_loader_close ()
   from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#26 0x00000000059fe435 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#27 0x0000000005a0007d in gdk_pixbuf_new_from_stream_at_scale ()
   from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0
#28 0x00000000051ae6ab in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#29 0x00000000051b1e4a in gtk_icon_info_load_icon ()
#30 0x00000000051b20dc in gtk_icon_theme_load_icon_for_scale ()
   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#31 0x000000000531bf4b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#32 0x000000000531cbfd in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#33 0x000000000532434c in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#34 0x00000000050fae3b in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#35 0x00000000061e63b8 in g_closure_invoke ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#36 0x00000000061f7557 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#37 0x00000000061ffa29 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#38 0x00000000061ffce2 in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#39 0x0000000005313926 in gtk_widget_realize ()
   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#40 0x000000000531f528 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#41 0x00000000061e63b8 in g_closure_invoke ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#42 0x00000000061f7557 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#43 0x00000000061ffa29 in g_signal_emit_valist ()
#44 0x00000000061ffce2 in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#45 0x000000000531100c in gtk_widget_show ()
   from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#46 0x0000000000435b28 in app_setup (wind=0x1e143470, cbdata=0xffefffb80)
    at main.c:740
#47 0x00000000004351c9 in on_startup (application=0x11140b40, 
    user_data=0xffefffb80) at main.c:545
#48 0x00000000061e63b8 in g_closure_invoke ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#49 0x00000000061f7d3d in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#50 0x00000000061ffa29 in g_signal_emit_valist ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#51 0x00000000061ffce2 in g_signal_emit ()
   from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#52 0x0000000005f0506a in g_application_register ()
   from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#53 0x0000000005f057e7 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#54 0x0000000005f05acb in g_application_run ()
   from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#55 0x000000000043592f in main (argc=1, argv=0xffefffe78) at main.c:690

comment:4 Changed 6 years ago by jmssil

Thanks. What does it mean in terms of bug correction? Who should correct it?

Is there a workaround?

Also, when there are memory errors, shouldn't valgrind stack trace be considered instead of gdb's? Because since gdb is not able to detect memory errors, it will stop when the *effects* of the error are noticed, not when the errors were introduced. Is this right?

comment:5 Changed 6 years ago by mike.dld

  • Resolution set to invalid
  • Status changed from new to closed

My understanding is that the problem isn't in Transmission, but in curl or gnutls. The solution for you would be downgrading or upgrading one of those packages.

As for your other question, valgrind and gdb are serving different (even if intersecting) purposes. If we're talking about errors as severe as bad/null pointer dereference though (which is the case here), the callstack from both tools will probably be the same.

Note: See TracTickets for help on using tickets.