Right now, it looks like a substantial portion of our crashes with this signature are stack overflows, without any particularly deep backtrace. e.g. bp-c4fa80d3-88b7-4416-9f85-c24cb0221013 These stack overflows seem to be pointing to our call to [`BuildTextRuns`](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1494) -- we're exhausting stack memory when we try to allocate space for our local variables when we enter that function. Maybe there's something we can do to make that function a little cheaper in terms of stack-space-usage? At first glance, it looks like the heavyweight things there are: * `BuildTextRunsScanner scanner` which brings along some AutoTArray instances which each reserve some stack space. * Another `AutoTArray<char16_t, BIG_TEXT_NODE_SIZE> buffer;` https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1590 Note that `BIG_TEXT_NODE_SIZE` is 4096, [defined here](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrameUtils.h#22), which goes back to bug 333659 in 2007 in [this commit](https://searchfox.org/mozilla-central/commit/e6bad38abe779bd329f48c52ab90fbae7b80bc03). 4096 feels quite large... That means this one AutoTArray uses at least 8KB of stack space, which is substantial. I wonder how often we actually grow to use all 4096 entries there, and if just failing over to heap allocation would be ~fine in that case. jfkthame, do you think we could change our AutoTArray usage there (and maybe BIG_TEXT_NODE_SIZE in general) to be more conservative of stack space, to avoid triggering stack overflows when entering this function?
Bug 1153736 Comment 12 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Right now, it looks like a substantial portion of our crashes with this signature are stack overflows, without any particularly deep backtrace (i.e. not a recursive death spiral type overflow). e.g. this one: bp-c4fa80d3-88b7-4416-9f85-c24cb0221013 These stack overflows seem to be pointing to our call to [`BuildTextRuns`](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1494) -- we're exhausting stack memory when we try to allocate space for our local variables when we enter that function. Maybe there's something we can do to make that function a little cheaper in terms of stack-space-usage? At first glance, it looks like the heavyweight things there are: * `BuildTextRunsScanner scanner` which brings along some AutoTArray instances which each reserve some stack space. * Another `AutoTArray<char16_t, BIG_TEXT_NODE_SIZE> buffer;` https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1590 Note that `BIG_TEXT_NODE_SIZE` is 4096, [defined here](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrameUtils.h#22), which goes back to bug 333659 in 2007 in [this commit](https://searchfox.org/mozilla-central/commit/e6bad38abe779bd329f48c52ab90fbae7b80bc03). 4096 feels quite large... That means this one AutoTArray uses at least 8KB of stack space, which is substantial. I wonder how often we actually grow to use all 4096 entries there, and if just failing over to heap allocation would be ~fine in that case. jfkthame, do you think we could change our AutoTArray usage there (and maybe BIG_TEXT_NODE_SIZE in general) to be more conservative of stack space, to avoid triggering stack overflows when entering this function?
Right now, it looks like a substantial portion of our crashes with this signature are stack overflows, without any particularly deep backtrace (i.e. not a recursive death spiral type overflow). e.g. this one: bp-c4fa80d3-88b7-4416-9f85-c24cb0221013 These stack overflows seem to be pointing to our call to [`BuildTextRuns`](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1494) -- we're exhausting stack memory when we try to allocate space for our local variables when we enter that function. Maybe there's something we can do to make that function a little cheaper in terms of stack-space-usage? At first glance, it looks like the heavyweight things there are: * `BuildTextRunsScanner scanner` which brings along [some `AutoTArray` instances](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1220-1222) which each reserve some stack space. (on the order of 100 pointers worth in total, I think? Three arrays with size 10, 50, and 10, where the first array stores pointer-pairs, and the last two arrays store individual pointers.) * Another `AutoTArray<char16_t, BIG_TEXT_NODE_SIZE> buffer;` https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1590 Note that `BIG_TEXT_NODE_SIZE` is 4096, [defined here](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrameUtils.h#22), which goes back to bug 333659 in 2007 in [this commit](https://searchfox.org/mozilla-central/commit/e6bad38abe779bd329f48c52ab90fbae7b80bc03). 4096 feels quite large... That means this one AutoTArray uses at least 8KB of stack space, which is substantial. I wonder how often we actually grow to use all 4096 entries there, and if just failing over to heap allocation would be ~fine in that case. jfkthame, do you think we could change our AutoTArray usage there (and maybe BIG_TEXT_NODE_SIZE in general) to be more conservative of stack space, to avoid triggering stack overflows when entering this function?
Right now, it looks like a substantial portion of our crashes with this signature are stack overflows, without any particularly deep backtrace (i.e. not a recursive death spiral type overflow). e.g. this one: bp-c4fa80d3-88b7-4416-9f85-c24cb0221013 These stack overflows seem to be pointing to our call to [`BuildTextRuns`](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1494) -- we're exhausting stack memory when we try to allocate space for our local variables when we enter that function. Maybe there's something we can do to make that function a little cheaper in terms of stack-space-usage? At first glance, it looks like the heavyweight things there are: * `BuildTextRunsScanner scanner` which brings along [some `AutoTArray` instances](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1220-1222) which each reserve some stack space. (on the order of 100 pointers worth in total, I think? Three arrays with size 10, 50, and 10, where the first array stores pointer-pairs, and the last two arrays store individual pointers.) * Another `AutoTArray<char16_t, BIG_TEXT_NODE_SIZE> buffer;` https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1590 Note that `BIG_TEXT_NODE_SIZE` is 4096, [defined here](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrameUtils.h#22), which goes back to bug 333659 in 2007 in [this commit](https://searchfox.org/mozilla-central/commit/e6bad38abe779bd329f48c52ab90fbae7b80bc03). 4096 feels quite large... That means this one AutoTArray uses at least 8KB of stack space (`uint16_t` is 2 bytes, and we're storing 4096 2-byte values, which is 8192 i.e. 8KB). That feels substantial. I wonder how often we actually grow to use all 4096 entries there, and if just failing over to heap allocation would be ~fine in that case. jfkthame, do you think we could change our AutoTArray usage there (and maybe BIG_TEXT_NODE_SIZE in general) to be more conservative of stack space, to avoid triggering stack overflows when entering this function?
Right now, it looks like a substantial portion of our crashes with this signature are stack overflows, without any particularly deep backtrace (i.e. not a recursive death spiral type overflow). e.g. this one: bp-c4fa80d3-88b7-4416-9f85-c24cb0221013 These stack overflows seem to be pointing to our call to [`BuildTextRuns`](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1494) -- we're exhausting stack memory when we try to allocate space for our local variables when we enter that function. Maybe there's something we can do to make that function a little cheaper in terms of stack-space-usage? At first glance, it looks like the heavyweight things there are: * `BuildTextRunsScanner scanner` which brings along [some `AutoTArray` instances](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1220-1222) which each reserve some stack space. (on the order of 100 pointers worth in total, I think? Three arrays with size 10, 50, and 10, where the first array stores pointer-pairs, and the last two arrays store individual pointers.) * Another `AutoTArray<char16_t, BIG_TEXT_NODE_SIZE> buffer;` https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrame.cpp#1590 Note that `BIG_TEXT_NODE_SIZE` is 4096, [defined here](https://searchfox.org/mozilla-central/rev/76ccfc801e6b736c844cde3fddeab7a748fc8515/layout/generic/nsTextFrameUtils.h#22), which goes back to bug 333659 in 2007 in [this commit](https://searchfox.org/mozilla-central/commit/e6bad38abe779bd329f48c52ab90fbae7b80bc03). 4096 feels quite large... That means this one AutoTArray uses at least 8KB of stack space (`uint16_t` is 2 bytes, and we're storing 4096 2-byte values, which is 8192 i.e. 8KB). That feels substantial. I wonder how often we actually grow to use all 4096 entries there, and if we could start lower and failing over to heap allocation when we do need the space. jfkthame, do you think we could change our AutoTArray usage there (and maybe BIG_TEXT_NODE_SIZE in general) to be more conservative of stack space, to avoid triggering stack overflows when entering this function?