Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

>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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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.)

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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 >

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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:

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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).

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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

Re: Re-visiting the DOM tree depth limit in layout

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