Bug 30312 – [Gtk] REGRESSION: WebKit fails part 2 of PeaceKeeper benchmark

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Mat]

this has been happening for some time now:

when launching the futuremark peacekeeper it "fails" at part 2 of 6 (#2 social networking) during benchmarking manifesting itself by not continuing (it doesn't show sorting and/or searching of fictitious members)

description:

"Social networking # 2/6
Social networking sites use JavaScript to provide navigation, forms and other features. These tests measure typical webpage functions, such as loading, sorting and searching for data."

this affects

*) webkit nightly-builds (tested in conjunction with midori)

*) webkit nightly-based gtk-webkit snapshots (tested with midori and/or epiphany 2.28)

*) also google chromium

I can confirm this on Chromium	4.0.221.5 (Developer Build 27967)

WebKit	532.2
V8	1.3.13.5
User Agent	Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.2 (KHTML, like Gecko) Chrome/4.0.221.5 Safari/532.2

[Mark Rowe (bdash)]

<rdar://problem/7296920>

[hubert star]

same here.

I can confirm this on Webkit-gtk trunk version(20091121).

Chromium, midori and other browers test failed.

I'm using git master src, make and install on by gentoo linux.

sorry for my bad english.

[Alexey Proskuryakov]

Is this still an issue? I cannot reproduce with r52487.

Still an issue here with this release:

Chromium	4.0.266.0 (Developer Build 33992)
WebKit	        532.6
V8	        2.0.3.1
User Agent	Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.6 (KHTML, like Gecko) Chrome/4.0.266.0 Safari/532.6

[Mat]

I can still reproduce:

strangely there's a distinction for me:

while using the 64bit binary snapshot provided by the www-client/chromium-bin-9999 ebuild it passes and this can also be seen visually how it "sorts" through the records

the version number of chrome (binary / pre-compiled) passing is 4.0.282.0 (64bit)


on the other hand it fails with the custom-built (locally compiled) chromium-version - which is a very close version - btw:

4.0.283.0 (35287)


it also fails with webkit-gtk 1.1.17 and latest midori snapshot


from my experience it's not dependent on compiler-flags (e.g. -O2 or using -O2 and more additional aggressive flags makes no difference):

Portage 2.2_rc61 (default/linux/amd64/10.0, gcc-4.4.2, glibc-2.11-r0, 2.6.32-zen4_bfs x86_64)
=================================================================
System uname: Linux-2.6.32-zen4_bfs-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-gentoo-2.0.1
Timestamp of tree: Wed, 30 Dec 2009 16:45:01 +0000
app-shells/bash:     3.2_p48-r1
dev-java/java-config: 1.3.7-r1, 2.1.10
dev-lang/python:     2.5.4-r3, 2.6.4, 3.1.1-r1
dev-python/pycrypto: 2.1.0_beta1
dev-util/cmake:      2.8.0
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.0
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.13, 2.65
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:  2.20, 2.20.51.0.1, 2.20.51.0.2, 2.20.51.0.3, 2.20.51.0.4
sys-devel/gcc-config: 1.5
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.30-r1
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer --param max-gcse-passes=8 -fno-strict-overflow -fno-delete-null-pointer-checks -fno-tree-vrp -freorder-blocks-and-partition -mno-align-stringops -minline-stringops-dynamically -fno-ident -mno-push-args"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer --param max-gcse-passes=8 -fno-strict-overflow -fno-delete-null-pointer-checks -fno-tree-vrp -freorder-blocks-and-partition -mno-align-stringops -minline-stringops-dynamically -fno-ident -mno-push-args -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--hash-style=both -Wl,--sort-common -Wl,--enable-new-dtags -Wl,--relax -Wl,--as-needed"

[Alexey Proskuryakov]

Does this fail for anyone using Safari with a nightly WebKit build?

[Jay]

On Windows XP SP3 using Webkit nightlies (on top of Safari 4.0.4), the last "good" Webkit nightly build is r49078.  All subsequent builds up to and including r52746 exhibit the bug.

The build immediately after r49078 is r49284.  That one crashes immediately on launch.

The build right after that is r49383.  That one works for most sites, but refuses to start the Peacekeeper benchmark.  Compare this page using r49078 and r49383:

http://service.futuremark.com/peacekeeper/run.action

Interestingly, it loads just fine under the latest version of Chrome (4.0.266.0).

So it looks like whatever is causing this was introduced between Oct-5-2009 (r49078) and Oct-10-2009 (r49383).  Which makes sense given this ticket was opened on Oct-12-2009.

[Alexey Proskuryakov]

I do see the problem with Windows nightly. The regression is between r49336 and r49367, which leaves me with only one candidate to blame: <http://trac.webkit.org/changeset/49365> "pronounce the death of AllInOneFile.cpp". Weird.

I'm not 100% sure if this is the same as the issue reported on Linux though - with Windows Safari nightlies, PeaceKeeper doesn't even run step 1.

[Alexey Proskuryakov]

The Windows issue is a purely JavaScriptCore one, so it cannot possibly affect Chrome. I don't think it can affect Gtk either - the problem is with JavaScriptCore DLL exports, while Gtk has a monolithic WebKit IIRC.

We have another bug with the same underlying cause for Windows Safari nightly builds: bug 33057. I'll make a fix there, and keep the bug open for Gtk/Chromium investigation.

[David Levin]

No need to keep it open for chromium as there is http://code.google.com/p/chromium/issues/detail?id=29542 specifically for chromium, so this bug is open for gtk alone.  I changed the summary/title to reflect this.

[Mat]

it's still happening with the webkit-gtk 1.1.21 snapshot in combination with

*) midori 0.2.2

*) epiphany 2.29.90


I couldn't test with chromium yet since futuremark's homepage right now takes ages to load

last time I ran it with chromium (a few weeks ago) it worked fine with it

[Gustavo Noronha (kov)]

Someone set this is as a regression, what version did this work in?

[f.zweig]

See comment #8: r49078 on Windows XP is the last one. Since it does work in Chromium, but not in Midori or Epiphany, it seems to be a problem in JavaScriptCore (Google uses its own JavaScript engine, V8: http://code.google.com/p/v8/). This is the reason it works in Chromium/Chrome, but not in pure WebKit browsers.

Could someone please reassign this to the JavaScriptCore component? Thank you!

[Alexey Proskuryakov]

Can anyone still reproduce this with Windows Safari nightlies? As mentioned in comment 10, I fixed it in bug 33057, <http://trac.webkit.org/changeset/52956>.

[Emilio Pozuelo Monfort]

New url: http://peacekeeper.futuremark.com/

[Gustavo Noronha (kov)]

I tried reproducing this with latest WebKitGTK+ and could not, I believe it has been fixed.