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 636052 - SIGSEGV loading planet gnome
SIGSEGV loading planet gnome
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: Misc
2.29.x
Other Linux
: Normal critical
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2010-11-29 11:07 UTC by Xan Lopez
Modified: 2010-11-29 15:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gnutls: Fix a crash caused by loading and unloading the module (2.85 KB, patch)
2010-11-29 15:52 UTC, Dan Winship
committed Details | Review

Description Xan Lopez 2010-11-29 11:07:00 UTC
webkit and libsoup master:


Program received signal SIGSEGV, Segmentation fault.
0x036dbbf4 in gvdb_table_bloom_filter (file=0x311def4, hash_value=1072) at ../gvdb/gvdb-reader.c:209
209	  return (file->bloom_words[word] & mask) == mask;
(gdb) bt
  • #0 gvdb_table_bloom_filter
    at ../gvdb/gvdb-reader.c line 209
  • #1 _gcry_ath_mutex_lock
    at ath.c line 186
  • #2 lock_pool
    at random-csprng.c line 298
  • #3 _gcry_rngcsprng_fast_poll
    at random-csprng.c line 1255
  • #4 _gcry_fast_random_poll
    at random.c line 259
  • #5 md_open
    at md.c line 499
  • #6 _gcry_md_open
    at md.c line 530
  • #7 gcry_md_open
    at visibility.c line 755
  • #8 wrap_gcry_hash_init
    at mac-libgcrypt.c line 108
  • #9 _gnutls_hash_init
    at gnutls_hash_int.c line 85
  • #10 _gnutls_handshake_hash_init
    at gnutls_handshake.c line 2382
  • #11 gnutls_handshake
    at gnutls_handshake.c line 2498
  • #12 do_handshake
    at soup-gnutls.c line 151
  • #13 soup_gnutls_write
  • #14 g_io_channel_write_chars
  • #15 soup_socket_write
    at soup-socket.c line 1501
  • #16 write_data
  • #17 io_write
    at soup-message-io.c line 610
  • #18 soup_message_io_client
    at soup-message-io.c line 1095
  • #19 soup_message_send_request
    at soup-message-client-io.c line 144
  • #20 soup_connection_send_request
    at soup-connection.c line 704
  • #21 soup_session_send_queue_item
    at soup-session.c line 1197
  • #22 process_queue_item
    at soup-session-async.c line 366
  • #23 run_queue
    at soup-session-async.c line 418
  • #24 got_connection
    at soup-session-async.c line 324
  • #25 socket_connect_result
    at soup-connection.c line 457
  • #26 async_connected
    at soup-socket.c line 681
  • #27 g_simple_async_result_complete
    at gsimpleasyncresult.c line 748
  • #28 g_socket_client_async_connect_complete
    at gsocketclient.c line 1102
  • #29 g_socket_client_tls_handshake
    at gsocketclient.c line 1173
  • #30 g_socket_client_proxy_connect
    at gsocketclient.c line 1231
  • #31 g_socket_client_socket_connected
    at gsocketclient.c line 1295
  • #32 g_socket_client_socket_callback
    at gsocketclient.c line 1333
  • #33 socket_source_dispatch
    at gsocket.c line 2471
  • #34 g_main_dispatch
    at gmain.c line 2436
  • #35 g_main_context_dispatch
    at gmain.c line 3009
  • #36 g_main_context_iterate
    at gmain.c line 3087
  • #37 g_main_loop_run
    at gmain.c line 3295
  • #38 gtk_main
    at gtkmain.c line 1297
  • #39 main
    at ../../src/ephy-main.c line 732

Comment 1 Dan Winship 2010-11-29 14:16:18 UTC
and glib/glib-networking master?

i'm seeing sporadic gcrypt crashes in libsoup when using tls-enabled glib. not reproducible under valgrind of course :-/
Comment 2 Dan Winship 2010-11-29 15:52:44 UTC
I was misremembering: it wasn't that I couldn't reproduce it under
valgrind, it was that I couldn't get it to make any sense. Your
backtrace was senseless in a more sensible way though.

The following fix has been pushed:
187a710 gnutls: Fix a crash caused by loading and unloading the module
Comment 3 Dan Winship 2010-11-29 15:52:48 UTC
Created attachment 175477 [details] [review]
gnutls: Fix a crash caused by loading and unloading the module

If gio-querymodules isn't run to update the cache then gio will need
to load and unload the module at startup time. This was causing
crashes in apps that used gcrypt elsewhere, because gcrypt was being
initialized to use our module's mutex functions, which then no longer
existed after unloading.

Fix this in two different ways: first, force the module to remain
resident after gtls_gnutls_init() has been called, and second, don't
call gtls_gnutls_init() if we're just being called from
g_io_modules_scan_all_in_directory().