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 779401 - libglib2.0-0: Epiphany SIGSEVs in slab_allocator_free_chunk at ././glib/gslice.c:1347
libglib2.0-0: Epiphany SIGSEVs in slab_allocator_free_chunk at ././glib/gslic...
Status: RESOLVED DUPLICATE of bug 779180
Product: epiphany
Classification: Core
Component: General
3.22.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-03-01 08:06 UTC by Andres Gomez
Modified: 2017-03-01 14:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Andres Gomez 2017-03-01 08:06:27 UTC 
I'm using WebKitGtk+ with my own JHBuild setting:
https://github.com/tanty/jhbuild-epiphany/tree/master

Epiphany 3.22.6 and WebKit 2.15.90.

However, the rest of the dependencies, but mesa and its dependencies, and evince, are all provided from Debian Testing.

The compilation was done with CMake args:

'-DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DENABLE_MINIBROWSER=ON -DCMAKE_C_FLAGS_RELEASE="-O0 -g -DNDEBUG  -DG_DISABLE_CAST_CHECKS" -DCMAKE_CXX_FLAGS_RELEASE="-O0 -g -DNDEBUG -DG_DISABLE_CAST_CHECKS"'

After visiting several pages, eventually, the Epiphany hits a SIGSEV.

This bug is not reproducible in a predictable way.
Comment 1 Andres Gomez 2017-03-01 08:06:46 UTC 
Details and BTs at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856383
Comment 2 Andres Gomez 2017-03-01 08:12:04 UTC 
Epiphany's compilation was done with autotools args:

'--disable-Werror --enable-debug --disable-static --disable-gtk-doc --disable-introspection'
Comment 3 Michael Catanzaro 2017-03-01 13:50:06 UTC 
Looks like memory corruption. Unfortunately Jason's comment in the downstream bug is correct:

"The problem with memory corruption bugs is that the stack trace you've
provided only shows where the memory corruption was detected.  It
doesn't show where the memory corruption actually happened."

So we need a valgrind log for this. Does it happen often for you? Are you able to catch it in valgrind? If not, we're out of luck unfortunately. :(

That said, I know of one other memory corruption bug right now, bug #779180. It could possibly be the same one.
Comment 4 Michael Catanzaro 2017-03-01 14:00:27 UTC 
So based on your comment in bug #779402, where you say you think that bug is a duplicate of this one, I'm going to tentatively mark this as a duplicate of bug #779180. Please reopen if this it turns out to not be a duplicate after all.

*** This bug has been marked as a duplicate of bug 779180 ***