On 9/15/17 6:35 AM, Henri Sivonen wrote:
I'm assuming that anonymous frames count towards the
limit and a display: table-cell that doesn't belong to a table ends up
creating 5 frames. Correct?
Yes for both. It creates a table, table-row-group, table-row,
table-cell, and a block inside the tab
On Thu, Sep 14, 2017, at 02:23 AM, Henri Sivonen wrote:
> Do I understand correctly that this is an address space issue only and
> Windows doesn't actually physically map the pages belonging to the
> stack until they are written to? That is, do I understand correctly
> that there's no obstacle for
Also, it seems that Android doesn't use the Linux stack defaults.
Is the stack size under our control on Android?
On Fri, Sep 15, 2017 at 1:35 PM, Henri Sivonen wrote:
> On Fri, Sep 15, 2017 at 12:26 PM, Henri Sivonen wrote:
>> From black-box testing, it seems that some part of layout has gotte
On Fri, Sep 15, 2017 at 12:26 PM, Henri Sivonen wrote:
> From black-box testing, it seems that some part of layout has gotten a
> new << 200 depth limit for nested display:table-cell some time between
> September 11 and September 14.
>
> To save myself the trouble of bisecting this, does anyone kn
>From black-box testing, it seems that some part of layout has gotten a
new << 200 depth limit for nested display:table-cell some time between
September 11 and September 14.
To save myself the trouble of bisecting this, does anyone know which
patch did this and why?
--
Henri Sivonen
hsivo...@hsi
On Thu, Sep 14, 2017 at 12:38 AM, Mike Hommey wrote:
> We could also move the main thread loop to a thread that we create with
> a stack size we want, and leave the original main thread just waiting
> for it (joining it).
What kind of pitfalls are associated with this approach? Could Windows
itse
On Thu, Sep 14, 2017 at 9:23 AM, Henri Sivonen wrote:
> Is there a reason why a larger stack size is OK on 32-bit Linux but
> wouldn't be OK on 32-bit Windows? (Seems kinda weird that both
> defaults would just happen to be exactly perfect even when they are so
> different.)
https://msdn.microsof
On Thu, Sep 14, 2017 at 8:23 AM, Henri Sivonen wrote:
> Do I understand correctly that this is an address space issue only and
> Windows doesn't actually physically map the pages belonging to the
> stack until they are written to? That is, do I understand correctly
> that there's no obstacle for
On Wed, Sep 13, 2017 at 5:19 PM, Jan de Mooij wrote:
> On Wed, Sep 13, 2017 at 10:44 AM, Henri Sivonen
> wrote:
>>
>> 3) Increase the run-time stack size on Windows such that 1026-deep
>> display: table-cell doesn't overflow the stack.
>
>
> On Windows, threads that are created without an explici
On Wed, Sep 13, 2017 at 10:03:55AM -0700, Eric Rahm wrote:
> Jan is right, increasing the stack size for all threads would cause a very
> large memory regression. Lets not do that ;) Selectively increasing might
> make sense but we'd need to keep an eye on how large of an increase we're
> expecting
Jan is right, increasing the stack size for all threads would cause a very
large memory regression. Lets not do that ;) Selectively increasing might
make sense but we'd need to keep an eye on how large of an increase we're
expecting.
-e
On Wed, Sep 13, 2017 at 7:19 AM, Jan de Mooij wrote:
> On
On Wed, Sep 13, 2017 at 10:44 AM, Henri Sivonen
wrote:
> 3) Increase the run-time stack size on Windows such that 1026-deep
> display: table-cell doesn't overflow the stack.
>
On Windows, threads that are created without an explicit stack size also
use the executable's stack size. So increasing
On Sep 13, 2017 15:52, "Ben Kelly" wrote:
On Wed, Sep 13, 2017 at 4:44 AM, Henri Sivonen wrote:
> I suggest we do the following:
>
> 1) Change the HTML parser behave more like Blink's: Raise the limit
> to 513 elements deep and append elements violating the limit to the
> 512th element on th
On Wed, Sep 13, 2017 at 4:44 AM, Henri Sivonen wrote:
> I suggest we do the following:
>
> 1) Change the HTML parser behave more like Blink's: Raise the limit
> to 513 elements deep and append elements violating the limit to the
> 512th element on the stack instead of dropping them. (Since the
>
On Tue, Sep 12, 2017 at 12:46 PM, Henri Sivonen wrote:
> On Tue, Sep 12, 2017 at 12:35 PM, Henri Sivonen wrote:
>> I'm rather unhappy about the prospect of having to examine another
>> browser's HTML parser beyond reading the spec in order to achieve
>> interop. :-(
>
> Fortunately, not too compl
On Tue, Sep 12, 2017 at 12:35 PM, Henri Sivonen wrote:
> I'm rather unhappy about the prospect of having to examine another
> browser's HTML parser beyond reading the spec in order to achieve
> interop. :-(
Fortunately, not too complicated:
https://cs.chromium.org/chromium/src/third_party/WebKit/
On Mon, Sep 11, 2017 at 5:37 PM, Geoffrey Sneddon wrote:
> Chrome limits the DOM at 513 deep (where the root element is one
> deep), Safari likewise but doesn't paint anything. Edge appears to
> have no limit, so that TC simply hangs in an infinite loop (presumably
> it will eventually go OOM and
Note also that, post-stylo, there are some very rough plans to investigate
rewriting the frame constructor in parallel Rust, which would likely move
us to a non-recursive model. But we probably won't start brainstorming the
details until the all-hands, have no idea if it will work, and even if it
d
On Mon, Sep 11, 2017 at 5:27 PM, wrote:
> On Monday, September 11, 2017 at 1:41:43 PM UTC+2, Henri Sivonen wrote:
> > Can we ask Windows to give us more stack space?
> > --
> Don't know if it's possible to set it dynamically at runtime, but Visual
> Studio supports setting it at compile time (in
On Monday, September 11, 2017 at 1:41:43 PM UTC+2, Henri Sivonen wrote:
> Can we ask Windows to give us more stack space?
> --
Don't know if it's possible to set it dynamically at runtime, but Visual Studio
supports setting it at compile time (in linker options).
On Mon, Sep 11, 2017 at 3:08 PM, Henri Sivonen wrote:
>> Per comments in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=485941 at least in their XML
>> parser they do have a depth limit of about 5000, but that was apparently
>> removed and then readded recently. Of course they may have different
On 9/11/17 10:08 AM, Henri Sivonen wrote:
What kind of style would have the maximum stack frame size? Is
display: table-cell enough to trigger the worst case?
I suspect that display:table-cell is the worst case, but at only about
70% confidence.
That said, I can't think of a worse case offha
On Mon, Sep 11, 2017 at 3:49 PM, Boris Zbarsky wrote:
>> I'd expect text node recovery (flattening out elements and just
>> considering text nodes) in the frame constructor to be a more robust
>> solution than trying to address the problem in the HTML parser. What's
>> the feasibility of such a fr
On 9/11/17 7:41 AM, Henri Sivonen wrote:
Frame construction runs recursive algorithms along the depth of the
DOM tree.
It's not just frame construction. Recursive algorithms are all over the
place in layout and DOM code.
Frame construction may be a long pole here in terms of crashes due to
On Mon, Sep 11, 2017 at 2:41 PM, Henri Sivonen wrote:
> * Firefox opt build on x86_64 Linux crashes when the DOM depth is
> between 3000 and 3100.
> * Mac: between 3900 and 4000.
32-bit Linux: between 3900 and 4000
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
Frame construction runs recursive algorithms along the depth of the
DOM tree. The depth is currently capped at 200, because deeper trees
caused stack overflow crashes on Windows in the Windows 95 era. There
is a corresponding limit the HTML parser. The parser limit is there
just to avoid showing fr
26 matches
Mail list logo
