Re: [webkit-dev] About WebKit memory cache

2012-03-26 Thread Nate Chapin
On Fri, Mar 23, 2012 at 7:48 PM, gaorock por...@hotmail.com wrote:

  Hi all

 Sometimes I met crashes about memory cache, and I traced them and found a
 bit doubt:

 Should we use
 typedef HashMapString, RefPtrCachedResource CachedResourceMap;
 instead of
 typedef HashMapString, CachedResource* CachedResourceMap;?


CachedResource doesn't support reference counting in the usual model.  It
uses a somewhat confusing set of rules to decide when to delete itself. See
canDelete() in CachedResource.h. Figuring out a way to make CachedResource
use our normal reference counting model is on my list of things to do
someday. :-)



 The following is the call stack, hope it's useful for you:

   WebKit.dll!WebCore::ResourceRequestBase::updateResourceRequest()
  Line447 + 0x37 byte C++
   WebKit.dll!WebCore::ResourceRequestBase::url()  Line123 C++
   WebKit.dll!WebCore::CachedResource::url()  Line106 + 0x19 byte C++
  WebKit.dll!WebCore::CachedResourceLoader::requestResource(WebCore::CachedResource::Type
 type=ImageResource, WebCore::ResourceRequest  request={...}, const
 WTF::String  charset={...}, const WebCore::ResourceLoaderOptions 
 options={...}, WebCore::ResourceLoadPriority priority=-1, bool
 forPreload=false)  Line444 + 0x11 byte C++
   
 WebKit.dll!WebCore::CachedResourceLoader::requestImage(WebCore::ResourceRequest
  request={...})  Line160 + 0x21 byte C++
   WebKit.dll!WebCore::CSSImageValue::cachedImage(WebCore::CachedResourceLoader
 * loader=0x00e6e6d8, const WTF::String  url={...})  Line90 + 0xf byte C++
   WebKit.dll!WebCore::CSSImageValue::cachedImage(WebCore::CachedResourceLoader
 * loader=0x00e6e6d8)  Line79 + 0x19 byte C++
   
 WebKit.dll!WebCore::CSSStyleSelector::loadPendingImage(WebCore::StylePendingImage
 * pendingImage=0x0ada6f30)  Line5306 + 0xc byte C++
   WebKit.dll!WebCore::CSSStyleSelector::loadPendingImages()  Line5331 +
 0x15 byte C++
   WebKit.dll!WebCore::CSSStyleSelector::applyMatchedDeclarations(const
 WebCore::CSSStyleSelector::MatchResult  matchResult={...})  Line2408 C++
   WebKit.dll!WebCore::CSSStyleSelector::styleForElement(WebCore::Element
 * element=0x0ad08088, WebCore::RenderStyle * defaultParent=0x, bool
 allowSharing=true, bool resolveForRootDefault=false)  Line1310 C++
   WebKit.dll!WebCore::Element::styleForRenderer()  Line1035 + 0x24 byte
 C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1059 + 0xc byte C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1138 C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1138 C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1138 C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1138 C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1138 C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1138 C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1138 C++
   WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1138 C++
   WebKit.dll!WebCore::Document::recalcStyle(WebCore::Node::StyleChange
 change=NoChange)  Line1574 C++
   WebKit.dll!WebCore::Document::updateStyleIfNeeded()  Line1634 C++
   WebKit.dll!WebCore::Document::updateLayout()  Line1658 + 0x12 byte C++

 In the function of WebCore::ResourceRequestBase::updateResourceRequest(),
 the point this is NOT null, but all of its members are null, so actually
 it had been freed before. So I think the refCount may be helpful to solve
 this problem.

 This is my first time to write to WebKit-dev, it will be appreciated if
 someone could give me some instructions or whether I should file a bug for
 it?


Yes, please file a bug on bugs.webkit.org, and feel free to point me in its
direction.



 Thanks in advance!

 Best Regards
 Rock

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Fwd: Please add EditBugs to my account

2012-03-26 Thread Tony Payne
Error message in webkit-patch upload says to email webkit-committers, but
that message is not going through and I've been told this is the proper
list to request the EditBugs permission.

Thanks,
Tony

-- Forwarded message --
From: Tony Payne tpa...@chromium.org
Date: Thu, Mar 22, 2012 at 3:39 PM
Subject: Please add EditBugs to my account
To: webkit-committ...@lists.webkit.org


I'm working on a patch to WebKit and need to upload the patch to
bugs.webkit.org. Would you please add EditBugs permission to my account (
tpa...@chromium.org)?

