Bug 1029394

*** 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. ***