On 06/27/2013 04:33 AM, Till Schneidereit wrote: > Thanks for bringing this up. I agree that we should do something about > this, and if only for testing purposes. I would tend to favor > > g) Add a command line argument to set the stack quota to the lowest any of > our platforms support. > > That way, you can be sure that your script really does run on all > platforms. (Well, at least it won't over-recurse unexpectedly.) > > @terrence, you worked on bug > 803182<https://bugzilla.mozilla.org/show_bug.cgi?id=803182>, > maybe you can comment on what's best here? > > As an aside, I'm surprised the linux opt builds have half the stack sizes > the debug ones do.
Stack frames in debug builds are considerably larger: more than 8x in the one frame I measured. > On Thu, Jun 27, 2013 at 4:06 AM, Andrew Sutherland < > asutherl...@asutherland.org> wrote: > >> For B2G's gaia repository we are currently using xpcshell[1] as our >> command line JS runner. I was noticing some horrible inconsistencies in >> terms of blowing the JS stack when we were trying to use the esprima JS >> parser[2] that varied by the platform and build type. >> >> The nutshell is that the #defines at http://dxr.mozilla.org/** >> mozilla-central/source/js/**xpconnect/src/XPCJSRuntime.**cpp#l2687<http://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#l2687>net >> us the following JS stack limits. (These are the limits when the JS >> engine starts throwing "InternalError: too much recursion" and are somewhat >> separate from actual native stack limits.) These problems are present in all of our configurations. If you are going to work on this, please make sure and apply your efforts to the browser and JS shell as well. >> linux (32 bit, non-debug): 512 KiB >> windows (all builds): 900 KiB [3] >From what I understand, windows doesn't have a red-zone, so overflowing the 1MiB limit will actually segfault. When I tested, the TBPL run did indeed crash at an over-recursion test if I set the limit on windows to 1MiB. We depend on the stack usage between JS_CHECK_RECURSION calls to be less than 100KiB. My attempt to increase our stack size on windows to help increase our manual red-zone got pushback because it would have increased the size of crashdump uploads and the crashdump database. >> linux (32 bit, debug): 1 MiB >> linux (64 bit, non-debug): 1 MiB >> linux (64-bit, debug): 2 MiB >> OS X (all): 7 MiB >> >> >> For gaia's purposes, this inconsistency is not great. How should we >> resolve this? >> >> a) Make xpcshell try and pick more consistent values itself >> >> b) Make xpcshell take a command line argument and call >> JS_SetNativeStackQuota plus doing whatever it needs to back that up with an >> appropriate platform stack (possibly by re-exec()ing). (Similar to node.js >> supporting --stack_size which defaults to 984 for me right now.) >> >> c) Change xpconnect's hard-coded defaults >> >> d) Change xpconnect to use jsnativestack.cpp's ability to tell us what the >> platform stack size actually is and/or nsThread's knowledge of the stack >> size it was created with. So on linux we'd use whatever 'ulimit -s' is >> telling us to do, etc. This seems to me to be the most elegant solution, and it was what I was working towards. Given, however, that I was getting non-zero pushback for my tweaking, I decided to spend my time on higher impact items. Maybe with Gaia hitting this, now would be a more auspicious time to fix this wart. >> e) Don't use xpcshell for that! Are you crazy?! Xpcshell is an excellent idea, however, it is not, from what I understand, terribly well maintained. If you are only running JS code and don't need all of the other things that xpcshell offers, you would probably be better off using the JS shell. >> f) Other >> >> Thanks, >> Andrew Feel free to ping me in #jsapi if you have any questions. Good luck, Terrence >> 1: Although in the future this might end up just being any xulrunner >> "-app" capable build. >> 2: Since the esprima JS parser produces a parse-tree that's supposed to >> confirm to what SpiderMonkey's Reflect API produces, we do have a >> work-around, but I expect this stack issue to come up again in the future. >> 3: The windows limit could be higher by its current rationale; >> https://bugzilla.mozilla.org/**show_bug.cgi?id=582910<https://bugzilla.mozilla.org/show_bug.cgi?id=582910>increased >> the windows stack to 2 MiB from 1MiB. >> ______________________________**_________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform> >> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
