GNOME Bugzilla – Bug 779180
Frequent crashes on a specific website and Valgrind: Invalid read of size 8 in ephy_embed_destroy_top_widgets()
Last modified: 2017-03-04 19:30:04 UTC
Debian unstable, Epiphany 3.22.6, WebKitGTK+ 2.14.5 Two issues, that might (or might not) have the same root cause: 1. I go to https://www.terveystalo.com/ click English and seach for a doctor - epiphany crashes sometimes when clicking on "English" and sometimes a few clicks later with different symptoms like e.g.: - segmentation fault - free(): invalid pointer: 0x00007f124017e1e0 - malloc.c:3084: __libc_realloc: Assertion `!newp || chunk_is_mmapped (mem2chunk (newp)) || ar_ptr == arena_for_chunk (mem2chunk (newp))' failed. Reverting commit b2c1bd64 (web-view: Fix memory leaks when web view is closed before info bar) fixes the crashes (but not the valgrind-reported "Invalid read of size 8" from 2.). 2. Run epiphany under valgrind, go to https://www.terveystalo.com/ and click on one of the Suomi/Svenska/English language buttons on the upper left: ==2611== Thread 1: ==2611== Invalid read of size 8 ==2611== at 0x169B8B: ephy_embed_destroy_top_widgets (ephy-embed.c:226) ==2611== by 0x169B8B: load_changed_cb (ephy-embed.c:284) ==2611== by 0xBB09F74: g_closure_invoke (gclosure.c:804) ==2611== by 0xBB1BF81: signal_emit_unlocked_R (gsignal.c:3635) ==2611== by 0xBB24BDB: g_signal_emit_valist (gsignal.c:3391) ==2611== by 0xBB24FBE: g_signal_emit (gsignal.c:3447) ==2611== by 0x6006A20: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) ==2611== by 0x62606B0: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) ==2611== by 0x625CFD4: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) ==2611== by 0x5F71788: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) ==2611== by 0x6025171: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) ==2611== by 0x5F6D8E5: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) ==2611== by 0x5F6E577: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) ==2611== Address 0x3119e688 is 8 bytes inside a block of size 16 free'd ==2611== at 0x4C2CDDB: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2611== by 0xBDB64EC: g_slist_remove (gslist.c:414) ==2611== by 0x16950F: remove_from_destroy_list_cb (ephy-embed.c:236) ==2611== by 0xBB09F74: g_closure_invoke (gclosure.c:804) ==2611== by 0xBB1BF81: signal_emit_unlocked_R (gsignal.c:3635) ==2611== by 0xBB24BDB: g_signal_emit_valist (gsignal.c:3391) ==2611== by 0xBB24FBE: g_signal_emit (gsignal.c:3447) ==2611== by 0xA2B5557: gtk_widget_dispose (gtkwidget.c:12063) ==2611== by 0xBB10647: g_object_run_dispose (gobject.c:1084) ==2611== by 0x169B8A: ephy_embed_destroy_top_widgets (ephy-embed.c:227) ==2611== by 0x169B8A: load_changed_cb (ephy-embed.c:284) ==2611== by 0xBB09F74: g_closure_invoke (gclosure.c:804) ==2611== by 0xBB1BF81: signal_emit_unlocked_R (gsignal.c:3635) ==2611== Block was alloc'd at ==2611== at 0x4C2BBAF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2611== by 0xBD9CE08: g_malloc (gmem.c:94) ==2611== by 0xBDB5342: g_slice_alloc (gslice.c:1025) ==2611== by 0xBDB63B5: g_slist_prepend (gslist.c:254) ==2611== by 0x16A908: ephy_embed_add_top_widget (ephy-embed.c:851) ==2611== by 0x173337: permission_request_cb (ephy-web-view.c:1395) ==2611== by 0x62480E3: webkit_marshal_BOOLEAN__OBJECT (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) ==2611== by 0xBB09F74: g_closure_invoke (gclosure.c:804) ==2611== by 0xBB1BF81: signal_emit_unlocked_R (gsignal.c:3635) ==2611== by 0xBB2467E: g_signal_emit_valist (gsignal.c:3401) ==2611== by 0xBB24FBE: g_signal_emit (gsignal.c:3447) ==2611== by 0x61E1E38: ??? (in /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37.14.12) Michael Catanzaro had a test patch that fixed this valgrind warning (but not the crashes from 1.).
OK, so it really is two separate bugs. But they're closely-related.
(In reply to Adrian Bunk from comment #0) > Michael Catanzaro had a test patch that fixed this valgrind warning (but not > the crashes from 1.). I'm still able to see the warnings even with my patch, so it must be wrong.
*** Bug 779402 has been marked as a duplicate of this bug. ***
*** Bug 779401 has been marked as a duplicate of this bug. ***
Created attachment 346973 [details] BT from gdb for epiphany Reproduced with Ephy 3.22.6 and WebKit 2.15.91. I go to http://www.myregus.com and, by clicking "Deny" on the request to know the location, most of the times is enough to have a crash. Some other times, I need first to log in that page. You can see that the BT is very similar to the one for bug 779401.
Created attachment 346974 [details] BT from gdb for epiphany, with G_SLICE=debug-blocks Following very similar steps than for the just attached BT, but with G_SLICE=debug-blocks
(In reply to Andres Gomez from comment #6) > Created attachment 346974 [details] > BT from gdb for epiphany, with G_SLICE=debug-blocks > > Following very similar steps than for the just attached BT, but with > G_SLICE=debug-blocks This BT is very similar to the one in bug 779402 so I do believe, bug 779401 is really a DUPLICATE of these 2.
Created attachment 346976 [details] Valgrind log following the already explained steps. After clicking the "Deny" button, valgrind crashes and generates a core file. That file weighs 1.8G and I cannot get any useful information out of that.
Created attachment 346977 [details] BT from memcheck-amd64-linux This is the BT from the core generated by the command line: /usr/bin/valgrind.bin --leak-check=full --track-origins=yes -v --log-file=valgrind-ephy-%p.txt ./epiphany-install/bin/epiphany --incognito-mode --profile /home/tanty/.config/epiphany
Created attachment 347119 [details] [review] Allocate PermissionRequestData with g_slice_new since it's freed with g_slice_free I can't reproduce the issue, but it could be caused because the PermissionRequestData struct is allocated with g_new and freed with g_slice_free.
Oh no, oops. :S Accepted, but please don't close the bug as that's definitely not the only thing that's wrong here. Adrian, does that fix your crash?
(In reply to Michael Catanzaro from comment #11) > Adrian, does that fix your crash? Thanks, that fixes the crashes I saw.
Comment on attachment 347119 [details] [review] Allocate PermissionRequestData with g_slice_new since it's freed with g_slice_free Attachment 347119 [details] pushed as 6b6c674 - Allocate PermissionRequestData with g_slice_new since it's freed with g_slice_free
The following fix has been pushed: 9f4e3e6 embed: avoid memory corruption when clearing top widgets
Created attachment 347232 [details] [review] embed: avoid memory corruption when clearing top widgets Don't call remove_from_destroy_list_cb, which modifies the destroy list, when already iterating through the list.