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
<rdar://problem/7296920>
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.
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
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"
Does this fail for anyone using Safari with a nightly WebKit build?
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.
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.
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.
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.
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
Someone set this is as a regression, what version did this work in?
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!
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>.
New url: http://peacekeeper.futuremark.com/
I tried reproducing this with latest WebKitGTK+ and could not, I believe it has been fixed.