Description of problem: Since version 3.1.15 (and 3.1.16 in testing) sound-juicer segfaults. Version-Release number of selected component (if applicable): gnutls-3.1.15-1.fc19.x86_64 gnutls-3.1.16-1.fc19.x86_64 How reproducible: Always Steps to Reproduce: 1. insert a CD 2. sound-juicer 3. Actual results: segfault Expected results: no segfault Additional info: No segfault with 3.1.11 (gdb) bt #0 0x00007fffeb000e20 in __gmpz_clear () from /lib64/libgmp.so.10 #1 0x00007fffef3c89eb in mp_clear_multi () from /lib64/libgnutls.so.28 #2 0x00007fffef3c9f2a in ecc_del_point () from /lib64/libgnutls.so.28 #3 0x00007fffef3c95da in ecc_wmnaf_cache_free () from /lib64/libgnutls.so.28 #4 0x00007fffef337861 in gnutls_global_deinit () from /lib64/libgnutls.so.28 #5 0x00007ffff7b8de0b in MusicBrainz5::CHTTPFetch::Fetch (this=this@entry=0x7fffb79b8e50, URL="/ws/2/discid/nniFYgqeO6ULqX1_SdEYnY6tkEc-", Request="GET") at /usr/src/debug/libmusicbrainz-5.0.1/src/HTTPFetch.cc:232 #6 0x00007ffff7bab342 in MusicBrainz5::CQuery::PerformQuery (this=this@entry=0x7fffb0001330, Query="/ws/2/discid/nniFYgqeO6ULqX1_SdEYnY6tkEc-") at /usr/src/debug/libmusicbrainz-5.0.1/src/Query.cc:145 #7 0x00007ffff7babc8c in MusicBrainz5::CQuery::Query (this=this@entry=0x7fffb0001330, Entity="discid", ID="nniFYgqeO6ULqX1_SdEYnY6tkEc-", Python Exception <type 'exceptions.IndexError'> list index out of range: Resource="", Params=std::map with 0 elements) at /usr/src/debug/libmusicbrainz-5.0.1/src/Query.cc:253 #8 0x00007ffff7bac0ee in MusicBrainz5::CQuery::LookupDiscID (this=this@entry=0x7fffb0001330, DiscID="nniFYgqeO6ULqX1_SdEYnY6tkEc-") at /usr/src/debug/libmusicbrainz-5.0.1/src/Query.cc:263 #9 0x00007ffff7b99c2d in mb5_query_lookup_discid (Query=0x7fffb0001330, DiscID=DiscID@entry=0x7fffb0001ad8 "nniFYgqeO6ULqX1_SdEYnY6tkEc-") at /usr/src/debug/libmusicbrainz-5.0.1/src/mb5_c.cc:684 #10 0x000000000041f71a in mb5_list_albums (metadata=<optimized out>, url=0x8fbea0, error=0x7fffb79b9bf8) at sj-metadata-musicbrainz5.c:517 #11 0x000000000041e803 in lookup_cd (mdg=0x8fbe80) at sj-metadata-getter.c:196 #12 0x00007ffff5790185 in g_thread_proxy (data=0xba7450) at gthread.c:798 #13 0x00007ffff550fc53 in start_thread (arg=0x7fffb79ba700) at pthread_create.c:308 #14 0x00007ffff523cdbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
*** Bug 1028730 has been marked as a duplicate of this bug. ***
gnutls_global_deinit() should not be called in individual threads.
Moving to neon as #5 0x00007ffff7b8de0b in MusicBrainz5::CHTTPFetch::Fetch (this=this@entry=0x7fffb79b8e50, URL="/ws/2/discid/nniFYgqeO6ULqX1_SdEYnY6tkEc-", Request="GET") at /usr/src/debug/libmusicbrainz-5.0.1/src/HTTPFetch.cc:232 is ne_sock_exit(), not a direct call to gnutls_global_deinit().
Then ne_sock_exit() probably should not be called in individual threads.
Good point supported by the documentation http://www.webdav.org/neon/doc/html/refsockinit.html "Once all use of neon is complete, ne_sock_exit can be called to perform de-initialization of socket or SSL libraries, if necessary."
I'm getting this too. I'm a kernel developer, and have the sound juicer compiled in debug mode from latest git tree, so let me know if I can do anything to assist.
*** Bug 1031285 has been marked as a duplicate of this bug. ***
Another user experienced a similar problem: opened sound-juicer, put in cd; crashed while scanning the cd. reporter: libreport-2.1.10 backtrace_rating: 4 cmdline: sound-juicer crash_function: __gmpz_clear executable: /usr/bin/sound-juicer kernel: 3.12.5-302.fc20.x86_64 package: sound-juicer-3.5.0-5.fc20 reason: sound-juicer killed by SIGSEGV runlevel: N 5 type: CCpp uid: 1000
Created attachment 841612 [details] File: backtrace
Although Thomas is right that gnutls_global_init/deinit are not threadsafe and thus calling them from threads is somewhat dangerous, this is not the cause of the crash seen here. It would still be desirable to make the code properly thread-safe to prevent any other possible bugs here. Also the gnutls global init is actually pretty darn CPU intensive so having a single CD lookup call gnutls_global_init+deinit as many as 15 times is actually wasting significant wall-clock time which is likely noticeable to the user. This crash issue though is simply a flaw in gnutls_global_deinit not cleaning up all its global state, resulting in use-after-free in subsequent calls to gnutls_global_deinit. See bug 1046672 for a demo program that reproduces the crash using gnutls alone and no threads at all. Also see patch attached to that bug to fix the problem.
*** Bug 1032857 has been marked as a duplicate of this bug. ***
(In reply to Daniel Berrange from comment #10) > > This crash issue though is simply a flaw in gnutls_global_deinit not > cleaning up all its global state, resulting in use-after-free in subsequent > calls to gnutls_global_deinit. Ah thanks a lot for the investigation and the fix! > Also the > gnutls global init is actually pretty darn CPU intensive so having a single > CD lookup call gnutls_global_init+deinit as many as 15 times is actually > wasting significant wall-clock time which is likely noticeable to the user. I've filed http://tickets.musicbrainz.org/browse/LMB-38 upstream. I'll close this bug as a duplicate of the gnutls one. *** This bug has been marked as a duplicate of bug 1046672 ***
*** Bug 1047088 has been marked as a duplicate of this bug. ***