Thanks
Tony
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] PSA: Chromium layout test fallbacks AKA down with graphs, long live trees

2012-03-26 Thread Ojan Vafai
Sometime this week or next, we plan to change the Chromium layout test
fallback order. We'll be changing it so all chromium ports fallback to
platform/chromium, then to platform/mac. They will never fallback to
platform/win or platform/mac-* as they do today.

The benefits of this change are that it makes the fallback order much
easier to reason about for both human beings and code. I believe it makes
the fallback order for all WebKit ports a tree instead of a complex graph.
This will have minimal impact on the number of expected result files in the
tree since only a few hundred chromium tests currently fallback to
platform/win and/or platform/mac-*.

Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Fwd: Please add EditBugs to my account

2012-03-26 Thread David Levin
Done.

On Mon, Mar 26, 2012 at 11:47 AM, Tony Payne tpa...@chromium.org wrote:


 Error message in webkit-patch upload says to email webkit-committers, but
 that message is not going through and I've been told this is the proper
 list to request the EditBugs permission.

 Thanks,
 Tony

 -- Forwarded message --
 From: Tony Payne tpa...@chromium.org
 Date: Thu, Mar 22, 2012 at 3:39 PM
 Subject: Please add EditBugs to my account
 To: webkit-committ...@lists.webkit.org


 I'm working on a patch to WebKit and need to upload the patch to
 bugs.webkit.org. Would you please add EditBugs permission to my account (
 tpa...@chromium.org)?

 Thanks
 Tony



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses

2012-03-26 Thread Adam Barth
I've started a thread on whatwg in case folks with like to discuss
this topic further:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-March/035188.html

Thanks,
Adam


On Thu, Mar 22, 2012 at 9:21 PM, Adam Barth aba...@webkit.org wrote:
 I wonder if we could expose the parent document's origin, so you could
 write the check as follows:

 if (parent.location.origin != location.origin)
    return;

 It's slightly subtle because we wouldn't want to expose the origin of
 child frames (then you could probe the redirect structure of private
 networks), but exposing ancestor origins seems tenable.

 Adam


 On Thu, Mar 22, 2012 at 9:16 PM, David Levin le...@chromium.org wrote:
 Suppose I am using a framework does window.frameElement for various
 reasons. When that framework is used in an iframe, it causes errors to
 appear in the console.

 For example, suppose the framework does this:

 var a;
 try {
     a = window.frameElement; // WebKit outputs a console error here.
     if (!a)
         return;
 } catch (e) {
     return;
 }
 ...


 Now if I had this new method, I would change the framework to do this:

 var a;
 try {
     // WebKit doesn't throw an exception for x-origin parent access, but it
 will puts errors in the console.
     // Do an explicit access check to avoid having the error appear in the
 console.
     var canAccessParent = window.parent.webkitCanAccess;
     if (canAccessParent != undefined  !canAccessParent)
         return;
     a = window.frameElement;
     if (!a)
         return;
 } catch (e) {
     return;
 }
 ...


 Does that help? (The use case is about avoiding spurious console error
 messages, so console error messages are real errors.)

 dave


 On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig wei...@apple.com wrote:

 Hey Dave,

 Can you describe the use case for this new property?  When would an author
 use it?

 -Sam

 On Mar 22, 2012, at 4:16 PM, David Levin le...@chromium.org wrote:

 Resurrecting a really old thread so continue the conversation now that I'm
 hitting this issue :).

 On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig sam.wei...@gmail.com wrote:

 I am not sure I agree.  Does our behavior actually cause any real bugs in
 the places you have tracked down?  The log spam really doesn't seem like an
 issue, we can remove it if we want to, but have found it useful in the
 past.


 Speaking as someone who working on a web app, the log spam is
 a significant issue because:

 It clutters up the console output making it harder to find the real error.
 (It is hard to explain how much worse this makes the experience until you
 have to deal with a sophisticated web page. Image looking at the logs from
 your app and seeing lots of error messages -- many of which are this one and
 then a real one hidden among them -- from personal experience.)
 When more sophisticated end users see it, they think there is a problem in
 the app and report it (and it could be that they include this in their error
 report and ignore other more important things).

 I understand that that the console/log spam is useful to detect real
 issues as well (given that WebKit doesn't throw an exception in this case).

 Would people find it acceptable to have window.webkitCanAccess so that a
 web page can use that property first to detect the cross origin issue and
 avoid doing an access which would trigger the console spam? (I would also be
 fine with an exception instead of log spam.)

 Thanks,
 dave



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] About WebKit memory cache

