Bug 515471 (webkitBrowser1Crash) - [Webkit1] test_BrowserSuite.testBrowser1() consistently crashes on RHEL6 / webkit1
Summary: [Webkit1] test_BrowserSuite.testBrowser1() consistently crashes on RHEL6 / we...
Status: RESOLVED FIXED
Alias: webkitBrowser1Crash
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 4.7   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 4.8   Edit
Assignee: Leo Ufimtsev CLA
QA Contact:
URL:
Whiteboard: Pending.dependents
Keywords:
Depends on: browser_tests
Blocks: webkit1JvmCrashes
  Show dependency tree
 
Reported: 2017-04-19 13:29 EDT by Martin Oberhuber CLA
Modified: 2017-08-02 12:52 EDT (History)
1 user (show)

See Also:


Attachments
hs_err_pid7100.log (89.95 KB, text/x-log)
2017-04-19 13:33 EDT, Martin Oberhuber CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2017-04-19 13:29:35 EDT
Build ID: SWT master on 20170418

I've built my own SWT.gtk.linux.x86_64 on RHEL6, and I'm trying to run the test suite. I've run build.xml:build_library from the fragment, and skipped building XULRunner since I use Webkit. Window manager is metacity. After installing and starting cups to work around bug 215234, it now consistently crashes here - A browser window showing Google homepage comes up quickly, but then it crashes:

Test_BrowserSuite#setUp(): testBrowser1

(SWT:7100): GLib-GObject-WARNING **: g_object_set_valist: object class `WebKitWebSettings' has no property named `enable-webgl'

(SWT:7100): GLib-CRITICAL **: g_hash_table_lookup_extended: assertion `hash_table != NULL' failed
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000003bbbb2856a, pid=7100, tid=0x00007f33b5070700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.121-b13 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libc.so.6+0x12856a]
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /folk/wb-fast/mober/home/git/eclipse.platform.swt/tests/org.eclipse.swt.tests/hs_err_pid7100.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Comment 1 Martin Oberhuber CLA 2017-04-19 13:33:17 EDT
Created attachment 267857 [details]
hs_err_pid7100.log

bash-4.1$ rpm -qa | grep webkitgtk
webkitgtk-devel-1.4.3-9.el6_6.x86_64
webkitgtk-1.4.3-9.el6_6.x86_64
Comment 2 Martin Oberhuber CLA 2017-04-19 13:34:25 EDT
It looks like this test is deliberately disabled on eclipse.org Hudson ... now that I can 100% reproduce it, maybe we can get a step further on this? Or should I disable it as well?
Comment 3 Martin Oberhuber CLA 2017-04-19 14:42:16 EDT
For the records, testBrowser2() also crashed, but installing freeglut resolved it:
yum install freeglut
Comment 4 Leo Ufimtsev CLA 2017-04-19 15:32:28 EDT
Webkit1 is somewhat notorious for crashing in a gtk_context_iteration(..)

See parent I liked to:
Bug 509587 - [Browser][Webkit 1] JVM crashes tracking bug

The long term solution is to switch over to using webkit2 because there are architecture issues inside webkit1 leading to those crashes that are fixed in Webkit2.

Can you use webkit2 on your system?
pgk:
webkitgtk4.x86_64 

export SWT_WEBKIT2=1
eclipse

* newest Eclipse needs to be used from nighties:
http://download.eclipse.org/eclipse/downloads/
Comment 5 Martin Oberhuber CLA 2017-04-20 03:01:42 EDT
(In reply to Leo Ufimtsev from comment #4)

Thanks for the explanation, Leo.

I'm not aware of any way updating RHEL6 to webkit2, therefore I think I am stuck with webkit1; that said, I think I can live with these known instabilities, and I'm OK closing this bug as WONTFIX.

I have filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=515486 instead, requesting a more consistent way disabling unstable tests, such that adopters won't run into this again.
Comment 6 Martin Oberhuber CLA 2017-04-22 05:35:37 EDT
So with my fix from https://bugs.eclipse.org/bugs/show_bug.cgi?id=515155 , *all* tests are green now on my RHEL6 / webkit1.4.3 box, except testBrowser1 crashes. I notice that a browser window does come up, fails to show www.google.com due to a proxy/timeout problem, and then it crashes.

Since you are not happy with my proposal from bug 515486, I suggest disabling testBrowser1 for webkit1 globally, would you agree?
Comment 7 Leo Ufimtsev CLA 2017-04-24 09:40:31 EDT
(In reply to Martin Oberhuber from comment #6)
> So with my fix from https://bugs.eclipse.org/bugs/show_bug.cgi?id=515155 ,
> *all* tests are green now on my RHEL6 / webkit1.4.3 box, except testBrowser1
> crashes. I notice that a browser window does come up, fails to show
> www.google.com due to a proxy/timeout problem, and then it crashes.
> 
> Since you are not happy with my proposal from bug 515486, I suggest
> disabling testBrowser1 for webkit1 globally, would you agree?

I think the problem may be the implementation of the test case itself. It has quirky wait logic in runLoopTimer(..). (Thread sleeps, async display redraws..

I.e, the tests in Test_BrowserSuite are very old and they're testing multiple things at once instead of having 1 test case testing 1 thing. This makes it hard to debug them. So in general I've been working on breaking all tests up in Test_BrowserSuite and implementing lots of little once into: Test_org_eclipse_swt_browser_Browser.

I think the solution would be for me to strip out the test case altogether and add what ever is not tested yet to Test_org_eclipse_swt_browser_Browser() as individual test cases.

I will try to do this sometime this week.
Comment 8 Leo Ufimtsev CLA 2017-05-25 17:00:36 EDT
The old Browser* tests should ideally all be replaced. I'll work on that in the parent: bug browser_tests

Once that's solved, this bug should be resolved as well.
Comment 9 Leo Ufimtsev CLA 2017-08-02 12:52:31 EDT
Browser1 test was removed and replaced by tests that have a different wait logic, which should prevent crashes.