[webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
Hi all, I am facing a problem while compiling the webkit-nightly build in debug mode. At the time of linking*(eg. CXXLD libwebkitgtk-3.0.la)*, it gets stopped with an error(*eg. /usr/bin/ld: failed to set dynamic section sizes: Memory exhausted)* What, I have tried: 1)By resizing the swappiness value(/proc/sys/vm/swappiness). 2)By creating a swap partition(eg. /mnt/512MiB.swap). But didn't get the problem resolved. Presently I have 4GB of main memory equipped. The same nightly build has no such an issue if debug mode is disabled. Please help me and let me know for a solution. Thanks Regards, Sanjeet ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
I think you have to have at least 8 GiB of RAM (16 GiB is recommended) and 64-bit OS to compile webkit in debug mode. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
Or you can add 8 GiB of swap, like I did before I upgraded my machine: https://lists.webkit.org/pipermail/webkit-help/2011-November/002678.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
Hi John, Thanks for your instant response. But, I had been compiling webkit in debug mode earlier, with the same configurations with no such any error. And thats why I doubt whether increasing the RAM, is an proper and generic solution. Thanks, Sanjeet On Fri, Mar 23, 2012 at 3:18 PM, John Yani van...@gmail.com wrote: I think you have to have at least 8 GiB of RAM (16 GiB is recommended) and 64-bit OS to compile webkit in debug mode. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
WebKit's codebase increases every day, so It's not strange that it requires more and more memory to link. On 23 March 2012 12:03, Sanjeet Pratap Singh sanjeetpratapsi...@gmail.com wrote: Hi John, Thanks for your instant response. But, I had been compiling webkit in debug mode earlier, with the same configurations with no such any error. And thats why I doubt whether increasing the RAM, is an proper and generic solution. Thanks, Sanjeet On Fri, Mar 23, 2012 at 3:18 PM, John Yani van...@gmail.com wrote: I think you have to have at least 8 GiB of RAM (16 GiB is recommended) and 64-bit OS to compile webkit in debug mode. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
Hi Sanjeet, I can confirm that the memory is most likely the problem. Especially WebKit/WebCore is growing steadily, whenever code is being added. And with WebCore we (Qt) had the problem on mac of crossing the 4GB boundary just a few days ago. So it is very likely that other ports will experience similar problems. In our case we had to make use of some of the *AllInOne files. Because we are building WebCore as a static library. And on mac you currently can't build static libs 4GB at all it seems. Ranlib always crashes when trying to build the symbol table. This even affects 64bit systems with 12GB of ram. :-| Best Regards, Zeno On Fri, Mar 23, 2012 at 11:03 AM, Sanjeet Pratap Singh sanjeetpratapsi...@gmail.com wrote: Hi John, Thanks for your instant response. But, I had been compiling webkit in debug mode earlier, with the same configurations with no such any error. And thats why I doubt whether increasing the RAM, is an proper and generic solution. Thanks, Sanjeet On Fri, Mar 23, 2012 at 3:18 PM, John Yani van...@gmail.com wrote: I think you have to have at least 8 GiB of RAM (16 GiB is recommended) and 64-bit OS to compile webkit in debug mode. ___ 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] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
This even affects 64bit systems with 12GB of ram. :-| So you're saying that you've tried to build webkit on 64bit system with 12GiB of RAM and failed? How much memory is used when build is not running? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
On Fri, Mar 23, 2012 at 11:14 AM, John Yani van...@gmail.com wrote: This even affects 64bit systems with 12GB of ram. :-| So you're saying that you've tried to build webkit on 64bit system with 12GiB of RAM and failed? How much memory is used when build is not running? Yes, this is a bug or undocumented limitation in ranlib/libtool i believe. I can reproduce it with any static library/archive that is 4GB. While building the archive itself works fine, ranlib fails to build a symbol table for the archive. So why is that not a problem for the Apple port? - Simple answer: They are building WebCore as a framework (dynamic library). :-) The available memory is for sure not the problem in my case. Because even when building/linking i still have about 6GB free (free+inactive). ___ 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
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.
Let's suppose I have some unannounced product like
unannounced.google.comand say it embeds an iframe.
Isn't it a information disclosure issue that anyone can now detect the
usage of unannounced.google.com when they are framed (especially if
unannounced were more descriptive)?
dave
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] Throwing SECURITY_ERR on cross-origin window.location property accesses
That's a risk, but you could also worry that the name would leak in the
iframe's document.referrer property.
Adam
On Mar 23, 2012 12:02 PM, David Levin le...@chromium.org wrote:
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.
Let's suppose I have some unannounced product like unannounced.google.comand
say it embeds an iframe.
Isn't it a information disclosure issue that anyone can now detect the
usage of unannounced.google.com when they are framed (especially if
unannounced were more descriptive)?
dave
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] Throwing SECURITY_ERR on cross-origin window.location property accesses
On Fri, Mar 23, 2012 at 12:13 PM, Adam Barth aba...@webkit.org wrote:
That's a risk, but you could also worry that the name would leak in the
iframe's document.referrer property.
Frankly, I'm in favor of anything to help me get rid of the console error
:).
I was concerned that exposing the parent origin has complications that will
make it harder for this to get into WebKit, etc. but if folks find that
acceptable, it scratches my itch.
dave
Adam
On Mar 23, 2012 12:02 PM, David Levin le...@chromium.org wrote:
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.
Let's suppose I have some unannounced product like unannounced.google.comand
say it embeds an iframe.
Isn't it a information disclosure issue that anyone can now detect the
usage of unannounced.google.com when they are framed (especially if
unannounced were more descriptive)?
dave
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] Problem In Compiling Webkit in Debug mode : failed to set dynamic section sizes: Memory exhausted
On Fri, 2012-03-23 at 12:08 +0200, John Yani wrote: WebKit's codebase increases every day, so It's not strange that it requires more and more memory to link. The maintainer of the WebKitGTK+ package in Ubuntu told me about a linker switch they are using to avoid problems when building in 32 bits systems: --no-keep-memory ld normally optimizes for speed over memory usage by caching the symbol tables of input files in memory. This option tells ld to instead optimize for memory usage, by rereading the symbol tables as necessary. This may be required if ld runs out of memory space while linking a large executable. Notice that that seems to only work for GNU ld - the gold linker has this as a no-op for compatibility only. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] About WebKit memory cache
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;?
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?
Thanks in advance!
Best RegardsRock ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