2012-03-26 Thread gaorock

Hi jap...@chromium.org
Thanks for your reply :)The bug#82287 has been filed.
Best RegardsRock

Date: Mon, 26 Mar 2012 08:44:36 -0700
Subject: Re: [webkit-dev] About WebKit memory cache
From: jap...@chromium.org
To: por...@hotmail.com
CC: webkit-dev@lists.webkit.org

On Fri, Mar 23, 2012 at 7:48 PM, gaorock por...@hotmail.com wrote:





Hi all
Sometimes I met crashes about memory cache, and I traced them and found a bit 
doubt:
Should we use typedef HashMapString, RefPtrCachedResource CachedResourceMap;
instead of typedef HashMapString, CachedResource* CachedResourceMap;?
CachedResource doesn't support reference counting in the usual model.  It uses 
a somewhat confusing set of rules to decide when to delete itself. See 
canDelete() in CachedResource.h. Figuring out a way to make CachedResource use 
our normal reference counting model is on my list of things to do someday. :-)
 
The following is the call stack, hope it's useful for you:

WebKit.dll!WebCore::ResourceRequestBase::updateResourceRequest()  
Line447 + 0x37 byte   C++ WebKit.dll!WebCore::ResourceRequestBase::url()  
Line123 C++
WebKit.dll!WebCore::CachedResource::url()  Line106 + 0x19 byte  C++
WebKit.dll!WebCore::CachedResourceLoader::requestResource(WebCore::CachedResource::Type
 type=ImageResource, WebCore::ResourceRequest  request={...}, const 
WTF::String  charset={...}, const WebCore::ResourceLoaderOptions  
options={...}, WebCore::ResourceLoadPriority priority=-1, bool 
forPreload=false)  Line444 + 0x11 byte   C++

WebKit.dll!WebCore::CachedResourceLoader::requestImage(WebCore::ResourceRequest 
 request={...})  Line160 + 0x21 byte   C++

WebKit.dll!WebCore::CSSImageValue::cachedImage(WebCore::CachedResourceLoader * 
loader=0x00e6e6d8, const WTF::String  url={...})  Line90 + 0xf byte C++

WebKit.dll!WebCore::CSSImageValue::cachedImage(WebCore::CachedResourceLoader * 
loader=0x00e6e6d8)  Line79 + 0x19 byte   C++

WebKit.dll!WebCore::CSSStyleSelector::loadPendingImage(WebCore::StylePendingImage
 * pendingImage=0x0ada6f30)  Line5306 + 0xc byte   C++
WebKit.dll!WebCore::CSSStyleSelector::loadPendingImages()  Line5331 + 
0x15 byte C++ 
WebKit.dll!WebCore::CSSStyleSelector::applyMatchedDeclarations(const 
WebCore::CSSStyleSelector::MatchResult  matchResult={...})  Line2408  C++
WebKit.dll!WebCore::CSSStyleSelector::styleForElement(WebCore::Element 
* element=0x0ad08088, WebCore::RenderStyle * defaultParent=0x, bool 
allowSharing=true, bool resolveForRootDefault=false)  Line1310   C++
WebKit.dll!WebCore::Element::styleForRenderer()  Line1035 + 0x24 byte   
C++ WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1059 + 0xc byte   C++
WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1138  C++ 
WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1138  C++
WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1138  C++ 
WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1138  C++
WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1138  C++ 
WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1138  C++
WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1138  C++ 
WebKit.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1138  C++
WebKit.dll!WebCore::Document::recalcStyle(WebCore::Node::StyleChange 
change=NoChange)  Line1574 C++ 
WebKit.dll!WebCore::Document::updateStyleIfNeeded()  Line1634   C++
WebKit.dll!WebCore::Document::updateLayout()  Line1658 + 0x12 byte  
C++
In the function of WebCore::ResourceRequestBase::updateResourceRequest(), the 
point this is NOT null, but all of its members are null, so actually it had 
been freed before. So I think the refCount may be helpful to solve this problem.

This is my first time to write to WebKit-dev, it will be appreciated if someone 
could give me some instructions or whether I should file a bug for it?

Yes, please file a bug on bugs.webkit.org, and feel free to point me in its 
direction. 

Thanks in advance!
Best RegardsRock  

___

webkit-dev mailing list

webkit-dev@lists.webkit.org

http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



  
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev