summaryrefslogtreecommitdiffstats
path: root/js/src/jsnativestack.cpp
Commit message (Collapse)AuthorAgeLines
* Issue #578: Applications cannot start without /proc (chroot).wolfbeast2018-07-02-3/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UXP uses the current stack frame address and the stack size as a sort of heuristic for various things in the JavaScript engine. The js::GetNativeStackBaseImpl() function is used to get the base stack address (i.e. the address from which the stack grows, so this can be either the first or last memory address of the stack memory space depending on the CPU architecture). On Linux, this function is implemented using the pthreads APIs. For non-main threads, the queried thread info is stored in memory. The main thread does not have this information on hand, so it gets the stack memory range via the /proc/self/maps file (see glibc's pthread_get_attr_np.c). Fortunately (per discussions with the firefox devs in #jsapi) the base address only needs to be approximate. In reality, environment variables, args, and other things are stored in stack space between the end/beginning of the mapped stack memory and the 'top' of the stack space used by stack frames. When using glibc, we can get the top of this usable stack from __libc_stack_end, which is a void* set by glibc during program initialization, avoiding the need to access /proc. Non-main threads still get their stack-base through the usual pthreads APIs. Other libc implementations like musl will fall back to the standard UNIX-like implementation which calls pthread's pthread_attr_getstack() also from the main thread, which may imply /proc access and not work in restricted environments.
* Add m-esr52 at 52.6.0Matt A. Tobin2018-02-02-0/+174