| Summary: | [GTK] Intel HD Graphics 3000 GPU hangs with WebKitGTK+ 2.1[4|6].x | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adrian Perez <aperez> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | agomez, bugs-noreply, clopez, kdwkleung, magomez, mcatanzaro, tonton.78340, XCH |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 245783 | ||
|
Description
Adrian Perez
2017-03-31 10:18:43 PDT
Correction: The session is (In reply to Adrian Perez from comment #0) > Using Epiphany to browse the web causes a GPU hang which brings down > the entire Wayland session, and the user is sent back to GDM. [...] Correction: The whole session is *not* brought down and the user sent back to GDM. What happens is that the system hangs, and eventually overheats. One more interesting data point: [20:19] <lashdu> The issue can also happen just after I close the browser window. This may be related (perhaps even the same issue) than bug 161862 One bit more:
<lashdu> aperezdc: Hi! I did a test with WEBKIT_FORCE_COMPOSITING_MODE
enabled. Unfortunately it crashes, too.
I guess that would be with WEBKIT_FORCE_COMPOSITING_MODE=1. Maybe it would
be interesting to know what happens with the variable set to zero.
I can reproduce this with: Epiphany 3.22.6 and WebKit 2.15.91. I'm using WebKitGtk+ with my own JHBuild setting: https://github.com/tanty/jhbuild-epiphany/tree/master 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 whole desktop freezes. The kernel doesn't react to the magic keys so, probably, it also hits a kernel panic. After reboot, I can see this: # cat /var/log/kern.log ... Apr 7 12:54:21 pomeron kernel: [ 4792.247402] [drm] GPU HANG: ecode 6:0:0x85fffffc, in ositorWorkQueue [3920], reason: Hang on render ring, action: reset Apr 7 12:54:21 pomeron kernel: [ 4792.247406] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. Apr 7 12:54:21 pomeron kernel: [ 4792.247406] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel Apr 7 12:54:21 pomeron kernel: [ 4792.247407] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. Apr 7 12:54:21 pomeron kernel: [ 4792.247407] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. Apr 7 12:54:21 pomeron kernel: [ 4792.247408] [drm] GPU crash dump saved to /sys/class/drm/card0/error Apr 7 12:54:21 pomeron kernel: [ 4792.247450] drm/i915: Resetting chip after gpu hang ... FTR, I think the change on my late behavior that is causing for me to hit this problem very often is that, now, I'm using an intensive use of pages at: https://travis-ci.org/ Like: https://travis-ci.org/Igalia/release-mesa/jobs/219618519 FTR, this could be the same than bug 167688. Check: https://bugs.webkit.org/show_bug.cgi?id=167688#c4 (In reply to Andres Gomez Garcia from comment #7) > FTR, this could be the same than bug 167688. > > Check: > https://bugs.webkit.org/show_bug.cgi?id=167688#c4 In any case, this one fixed in my system: https://bugs.freedesktop.org/show_bug.cgi?id=84252 (In reply to Andres Gomez Garcia from comment #7) > FTR, this could be the same than bug 167688. > > Check: > https://bugs.webkit.org/show_bug.cgi?id=167688#c4 And I'm using DRI3, so it seems something different. (In reply to Adrian Perez from comment #4) > One bit more: > > <lashdu> aperezdc: Hi! I did a test with WEBKIT_FORCE_COMPOSITING_MODE > enabled. Unfortunately it crashes, too. > > I guess that would be with WEBKIT_FORCE_COMPOSITING_MODE=1. Maybe it would > be interesting to know what happens with the variable set to zero. It wouldn't do anything, you want WEBKIT_DISABLE_COMPOSITING_MODE=1. Hi! I am the original reporter. - The fix provided for https://bugs.freedesktop.org/show_bug.cgi?id=84252 doesn't work for me as I have XCB 1.12 (build 22 May 2016) and Epiphany still makes the system irresposive and overheats it. - The issue is easily reproducible on heavy pages I presume having lots of scripts running. My banking web app doesn't contain any HTML5 videos or images, yet it causes the issue with 50% chance. - The issue recently is present on Epiphany 3.22.6, WebKit 2.16.1, xf86-video-vesa 2.3.4 or xf86-video-intel 2.99.917+772+gc72bb27a. Let me know here if you like any other details needed to find out the cause. (In reply to drtan from comment #11) > Hi! I am the original reporter. > > - The fix provided for https://bugs.freedesktop.org/show_bug.cgi?id=84252 > doesn't work for me as I have XCB 1.12 (build 22 May 2016) and Epiphany > still makes the system irresposive and overheats it. > - The issue is easily reproducible on heavy pages I presume having lots of > scripts running. My banking web app doesn't contain any HTML5 videos or > images, yet it causes the issue with 50% chance. > - The issue recently is present on Epiphany 3.22.6, WebKit 2.16.1, > xf86-video-vesa 2.3.4 or xf86-video-intel 2.99.917+772+gc72bb27a. > > Let me know here if you like any other details needed to find out the cause. Can you try to launch epiphany from a terminal after exporting this environment variable: export WEBKIT_DISABLE_COMPOSITING_MODE=1 Does it make any difference? (In reply to Carlos Alberto Lopez Perez from comment #12) > (In reply to drtan from comment #11) > > Hi! I am the original reporter. > > > > - The fix provided for https://bugs.freedesktop.org/show_bug.cgi?id=84252 > > doesn't work for me as I have XCB 1.12 (build 22 May 2016) and Epiphany > > still makes the system irresposive and overheats it. > > - The issue is easily reproducible on heavy pages I presume having lots of > > scripts running. My banking web app doesn't contain any HTML5 videos or > > images, yet it causes the issue with 50% chance. > > - The issue recently is present on Epiphany 3.22.6, WebKit 2.16.1, > > xf86-video-vesa 2.3.4 or xf86-video-intel 2.99.917+772+gc72bb27a. > > > > Let me know here if you like any other details needed to find out the cause. > > > Can you try to launch epiphany from a terminal after exporting this > environment variable: > > export WEBKIT_DISABLE_COMPOSITING_MODE=1 > > Does it make any difference? Currently I am testing WebKit 2.16.2 as it became the latest available version. If the problem persists I will check influence of WEBKIT_DISABLE_COMPOSITING_MODE. The issue is present with WebKit 2.16.2. I am testing WEBKIT_DISABLE_COMPOSITING_MODE now. The issue seems gone with WEBKIT_DISABLE_COMPOSITING_MODE set. Yet I can notice that a tab freezes when video playback is paused. Either as a result of pressing a pause button or changing the video played. Apart from that the browser is responding, so it is possible for example to open a new tab and play another video there. I'll be testing more to be sure that GPU won't overheat in some other scenario of use. Unfortunately even WEBKIT_DISABLE_COMPOSITING_MODE set cannot prevent Epiphany from overheating the system. This time I achieved the result by long (over an hour) playback of an HTML5 video (YouTube). However it seems that with WEBKIT_DISABLE_COMPOSITING_MODE set it is more difficult to hang the system. (In reply to drtan from comment #16) > Unfortunately even WEBKIT_DISABLE_COMPOSITING_MODE set cannot prevent > Epiphany from overheating the system. This time I achieved the result by > long (over an hour) playback of an HTML5 video (YouTube). However it seems > that with WEBKIT_DISABLE_COMPOSITING_MODE set it is more difficult to hang > the system. If Epiphany uses too much CPU, then that is a bug we can try to fix. But your system overheating is a hardware problem (a poor cooling system). Nothing we can do about it. (In reply to Carlos Alberto Lopez Perez from comment #17) > (In reply to drtan from comment #16) > > Unfortunately even WEBKIT_DISABLE_COMPOSITING_MODE set cannot prevent > > Epiphany from overheating the system. This time I achieved the result by > > long (over an hour) playback of an HTML5 video (YouTube). However it seems > > that with WEBKIT_DISABLE_COMPOSITING_MODE set it is more difficult to hang > > the system. > > If Epiphany uses too much CPU, then that is a bug we can try to fix. > > But your system overheating is a hardware problem (a poor cooling system). > Nothing we can do about it. Is there anything I can provide for you to differentiate between the two? I personally doubt it is a hardware problem although hardware might contribute to the problem. It is because I can still normally browse the web with other browsers, like for example Iceweasel and I used to be able to browse with Epiphany (some year ago for sure). Let me describe the exact user perception of the problem on the most frequent case: playing an HTML5 video. A user launches the browser and navigates to YouTube. There he plays an hour long video. At random moment (it might be in the middle of the video or more closer to the end) the mouse pointer is starting to work harder. After a while the video freezes and audio repeats in a short loop (2-3 seconds). Afterwards the whole graphical environment freezes. Then the fans begin to work louder. Eventually the system shuts down. Presumably due to being overheated by too much load on processing. Hi! On Epiphany 3.24 (WebKitGTK+ 2.16.3) now I get GNOME session crash (returning to the login screen of GDM) when loading a heavy website (try https://wp.pl). The following is the dump. Process 5131 (epiphany) of user 1000 dumped core. Stack trace of thread 5131: #0 0x00007fe0f333e221 n/a (libglib-2.0.so.0) #1 0x00007fe0f3340851 g_log_writer_default (libglib-2.0.so.0) #2 0x00007fe0f333edbc g_log_structured_array (libglib-2.0.so.0) #3 0x00007fe0f333f0b9 g_log_structured (libglib-2.0.so.0) #4 0x00007fe0ef497b07 n/a (libgdk-3.so.0) #5 0x00007fe0f3337e8d g_main_context_prepare (libglib-2.0.so.0) #6 0x00007fe0f33388db n/a (libglib-2.0.so.0) #7 0x00007fe0f3338acc g_main_context_iteration (libglib-2.0.so.0) #8 0x00007fe0f38f3f9d g_application_run (libgio-2.0.so.0) #9 0x0000000000402a31 main (epiphany) #10 0x00007fe0f2f6943a __libc_start_main (libc.so.6) #11 0x0000000000401f0a _start (epiphany) Stack trace of thread 5133: #0 0x00007fe0eb0b439d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fe0e87d8c4c __gthread_cond_wait (libstdc++.so.6) #2 0x00007fe0ee02f91c _ZN7bmalloc9AsyncTaskINS_4HeapEMS1_FvvEE13threadRunLoopEv (libjavascrip #3 0x00007fe0ee02fa69 _ZN7bmalloc9AsyncTaskINS_4HeapEMS1_FvvEE16threadEntryPointEPS4_ (libjav #4 0x00007fe0e87def8f execute_native_thread_routine (libstdc++.so.6) #5 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #6 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5136: #0 0x00007fe0f302c2bd poll (libc.so.6) #1 0x00007fe0f33389b6 n/a (libglib-2.0.so.0) #2 0x00007fe0f3338d42 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fe0f391ff86 n/a (libgio-2.0.so.0) #4 0x00007fe0f3360295 n/a (libglib-2.0.so.0) #5 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #6 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5148: #0 0x00007fe0eb0b4756 pthread_cond_timedwait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fe0ee02664a _ZN3WTF15ThreadCondition9timedWaitERNS_5MutexEd (libjavascriptcoregtk-4 #2 0x00007fe0edfef333 _ZN3WTF10ParkingLot21parkConditionallyImplEPKvRKNS_12ScopedLambdaIFbvEE #3 0x00007fe0edfe0965 _ZN3WTF5sleepEd (libjavascriptcoregtk-4.0.so.18) #4 0x00007fe0efee6fad n/a (libwebkit2gtk-4.0.so.37) #5 0x00007fe0edff2575 n/a (libjavascriptcoregtk-4.0.so.18) #6 0x00007fe0ee025f5a n/a (libjavascriptcoregtk-4.0.so.18) #7 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #8 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5159: #0 0x00007fe0f302c2bd poll (libc.so.6) #1 0x00007fe0f33389b6 n/a (libglib-2.0.so.0) #2 0x00007fe0f3338d42 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fe0ee028c60 _ZN3WTF7RunLoop3runEv (libjavascriptcoregtk-4.0.so.18) #4 0x00007fe0ee027bc3 n/a (libjavascriptcoregtk-4.0.so.18) #5 0x00007fe0edff2575 n/a (libjavascriptcoregtk-4.0.so.18) #6 0x00007fe0ee025f5a n/a (libjavascriptcoregtk-4.0.so.18) #7 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #8 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5145: #0 0x00007fe0f30313b9 syscall (libc.so.6) #1 0x00007fe0f337e32f g_cond_wait (libglib-2.0.so.0) #2 0x00007fe0f330cf8b n/a (libglib-2.0.so.0) #3 0x00007fe0f330d3f7 g_async_queue_pop (libglib-2.0.so.0) #4 0x00007fe0f4d4823f n/a (libephymisc.so) #5 0x00007fe0f3360295 n/a (libglib-2.0.so.0) #6 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #7 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5160: #0 0x00007fe0f302c2bd poll (libc.so.6) #1 0x00007fe0f33389b6 n/a (libglib-2.0.so.0) #2 0x00007fe0f3338d42 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fe0ee028c60 _ZN3WTF7RunLoop3runEv (libjavascriptcoregtk-4.0.so.18) #4 0x00007fe0ee027bc3 n/a (libjavascriptcoregtk-4.0.so.18) #5 0x00007fe0edff2575 n/a (libjavascriptcoregtk-4.0.so.18) #6 0x00007fe0ee025f5a n/a (libjavascriptcoregtk-4.0.so.18) #7 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #8 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5134: #0 0x00007fe0f302c2bd poll (libc.so.6) #1 0x00007fe0f33389b6 n/a (libglib-2.0.so.0) #2 0x00007fe0f3338acc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fe0de3fa55d n/a (libdconfsettings.so) #4 0x00007fe0f3360295 n/a (libglib-2.0.so.0) #5 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #6 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5135: #0 0x00007fe0f302c2bd poll (libc.so.6) #1 0x00007fe0f33389b6 n/a (libglib-2.0.so.0) #2 0x00007fe0f3338acc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fe0f3338b11 n/a (libglib-2.0.so.0) #4 0x00007fe0f3360295 n/a (libglib-2.0.so.0) #5 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #6 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5139: #0 0x00007fe0f302c2bd poll (libc.so.6) #1 0x00007fe0f33389b6 n/a (libglib-2.0.so.0) #2 0x00007fe0f3338d42 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fe0ee028c60 _ZN3WTF7RunLoop3runEv (libjavascriptcoregtk-4.0.so.18) #4 0x00007fe0ee027bc3 n/a (libjavascriptcoregtk-4.0.so.18) #5 0x00007fe0edff2575 n/a (libjavascriptcoregtk-4.0.so.18) #6 0x00007fe0ee025f5a n/a (libjavascriptcoregtk-4.0.so.18) #7 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #8 0x00007fe0f303625f __clone (libc.so.6) Stack trace of thread 5144: #0 0x00007fe0eb0b439d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fe0ee02667b _ZN3WTF15ThreadCondition9timedWaitERNS_5MutexEd (libjavascriptcoregtk-4 #2 0x00007fe0edfef333 _ZN3WTF10ParkingLot21parkConditionallyImplEPKvRKNS_12ScopedLambdaIFbvEE #3 0x00007fe0f084bd06 n/a (libwebkit2gtk-4.0.so.37) #4 0x00007fe0f084cfa8 n/a (libwebkit2gtk-4.0.so.37) #5 0x00007fe0edff2575 n/a (libjavascriptcoregtk-4.0.so.18) #6 0x00007fe0ee025f5a n/a (libjavascriptcoregtk-4.0.so.18) #7 0x00007fe0eb0ae297 start_thread (libpthread.so.0) #8 0x00007fe0f303625f __clone (libc.so.6) cze 09 20:36:33 sharviza systemd-coredump[5219]: Process 705 (gnome-shell) of user 1000 dumped core. Stack trace of thread 705: #0 0x00007fbeb383d670 raise (libc.so.6) #1 0x00007fbeb383ed00 abort (libc.so.6) #2 0x00007fbeb3e3e465 g_assertion_message (libglib-2.0.so.0) #3 0x00007fbeb3e3e4fa g_assertion_message_expr (libglib-2.0.so.0) #4 0x00007fbeb5d07c54 n/a (libgjs.so.0) #5 0x00007fbeaebf4f6d n/a (libmozjs-38.so) #6 0x00007fbeaebd15cd n/a (libmozjs-38.so) #7 0x00007fbeaef28e90 n/a (libmozjs-38.so) #8 0x00007fbeaef54ede n/a (libmozjs-38.so) #9 0x00007fbeaef558c0 n/a (libmozjs-38.so) #10 0x00007fbeaef55b0d n/a (libmozjs-38.so) #11 0x00007fbeaef55ed4 n/a (libmozjs-38.so) #12 0x00007fbeb5d20f49 gjs_schedule_gc_if_needed (libgjs.so.0) #13 0x00007fbeb5d20fb4 gjs_call_function_value (libgjs.so.0) #14 0x00007fbeb5cfc0b5 gjs_closure_invoke (libgjs.so.0) #15 0x00007fbeb5d13e1c n/a (libgjs.so.0) #16 0x00007fbeb40f0f75 g_closure_invoke (libgobject-2.0.so.0) #17 0x00007fbeb410c7b2 n/a (libgobject-2.0.so.0) #18 0x00007fbeb3e180e3 n/a (libglib-2.0.so.0) #19 0x00007fbeb3e1766a g_main_context_dispatch (libglib-2.0.so.0) #20 0x00007fbeb3e17a20 n/a (libglib-2.0.so.0) #21 0x00007fbeb3e17d42 g_main_loop_run (libglib-2.0.so.0) #22 0x00007fbeb55d9fdc meta_run (libmutter-0.so.0) #23 0x0000000000401ff7 main (gnome-shell) #24 0x00007fbeb382a43a __libc_start_main (libc.so.6) #25 0x000000000040212a n/a (gnome-shell) Stack trace of thread 756: #0 0x00007fbeb3bbc39d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fbea662b500 PR_WaitCondVar (libnspr4.so) #2 0x00007fbeaec18811 n/a (libmozjs-38.so) #3 0x00007fbea6630d8c n/a (libnspr4.so) #4 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #5 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 709: #0 0x00007fbeb38ed2bd poll (libc.so.6) #1 0x00007fbeb3e179b6 n/a (libglib-2.0.so.0) #2 0x00007fbeb3e17acc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fbe8f76255d n/a (libdconfsettings.so) #4 0x00007fbeb3e3f295 n/a (libglib-2.0.so.0) #5 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #6 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 757: #0 0x00007fbeb3bbc39d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fbea662b500 PR_WaitCondVar (libnspr4.so) #2 0x00007fbeaec18811 n/a (libmozjs-38.so) #3 0x00007fbea6630d8c n/a (libnspr4.so) #4 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #5 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 707: #0 0x00007fbeb38ed2bd poll (libc.so.6) #1 0x00007fbeb3e179b6 n/a (libglib-2.0.so.0) #2 0x00007fbeb3e17d42 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fbeb43fef86 n/a (libgio-2.0.so.0) #4 0x00007fbeb3e3f295 n/a (libglib-2.0.so.0) #5 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #6 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 752: #0 0x00007fbeb3bbc39d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fbea662b500 PR_WaitCondVar (libnspr4.so) #2 0x00007fbeaec18811 n/a (libmozjs-38.so) #3 0x00007fbea6630d8c n/a (libnspr4.so) #4 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #5 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 706: #0 0x00007fbeb38ed2bd poll (libc.so.6) #1 0x00007fbeb3e179b6 n/a (libglib-2.0.so.0) #2 0x00007fbeb3e17acc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fbeb3e17b11 n/a (libglib-2.0.so.0) #4 0x00007fbeb3e3f295 n/a (libglib-2.0.so.0) #5 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #6 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 751: #0 0x00007fbeb3bbc39d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fbea662b500 PR_WaitCondVar (libnspr4.so) #2 0x00007fbeaec18811 n/a (libmozjs-38.so) #3 0x00007fbea6630d8c n/a (libnspr4.so) #4 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #5 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 755: #0 0x00007fbeb3bbc39d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fbea662b500 PR_WaitCondVar (libnspr4.so) #2 0x00007fbeaec18811 n/a (libmozjs-38.so) #3 0x00007fbea6630d8c n/a (libnspr4.so) #4 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #5 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 750: #0 0x00007fbeb3bbc39d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fbea662b500 PR_WaitCondVar (libnspr4.so) #2 0x00007fbeaec18811 n/a (libmozjs-38.so) #3 0x00007fbea6630d8c n/a (libnspr4.so) #4 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #5 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 753: #0 0x00007fbeb3bbc39d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fbea662b500 PR_WaitCondVar (libnspr4.so) #2 0x00007fbeaec18811 n/a (libmozjs-38.so) #3 0x00007fbea6630d8c n/a (libnspr4.so) #4 0x00007fbeb3bb6297 start_thread (libpthread.so.0) #5 0x00007fbeb38f725f __clone (libc.so.6) Stack trace of thread 754: #0 0x00007fbeb3bbc39d pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00007fbea662b500 PR_WaitCondVar (libnspr4.so) #2 0x00007fbeaec18811 n/a (libmozjs-38.so) #3 0x00007fbea6630d8c n/a (libnspr4.so) #4 0x00007fbeb3bb6297 start_thread (libpthread.so.0) (In reply to drtan from comment #19) > Hi! > > On Epiphany 3.24 (WebKitGTK+ 2.16.3) now I get GNOME session crash > (returning to the login screen of GDM) when loading a heavy website (try > https://wp.pl). The following is the dump. > > Process 5131 (epiphany) of user 1000 dumped core. [...] > cze 09 20:36:33 sharviza systemd-coredump[5219]: Process 705 (gnome-shell) > of user 1000 dumped core. That backtrace is not very helpful as it misses most of the symbols. However I see two things: * Seems you got two programs crashing in the same momemnt (epiphany and gnome-shell). * GNOME shells looks like it crashed when it was trying to run garbage collection or something like that (gjs_schedule_gc_if_needed) * Not sure where Epiphany/WebKitGTK+ crashed, but there is at least one thread calling into bmalloc (the WebKitGTK+/JSC memory allocator). It seems to me that is likely that you are running into not enough RAM related problems. How much amount of RAM do you have? Have you checked that you are not running into an out of memory situation? If that happens you should see message on the kernel log indicating that such thing happened. You can query the kernel log with the command dmesg, try to grep it (after the crash) for something related to not enough memory like: dmesg | grep -i "out of memory" If that is not the case, then please try to get another backtrace with symbols enabled (install your distro dbgsym packages for webkitgtk). I have 4 GB of RAM in the system. I can't see any trace of memory related messages. I'll try to obtain more useful crash dump. I was able to compile with debug symbols, but since then I haven't seen any issues. Now I am running WebKit 2.16.5 and Epiphany 3.24.2. Although heavy pages don't cause the issue, the system sometimes freezes for a while to become responsive right after. Some pages end not rendered with full page error that says that the page couldn't be viewed. These are from The Independent or Guardian which also seem heavy sometimes. Better results might also be a result of AC adapter replacement which happened in the same time. All in all Epiphany serves me better, but still fails to be responsive when loading heavy page if it loads them at all. *** Bug 183565 has been marked as a duplicate of this bug. *** *** Bug 183564 has been marked as a duplicate of this bug. *** Unable to reproduce in Gnome Web 44.2/ WebKitGTK 2.40.1. Perhaps fixed already? |