зеркало из https://github.com/mozilla/gecko-dev.git
63557d95ad
The native allocations feature added stackwalking that can happen anywhere that memory is allocated. This means that stackwalking happens in places where the execution already has a very large execution stack. Stackwalking was relying on stack-allocated buffers used for merging stacks. This was taking up 64kb of stack space. On Linux, this was causing a stack overflow, as there is only 256kb of stack space. I encountered a crash while using GDB. Using pointer arithmetic, I determined that the stack size before stack walking was around 20kb, and during stackwalking, we overflowed the stack (>256kb). The largest culprit was the JS::ProfilingFrameIterator::Frame jsFrames[MAX_JS_FRAMES]. In addition, Bug 1468789 added another member to the Frame class, also increasing the size of the stack allocation. I changed the implementation to allocate some memory on the CorePS class, and share that with every stackwalk that happens. I tested this loading a large news site, and didn't get any crashes. Differential Revision: https://phabricator.services.mozilla.com/D54072 --HG-- extra : moz-landing-system : lando |
||
|---|---|---|
| .. | ||
| bloatview | ||
| browsertime | ||
| clang-tidy | ||
| code-coverage | ||
| compare-locales | ||
| coverity | ||
| crashreporter | ||
| docs | ||
| fuzzing | ||
| infer | ||
| jprof | ||
| leak-gauge | ||
| lint | ||
| performance | ||
| power | ||
| profiler | ||
| quitter | ||
| rb | ||
| rewriting | ||
| tryselect | ||
| update-packaging | ||
| update-verify | ||
| vcs | ||
| mach_commands.py | ||
| moz.build | ||