Bugzilla

To me these are crashes that could appear when a first background hang is detected but we are in a low memory condition.

The background hang monitor thread has 256KB of reserved stack space, but only a few are committed before the first hang is detected. Then, when a first hang is detected, `__chkstk` tries to commit 18600 bytes of stack, which are needed mostly to store the 2 * 1024 pointers in the [`NativeStack nativeStack`](https://searchfox.org/mozilla-central/source/tools/profiler/core/platform.cpp#6901) stack variable.

These crashes may be favored by [the weird trick](https://hacks.mozilla.org/2022/11/improving-firefox-stability-with-this-one-weird-trick/) (bug 1716727), which, by introducing artificial delays when we are in a low memory condition instead of crashes, could favor the trigger of background hang detection while we are in a low memory condition.

We could try to avoid these crashes by pre-committing the required 18600 bytes of stack when the thread is created, unless we have a better idea?

To me these are crashes that could appear when a first background hang is detected but we are in a low memory condition.

The background hang monitor thread has 256KB of reserved stack space, but only a few are committed before the first hang is detected. Then, when a first hang is detected, `__chkstk` tries to commit 18600 bytes of stack, which are needed mostly to store the 2 * 1024 pointers in the [`NativeStack nativeStack`](https://searchfox.org/mozilla-central/source/tools/profiler/core/platform.cpp#6901) stack variable.

These crashes may be favored by [the weird trick](https://hacks.mozilla.org/2022/11/improving-firefox-stability-with-this-one-weird-trick/) (bug 1716727), which, by introducing artificial delays when we are in a low memory condition instead of crashes, could favor triggering background hang detection while we are in a low memory condition.

We could try to avoid these crashes by pre-committing the required 18600 bytes of stack when the thread is created, unless we have a better idea?

To me these are crashes that could appear when a first background hang is detected but we are in a low memory condition.

The background hang monitor thread has 256KB of reserved stack space, but only a few are committed before the first hang is detected. Then, when a first hang is detected, `__chkstk` tries to commit 18600 bytes of stack, which are needed mostly to store the 2 * 1024 pointers in the [`NativeStack nativeStack`](https://searchfox.org/mozilla-central/source/tools/profiler/core/platform.cpp#6901) stack variable.

These crashes may be favored by [the weird trick](https://hacks.mozilla.org/2022/11/improving-firefox-stability-with-this-one-weird-trick/) (bug 1716727), which, by introducing artificial delays when we are in a low memory condition instead of crashes, could favor triggering background hang detection while we are in a low memory condition.

We could try to avoid these crashes by pre-committing the required 18600 bytes of stack when the thread is created, unless we have a better idea? (pre-allocating the `nativeStack` in heap could also be a cleaner way to achieve the same thing)

To me these are crashes that could appear when a first background hang is detected but we are in a low memory condition.

The background hang monitor thread has 256KB of reserved stack space, but only a few are committed before the first hang is detected. Then, when a first hang is detected, `__chkstk` tries to commit 18600 bytes of stack, which are needed mostly to store the 2 * 1024 pointers in the [`NativeStack nativeStack`](https://searchfox.org/mozilla-central/source/tools/profiler/core/platform.cpp#6901) stack variable.

These crashes may be favored by [the weird trick](https://hacks.mozilla.org/2022/11/improving-firefox-stability-with-this-one-weird-trick/) (bug 1716727), which, by introducing artificial delays when we are in a low memory condition instead of crashes, could favor triggering background hang detection while we are in a low memory condition.

We could try to avoid these crashes by pre-committing the required 18600 bytes of stack when the thread is created, unless we have a better idea? (pre-allocating the `nativeStack` variable in heap could also be a cleaner way to achieve the same thing)

To me these are crashes that could appear when a first background hang is detected but we are in a low memory condition.

The background hang monitor thread has 256KB of reserved stack space, but only a few are committed before the first hang is detected. Then, when a first hang is detected, `__chkstk` tries to commit 18600 bytes of stack, which are needed mostly to store the 2 * 1024 pointers in the [`NativeStack nativeStack`](https://searchfox.org/mozilla-central/source/tools/profiler/core/platform.cpp#6901) stack variable.

These crashes may be favored by [the weird trick](https://hacks.mozilla.org/2022/11/improving-firefox-stability-with-this-one-weird-trick/) (bug 1716727), which, by introducing artificial delays when we are in a low memory condition instead of crashes, could favor triggering background hang detection while we are in a low memory condition.

We could try to avoid these crashes by pre-committing the required 18600 bytes of stack when the thread is created, unless we have a better idea? (pre-allocating the `nativeStack` variable could also be a cleaner way to achieve the same thing)

To me these are crashes that could appear when a first background hang is detected but we are in a low memory condition.

The background hang monitor thread has 256KB of reserved stack space, but only a few are committed before the first hang is detected. Then, when a first hang is detected, `__chkstk` tries to commit 18600 bytes of stack, which are needed mostly to store the 2 * 1024 pointers in the [`NativeStack nativeStack`](https://searchfox.org/mozilla-central/source/tools/profiler/core/platform.cpp#6901) stack variable.

These crashes may be favored by [the weird trick](https://hacks.mozilla.org/2022/11/improving-firefox-stability-with-this-one-weird-trick/) (bug 1716727), which, by introducing artificial delays when we are in a low memory condition instead of crashes, could favor triggering background hang detection while we are in a low memory condition.

We could try to avoid these crashes by pre-committing the required 18600 bytes of stack when the thread is created, unless we have a better idea? (pre-allocating the `nativeStack` variable in heap could also be a cleaner way to achieve the same thing)