Closed Bug 237006 Opened 17 years ago Closed 11 years ago
API for address of first stack variable to prevent Mozilla crashes
Actually, what's more important then the start of the stack is the size of the stack. Also some NSPR define for getting the direction the stack grows would be nice, although JS does supply us with that already.
(In reply to comment #1) > Actually, what's more important then the start of the stack is the size of the > stack. Also some NSPR define for getting the direction the stack grows would be > nice, although JS does supply us with that already. JS needs to know the maximum (or minimum if stack growth down) allowed address to detect run away recursion so if the stack size information is available it would allow to calculate the limit properly. The problem is that it seems that this information is extremely platform dependent and for over a year nobody suggested a code that works reliably. On the other hand a hard coded limit like no more then 500K of stack space covers most of interested cases and would prevent one-line scripts to crash Mozilla or any other JS embedding that allows to execute untrusted scripts. Now for the limit to work reliably one would need to know initial stack address but that is trivial to expose from NSPR without any platform-specific code as it is just an address of first variable in NSPR thread callback. It is this practical considerations that caused me to limit the scope of this enhancement.
See bug 516832 comment 34. /be
This is based on Gregor's patch from the bug 516832.
Assignee: wtc → igor
Attachment #441340 - Flags: review?(anygregor)
Product: NSPR → Core
QA Contact: nspr → general
Version: other → unspecified
Attachment #441340 - Flags: review?(anygregor) → review+
v1 could not compile on Mac due to the bug 564414. So while fixing the bug there I also added better comments here.
(In reply to comment #7) > 42271 INFO TEST-PASS | > /tests/content/html/content/test/test_formSubmission.html | Correct number of > items > Assertion failure: cx->requestDepth > 0, at It is hard to see what in the patch could have caused that as it does not change anything in the request-related code.
(In reply to comment #7) > Assertion failure: cx->requestDepth > 0, at > /builds/slave/tracemonkey-linux-debug/build/js/src/jsgc.cpp:2336 The assert is in the js_TriggerGC call. Most likely that comes from JSContext::checkMallocGCPressure called from JSContext::malloc. Which points that the assertion is bogus and should be replaced by the real check - JSContext::malloc could be called outside the request.
Want to file a bug for that?
Never mind you just did. Bug 566949.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.