[webkit-dev] Optimize Property Access failed
Hi
I enable ENABLE_JIT_OPTIMIZE_PROPERTY_ACCESS feature and find that it will
crash when go back the home page after run follow test case, I think it is
caused by the optimize propery access, so anyone know that it is caused by the
arch related code or jit Infrastructure code? and if i disable
ENABLE_JIT_OPTIMIZE_PROPERTY_ACCESS feature, it will run correctly.
Any help explaining this would be much appreciated!
test case:
var Origin = new Object();
function Init() {
Origin.V = [150]
}
for ( var i = 20; i = 160; i *= 2 ) {
//Init(i);
}
Init();
Init();
Init();
Origin = null;
Callstack:
JAVASCRIPTCORE!const JSC::JSArray::`vftable' + 2 bytes
JAVASCRIPTCORE!JSC::Heap::sweep() line 1104 + 14 bytes
JAVASCRIPTCORE!JSC::Heap::collectAllGarbage() line 1306
WEBKIT!WebCore::collect(void * 0x) line 47
WEBKIT!WebCore::GCController::gcTimerFired(WebCore::TimerWebCore::GCController
* 0x06a905a0 {m_object=??? m_function=??? }) line 70
WEBKIT!WebCore::TimerWebCore::PageCache::fired() line 98 + 20 bytes
WEBKIT!WebCore::ThreadTimers::sharedTimerFiredInternal() line 115
WEBKIT!WebCore::ThreadTimers::sharedTimerFired() line 91
--
BGs/Felix Shi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Optimize Property Access failed
When i try to access https://bugs.webkit.org/show_bug.cgi?id=41482, it show me follow information, so if I want to check some bug, it need send an email for request to grant the permissions? You are not authorized to access bug #41482. -- BGs/Felix Shi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Not authorized to access Bugzillia
When I try to access https://bugs.webkit.org/show_bug.cgi?id=41482, it show me follow information, so if I want to check some bug, it need send an email for request to grant the permissions? You are not authorized to access bug #41482. -- BGs/Felix Shi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Optimize Property Access failed
Please ask these questions on webkit-help. FWIW, not all bugs require authentication to view. On Wed, Aug 8, 2012 at 1:30 AM, talking1...@gmail.com wrote: When i try to access https://bugs.webkit.org/show_bug.cgi?id=41482, it show me follow information, so if I want to check some bug, it need send an email for request to grant the permissions? *You are not authorized to access bug #41482.* -- ** BGs/Felix Shi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Not authorized to access Bugzillia
This is a security bug. Only some people can access those, typically the security team members at least. Philippe On Wed, 2012-08-08 at 16:32 +0800, talking1...@gmail.com wrote: When I try to access https://bugs.webkit.org/show_bug.cgi?id=41482, it show me follow information, so if I want to check some bug, it need send an email for request to grant the permissions? You are not authorized to access bug #41482. -- BGs/Felix Shi ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Not authorized to access Bugzillia
Security bugs are restricted so that security holes aren't made public until they're fixed. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of talking1...@gmail.com [talking1...@gmail.com] Sent: Wednesday, August 08, 2012 4:32 AM To: webkit-dev@lists.webkit.org Subject: [webkit-dev] Not authorized to access Bugzillia When I try to access https://bugs.webkit.org/show_bug.cgi?id=41482, it show me follow information, so if I want to check some bug, it need send an email for request to grant the permissions? You are not authorized to access bug #41482. -- BGs/Felix Shi - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Add support for CSS3 text-decoration* properties
Hi again, Just to inform I've carefully followed the guidelines from Ryosuke as well as other reviewers, and also people from www-style (regarding blink value). The following patches are now pending review: -webkit-text-decoration-line: https://bugs.webkit.org/show_bug.cgi?id=90959 -webkit-text-decoration-style: https://bugs.webkit.org/show_bug.cgi?id=90958 -webkit-text-decoration-color: https://bugs.webkit.org/show_bug.cgi?id=91638 text-decoration (shorthand as specified in CSS3 spec but also fully backwards-compatible with CSS2.1): https://bugs.webkit.org/show_bug.cgi?id=92000 I kindly ask for review and comments :) Best regards, On Fri, Aug 3, 2012 at 2:01 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Aug 2, 2012 at 9:43 PM, Bruno Abinader brunoabina...@gmail.com wrote: On Thu, Aug 2, 2012 at 6:10 PM, Ryosuke Niwa rn...@webkit.org wrote: Does the spec require to return new values in the computed style of text-decoration property without authors specifying new text-decoration properties and values? If not, then using text-decoration property is probably better because it'll only affect those authors who have used new properties and values. - Ryosuke If I got it right you are asking if it is necessary to designate values for all longhand properties from text-decoration. The answer is no, based on what the specification says: This property is a shorthand for setting ‘text-decoration-line’, ‘text-decoration-color’, and ‘text-decoration-style’ in one declaration. Omitted values are set to their initial values. A ‘text-decoration’ declaration that omits both the ‘text-decoration-color’ and ‘text-decoration-style’ values is backwards-compatible with CSS Levels 1 and 2. Speaking about it, I did finished a refactory on the text-decoration property that now becomes a shorthand (thus removing the necessity of having -webkit-text-decoration property), like CSS3 specifies. Though I haven't upstreamed it to Bugzilla yet, it is fully backwards-compatible with previous CSS specifications. I do have, however, a small set of questions to ask before publishing it for review: 1. I had a full layout test run and noticed a few test failures, but not exactly failures. The reason they failed is because the computed style expected something like text-decoration: underline and now it produces text-decoration-line: underline. Is it ok to update the test expectations on these cases? IMO It doesn't makes sense having a shorthand property behaving like a longhand one anymore. We need to be careful here. Computed styles are used in editing and markup generated (including style attribute values) need to be understood properly by old UAs. It's not sufficient that only WebKit with/without your patch can parse it correctly. - Ryosuke -- Bruno de Oliveira Abinader ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
See https://bugs.webkit.org/show_bug.cgi?id=93195. media/W3C/video/networkState/networkState_during_progress.html and media/video-poster-blocked-by-willsendrequest.html are flaky on all platforms because they behave differently if the loaded resource is cached. Every time I've taken a stab at reducing test flakiness, I've come across at least a few tests that pass when run as part of the test suite, but fail when run by themselves (or in parallel) because they accidentally expect an image or something to be in the cache. I think it would make the tests more maintainable if we cleared the cache before each test run. This is *not* before each page load though. So tests that do multiple page loads will still test cross-navigation caching behavior. While it's true that we could one-off fix each of these tests, it's usually very time consuming to figure out that caching is the problem, that's assuming anyone takes the time to look into why the test is flaky in the first place. Any objections? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
That sounds like a great idea to me. I was actually surprised when fischman told me we don't currently do this. - Ryosuke On Wed, Aug 8, 2012 at 10:47 AM, Ojan Vafai o...@chromium.org wrote: See https://bugs.webkit.org/show_bug.cgi?id=93195. media/W3C/video/networkState/networkState_during_progress.html and media/video-poster-blocked-by-willsendrequest.html are flaky on all platforms because they behave differently if the loaded resource is cached. Every time I've taken a stab at reducing test flakiness, I've come across at least a few tests that pass when run as part of the test suite, but fail when run by themselves (or in parallel) because they accidentally expect an image or something to be in the cache. I think it would make the tests more maintainable if we cleared the cache before each test run. This is *not* before each page load though. So tests that do multiple page loads will still test cross-navigation caching behavior. While it's true that we could one-off fix each of these tests, it's usually very time consuming to figure out that caching is the problem, that's assuming anyone takes the time to look into why the test is flaky in the first place. Any objections? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
I can see some downsides to emptying the cache before each test: - we won't be getting any test coverage for cache behavior when it hits non-trivial size; - this may well make tests measurably slower; - this will be yet another cause of subtle difference between platforms, as some will undoubtedly have this unimplemented for a long time. - WBR, Alexey Proskuryakov 08.08.2012, в 10:47, Ojan Vafai написал(а): See https://bugs.webkit.org/show_bug.cgi?id=93195. media/W3C/video/networkState/networkState_during_progress.html and media/video-poster-blocked-by-willsendrequest.html are flaky on all platforms because they behave differently if the loaded resource is cached. Every time I've taken a stab at reducing test flakiness, I've come across at least a few tests that pass when run as part of the test suite, but fail when run by themselves (or in parallel) because they accidentally expect an image or something to be in the cache. I think it would make the tests more maintainable if we cleared the cache before each test run. This is *not* before each page load though. So tests that do multiple page loads will still test cross-navigation caching behavior. While it's true that we could one-off fix each of these tests, it's usually very time consuming to figure out that caching is the problem, that's assuming anyone takes the time to look into why the test is flaky in the first place. Any objections? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov a...@webkit.org wrote: I can see some downsides to emptying the cache before each test: - we won't be getting any test coverage for cache behavior when it hits non-trivial size; Then let's add a cache test explicitly for this. Otherwise we just have to hope it gets tested accidentally along the way. - this may well make tests measurably slower; - this will be yet another cause of subtle difference between platforms, as some will undoubtedly have this unimplemented for a long time. Both good points, but probably worth it, given the reliability improvement in the tests IMO. Eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov a...@webkit.org wrote: I can see some downsides to emptying the cache before each test: - we won't be getting any test coverage for cache behavior when it hits non-trivial size; We should have a separate test for that as Eric pointed out. - this may well make tests measurably slower; - this will be yet another cause of subtle difference between platforms, as some will undoubtedly have this unimplemented for a long time. On the contrary, it may well improve the overall bot cycle time because flaky tests are ran twice on new-run-webkit-tests if we actually have many tests that are flaky because of this. We also parallelize tests and resources are loaded from the disk (with cache) so I highly suspect this will be an issue. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] svns...@macosforge.org ?
I noticed today that some patches are authored by svns...@macosforge.org: http://trac.webkit.org/search?q=svnsync Is this behavior expected? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?
On Wed, Aug 8, 2012 at 10:47 AM, Ojan Vafai o...@chromium.org wrote: See https://bugs.webkit.org/show_bug.cgi?id=93195. media/W3C/video/networkState/networkState_during_progress.html and media/video-poster-blocked-by-willsendrequest.html are flaky on all platforms because they behave differently if the loaded resource is cached. Every time I've taken a stab at reducing test flakiness, I've come across at least a few tests that pass when run as part of the test suite, but fail when run by themselves (or in parallel) because they accidentally expect an image or something to be in the cache. I think it would make the tests more maintainable if we cleared the cache before each test run. This is *not* before each page load though. So tests that do multiple page loads will still test cross-navigation caching behavior. While it's true that we could one-off fix each of these tests, it's usually very time consuming to figure out that caching is the problem, that's assuming anyone takes the time to look into why the test is flaky in the first place. Any objections? Given that the way we run tests in parallel in NRWT means that different processes get different lists of tests each time, it sounds like we may be getting a fair amount of nondeterminism from the cache not being cleared between tests. That seems bad, so I'm in favor of clearing the cache :) -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Optimize Property Access failed
The existence of the enable flag you mention implies that you have an ancient
version of WebKit. Please consider updating.
-Filip
On Aug 7, 2012, at 11:39 PM, talking1...@gmail.com wrote:
Hi
I enable ENABLE_JIT_OPTIMIZE_PROPERTY_ACCESS feature and find that it will
crash when go back the home page after run follow test case, I think it is
caused by the optimize propery access, so anyone know that it is caused by
the arch related code or jit Infrastructure code? and if i disable
ENABLE_JIT_OPTIMIZE_PROPERTY_ACCESS feature, it will run correctly.
Any help explaining this would be much appreciated!
test case:
var Origin = new Object();
function Init() {
Origin.V = [150]
}
for ( var i = 20; i = 160; i *= 2 ) {
//Init(i);
}
Init();
Init();
Init();
Origin = null;
Callstack:
JAVASCRIPTCORE!const JSC::JSArray::`vftable' + 2 bytes
JAVASCRIPTCORE!JSC::Heap::sweep() line 1104 + 14 bytes
JAVASCRIPTCORE!JSC::Heap::collectAllGarbage() line 1306
WEBKIT!WebCore::collect(void * 0x) line 47
WEBKIT!WebCore::GCController::gcTimerFired(WebCore::TimerWebCore::GCController
* 0x06a905a0 {m_object=??? m_function=??? }) line 70
WEBKIT!WebCore::TimerWebCore::PageCache::fired() line 98 + 20 bytes
WEBKIT!WebCore::ThreadTimers::sharedTimerFiredInternal() line 115
WEBKIT!WebCore::ThreadTimers::sharedTimerFired() line 91
--
BGs/Felix Shi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] We should encourage the use of httpS://svn.webkit.org
Hi, It appears that we recommend the use of non-secure HTTP connection on many webkit.org documents: e.g. https://www.webkit.org/building/checkout.html Can we move away from this and recommend the use of HTTPS instead? It's very easy to eavesdrop the svn credentials if we're using HTTP. Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [squirrelfish] [webkit-help] Optimize Property Access failed
My webkkit version 60* and many custom features are verified, so it is hard
to update it. But after check the Changlog, i find that GC is related with JIT
Infrastructure and ARCH code.
--
BGs/Felix Shi
At 2012-08-09 07:36:16,Filip Pizlo fpi...@apple.com wrote:
The existence of the enable flag you mention implies that you have an ancient
version of WebKit. Please consider updating.
-Filip
On Aug 7, 2012, at 11:39 PM, talking1...@gmail.com wrote:
Hi
I enable ENABLE_JIT_OPTIMIZE_PROPERTY_ACCESS feature and find that it will
crash when go back the home page after run follow test case, I think it is
caused by the optimize propery access, so anyone know that it is caused by the
arch related code or jit Infrastructure code? and if i disable
ENABLE_JIT_OPTIMIZE_PROPERTY_ACCESS feature, it will run correctly.
Any help explaining this would be much appreciated!
test case:
var Origin = new Object();
function Init() {
Origin.V = [150]
}
for ( var i = 20; i = 160; i *= 2 ) {
//Init(i);
}
Init();
Init();
Init();
Origin = null;
Callstack:
JAVASCRIPTCORE!const JSC::JSArray::`vftable' + 2 bytes
JAVASCRIPTCORE!JSC::Heap::sweep() line 1104 + 14 bytes
JAVASCRIPTCORE!JSC::Heap::collectAllGarbage() line 1306
WEBKIT!WebCore::collect(void * 0x) line 47
WEBKIT!WebCore::GCController::gcTimerFired(WebCore::TimerWebCore::GCController
* 0x06a905a0 {m_object=??? m_function=??? }) line 70
WEBKIT!WebCore::TimerWebCore::PageCache::fired() line 98 + 20 bytes
WEBKIT!WebCore::ThreadTimers::sharedTimerFiredInternal() line 115
WEBKIT!WebCore::ThreadTimers::sharedTimerFired() line 91
--
BGs/Felix Shi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
