Bug 675824 – Rhythmbox segfaults when trying to update podcasts

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 675824 - Rhythmbox segfaults when trying to update podcasts


Summary:	Rhythmbox segfaults when trying to update podcasts


Status:	RESOLVED FIXED

Product:	totem-pl-parser
Classification:	Core
Component:	General
Version:	3.4.x
Hardware:	Other Linux

Importance:	Normal major
Target Milestone:	---
Assigned To:	totem-pl-parser-maint
QA Contact:	totem-pl-parser-maint

URL:
Whiteboard:

Duplicates:	681713 690694 (view as bug list)
Depends on:
Blocks:

Reported:	2012-05-10 16:36 UTC by Benjamin
Modified:	2012-12-29 04:43 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Benjamin 2012-05-10 16:36:44 UTC

Rhythmbox segfaults when trying to update podcasts. This happened since fedora 16. Backtrace follows:


(gdb) thread apply all bt
[New Thread 0xa3d06b40 (LWP 3204)]

+ Trace 230209

Thread 22 (Thread 0xa3d06b40 (LWP 3204))

#0 clone
at ../sysdeps/unix/sysv/linux/i386/clone.S line 111
#1 ??
from /lib/libpython2.7.so.1.0
#2 ??

Thread 20 (Thread 0xa4d08b40 (LWP 3202))

#0 _int_malloc
at malloc.c line 3425
#1 __GI___libc_malloc
at malloc.c line 2928
#2 ??
from /lib/liblua-5.1.so
#3 ??
from /lib/liblua-5.1.so
#4 ??
from /lib/liblua-5.1.so
#5 lua_pushcclosure
from /lib/liblua-5.1.so
#6 luaL_openlib
from /lib/liblua-5.1.so
#7 luaL_register
from /lib/liblua-5.1.so
#8 luaopen_os
from /lib/liblua-5.1.so
#9 ??
from /lib/liblua-5.1.so
#10 ??
from /lib/liblua-5.1.so
#11 lua_call
from /lib/liblua-5.1.so
#12 luaL_openlibs
from /lib/liblua-5.1.so
#13 init_lua
from /lib/libquvi.so.7
#14 quvi_init
from /lib/libquvi.so.7
#15 totem_pl_parser_is_videosite
at totem-pl-parser-videosite.c line 46
#16 totem_pl_parser_parse_internal
at totem-pl-parser.c line 1798
#17 totem_pl_parser_parse_with_base
at totem-pl-parser.c line 2088
#18 totem_pl_parser_parse
at totem-pl-parser.c line 2170
#19 rb_podcast_parse_load_feed
at rb-podcast-parse.c line 218
#20 rb_podcast_manager_thread_parse_feed
at rb-podcast-manager.c line 1147
#21 g_thread_proxy
at gthread.c line 801
#22 start_thread
at pthread_create.c line 309
#23 clone
at ../sysdeps/unix/sysv/linux/i386/clone.S line 133

Thread 19 (Thread 0xa5509b40 (LWP 3201))

#0 __pthread_mutex_destroy
at pthread_mutex_destroy.c line 32
#1 g_mutex_impl_free
at gthread-posix.c line 112
#2 g_mutex_clear
at gthread-posix.c line 187
#3 totem_pl_parser_finalize
at totem-pl-parser.c line 1290
#4 g_object_unref
at gobject.c line 3018
#5 rb_podcast_parse_load_feed
at rb-podcast-parse.c line 224
#6 rb_podcast_manager_thread_parse_feed
at rb-podcast-manager.c line 1147
#7 g_thread_proxy
at gthread.c line 801
#8 start_thread
at pthread_create.c line 309
#9 clone
at ../sysdeps/unix/sysv/linux/i386/clone.S line 133

Thread 1 (Thread 0xb7fca8c0 (LWP 3180))

#0 clone
at ../sysdeps/unix/sysv/linux/i386/clone.S line 111
#1 ??
#2 ??
#3 ??

Comment 1 Jonathan Matthew 2012-05-10 22:10:14 UTC

Looks like some kind of memory corruption somewhere.  Can you try running rhythmbox in valgrind?  http://live.gnome.org/Valgrind has some helpful information.

Comment 2 Benjamin 2012-05-11 13:45:06 UTC

See http://dl.dropbox.com/u/1213532/vgdump (8MB)

I used:
G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-modules valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump rhythmbox

Is it right that valgrind doesn't open rhythmbox when running this? I'm new to it.

Comment 3 Jonathan Matthew 2012-05-13 11:11:51 UTC

This is just a crash in totem-pl-parser.

Comment 4 Jonathan Matthew 2012-05-13 11:15:13 UTC

This crashes with totem-pl-parser git master:

#include <totem-pl-parser.h>

int main(int argc, char **argv)
{
	TotemPlParser *parser;

	g_type_init ();	

	parser = totem_pl_parser_new ();
	g_object_unref (parser);

	return 0;
}


because it calls g_mutex_clear on a mutex that has never been used, which for the POSIX implementation amounts to pthread_mutex_destroy (NULL); free (NULL);

Adding a single call to totem_pl_parser_add_ignored_scheme (or add_ignored_mimetype) makes it initialize the mutex, so it doesn't crash.

Comment 5 Philip Withnall 2012-05-13 12:04:22 UTC

Fixed on master. Thanks for investigating it.

commit 46c74f20e2dc26e54d881f04116fcbd1703ee030
Author: Philip Withnall <philip@tecnocode.co.uk>
Date:   Sun May 13 13:02:54 2012 +0100

    lib: Fix initialisation of ignore_mutex
    
    Closes: https://bugzilla.gnome.org/show_bug.cgi?id=675824

 plparse/totem-pl-parser.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Comment 6 Benjamin 2012-05-17 11:12:07 UTC

Will this be fixed in FC17 final?

Comment 7 Philip Withnall 2012-05-19 14:59:22 UTC

The fix has been released in version 3.4.2 of totem-pl-parser. I believe Fedora 17 will ship GNOME 3.4, so yes, this should be in F17 final as far as I know.

Comment 8 Jonathan Matthew 2012-08-13 10:36:46 UTC

*** Bug 681713 has been marked as a duplicate of this bug. ***

Comment 9 Jonathan Matthew 2012-12-29 04:43:49 UTC

*** Bug 690694 has been marked as a duplicate of this bug. ***