Currently, there’s no way for the developer to change this. We can certainly make it an option that the Inspector can change if desired.
Mark > On Mar 28, 2017, at 7:35 PM, Matt Baker <matthew_a_ba...@apple.com> wrote: > >> On Mar 28, 2017, at 4:23 PM, Geoffrey Garen <gga...@apple.com >> <mailto:gga...@apple.com>> wrote: >> >> Does the separate exceptionStackTraceLimit mean that if a developer gets a >> truncated stack trace in the Web Inspector, there’s no way for the developer >> to remedy that? Is that what other browsers’ developer tools do? > > FireFox and Chrome show console entires with exception stack traces with 128 > and 200 frames (respectively). > >> >> Geoff >> >>> On Mar 28, 2017, at 4:09 PM, Mark Lam <mark....@apple.com >>> <mailto:mark....@apple.com>> wrote: >>> >>> To follow up, I’ve implemented the change in r214289: <http://trac.webkit >>> <http://trac.webkit/>.org/r214289>. Error.stackTraceLimit is now 100. I >>> also implemented a separate exceptionStackTraceLimit for stack traces >>> captured at the time of throwing a value (not to be confused with >>> Error.stack which is captured at the time of instantiation of the Error >>> object). exceptionStackTraceLimit is also limited to 100 by default. >>> >>> Mark >>> >>> >>>> On Mar 17, 2017, at 1:04 PM, Mark Lam <mark....@apple.com >>>> <mailto:mark....@apple.com>> wrote: >>>> >>>> @Geoff, my testing shows that we can do 200 frames and still perform well >>>> (~1 second to console.log Error.stack). Base on what we at present, I >>>> think 100 is a good round number to use as our default stackTraceLimit. >>>> >>>>> On Mar 17, 2017, at 11:40 AM, Maciej Stachowiak <m...@apple.com >>>>> <mailto:m...@apple.com>> wrote: >>>>> >>>>>> >>>>>> On Mar 17, 2017, at 11:09 AM, Mark Lam <mark....@apple.com >>>>>> <mailto:mark....@apple.com>> wrote: >>>>>> >>>>>> Thanks for the reminder to back observations up with data. I was >>>>>> previously running some tests that throws StackOverflowErrors a lot >>>>>> (which tainted my perspective), and I made a hasty conclusion which >>>>>> isn’t good. Anyway, here’s the data using an instrumented VM to take >>>>>> some measurements and a simple test program that recurses forever to >>>>>> throw a StackOverflowError (run on a MacPro): >>>>>> >>>>>> 1. For a release build of jsc shell: >>>>>> Time to capture exception stack = 0.002807 sec >>>>>> Number of stack frames captured = 31722 >>>>>> sizeof StackFrame = 24 >>>>>> total memory consumed = ~761328 bytes. >>>>>> >>>>>> 2. For a debug build of jsc shell: >>>>>> Time to capture exception stack = 0.052107 sec >>>>>> Number of stack frames captured = 31688 >>>>>> sizeof StackFrame = 24 >>>>>> total memory consumed = ~760512 bytes. >>>>>> >>>>>> So, regarding performance, I was wrong. The amount of time taken to >>>>>> capture the entire JS stack each time is insignificant. >>>>>> Regarding memory usage, ~760K is not so good, but maybe it’s acceptable. >>>>>> >>>>>> Comparing browsers with their respective inspectors open: >>>>>> >>>>>> 1. Chrome >>>>>> number of frames captured: 10 >>>>>> length of e.stack string: 824 chars >>>>>> time to console.log e.stack: 0.27 seconds >>>>>> >>>>>> 2. Firefox >>>>>> number of frames captured: 129 >>>>>> length of e.stack string: 8831 chars >>>>>> time to console.log e.stack: 0.93 seconds >>>>>> >>>>>> 3. Safari >>>>>> number of frames captured: 31722 >>>>>> length of e.stack string: 218821 chars >>>>>> time to console.log e.stack: 50.8 seconds >>>>>> >>>>>> 4. Safari (with error.stack shrunk to 201 frames at time of capture to >>>>>> simulate my proposal) >>>>>> number of frames captured: 201 >>>>>> length of e.stack string: 13868 chars >>>>>> time to console.log e.stack: 1 second >>>>>> >>>>>> With my proposal, the experience of printing Error.stack drops from 50.8 >>>>>> seconds to about 1 second. The memory used for capturing the stack also >>>>>> drops from ~760K to 5K. >>>>>> >>>>>> I wasn’t aware of the Error.stackTraceLimit, but that does sound like a >>>>>> better solution than my proposal since it gives developers the ability >>>>>> to capture more stack frames if they need it. Chrome’s default >>>>>> Error.stackTraceLimit appears to be 10. MS appears to support it as >>>>>> well and defaults to 10 >>>>>> (https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript >>>>>> >>>>>> <https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript>). >>>>>> Firefox does now. >>>>> >>>>> Out of curiosity: Why does Firefox capture 129 frames instead of 31722 in >>>>> this case? Do they have a hardcoded limit? >>>> >>>> Actually, my previous frame counts are a bit off. I was using >>>> e.stack.split(/\r\n|\r|\n/).length as the frame count. Below, I just copy >>>> the console.log dump into an editor and take the line count from there as >>>> the frame count instead. The result of that string.split appears to be a >>>> bit off from the actual frames printed by console.log. >>>> >>>> I also modified my recursing test function to console.log the re-entry >>>> count on entry and this is what I saw: >>>> >>>> 1. Chrome >>>> test reported reentry count = 10150 >>>> ....split(…).length = 11 (because Chromes starts e.stack with a line >>>> "RangeError: Maximum call stack size exceeded”) >>>> e.stack lines according to editor = 10 frames >>>> >>>> 2. Firefox >>>> test reported reentry count = 222044 >>>> ....split(…).length = 129 (probably because there’s an extra newline >>>> in there somewhere) >>>> e.stack lines according to editor = 128 frames >>>> >>>> 3. Safari >>>> test reported reentry count = 31701 >>>> ....split(…).length = 31722 (I don’t know why there’s a 21 frame >>>> discrepancy here. I’ll debug this later) >>>> e.stack lines according to editor = ??? frames (WebInspector hangs >>>> every time I try to scroll in it, let alone let me highlight and copy the >>>> stack trace. So I gave up) >>>> >>>> Assuming the test function frame is not significantly different in size >>>> for all browsers, it looks like: >>>> 1. Chrome uses a much smaller stack (about 1/3 of our stack). >>>> 2. Firefox uses a much larger stack (possibly the full machine stack), but >>>> caps its Error.stack to just 128 frames (possibly a hardcoded limit). >>>> >>>> Mark >>>> >>>> >>>>> >>>>> - Maciej >>>>> >>>>>> >>>>>> Does anyone object to us adopting Error.stackTraceLimit and setting the >>>>>> default to 10 to match Chrome? >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>>> On Mar 16, 2017, at 11:29 PM, Geoffrey Garen <gga...@apple.com >>>>>>> <mailto:gga...@apple.com>> wrote: >>>>>>> >>>>>>> Can you be more specific about the motivation here? >>>>>>> >>>>>>> Do we have any motivating examples that will tell us wether time+memory >>>>>>> were unacceptable before this change, or are acceptable after this >>>>>>> change? >>>>>>> >>>>>>> In our motivating examples, does Safari use more time+memory than other >>>>>>> browsers? If so, how large of a stack do other browsers capture? >>>>>>> >>>>>>> We already limit the size of the JavaScript stack to avoid performance >>>>>>> problems like the ones you mention in many other contexts. Why is that >>>>>>> limit not sufficient? >>>>>>> >>>>>>> Did you consider implementing Chrome’s Error.stackTraceLimit behavior? >>>>>>> >>>>>>> Geoff >>>>>>> >>>>>>>> On Mar 16, 2017, at 10:09 PM, Mark Lam <mark....@apple.com >>>>>>>> <mailto:mark....@apple.com>> wrote: >>>>>>>> >>>>>>>> Hi folks, >>>>>>>> >>>>>>>> Currently, if we have an exception stack that is incredibly deep >>>>>>>> (especially for a StackOverflowError), JSC may end up thrashing memory >>>>>>>> just to capture the large stack trace in memory. This is bad for >>>>>>>> many reasons: >>>>>>>> >>>>>>>> 1. the captured stack will take a lot of memory. >>>>>>>> 2. capturing the stack may take a long time (due to memory thrashing) >>>>>>>> and makes for a bad user experience. >>>>>>>> 3. if memory availability is low, capturing such a large stack may >>>>>>>> result in an OutOfMemoryError being thrown in its place. >>>>>>>> The OutOfMemoryError thrown there will also have the same problem >>>>>>>> with capturing such a large stack. >>>>>>>> 4. most of the time, no one will look at the captured Error.stack >>>>>>>> anyway. >>>>>>>> >>>>>>>> Since there isn’t a standard on what we really need to capture for >>>>>>>> Error.stack, I propose that we limit how much stack we capture to a >>>>>>>> practical size. How about an Error.stack that consists of (1) the top >>>>>>>> N frames, (2) an ellipses, and (3) the bottom M frames? If the number >>>>>>>> of frames on the stack at the time of capture is less or equal to >>>>>>>> than N + M frames, then Error.stack will just show the whole stack >>>>>>>> with no ellipses. For example, if N is 4 and M is 2, the captured >>>>>>>> stack will look something like this: >>>>>>>> >>>>>>>> foo10001 >>>>>>>> foo10000 >>>>>>>> foo9999 >>>>>>>> foo9998 >>>>>>>> … >>>>>>>> foo1 >>>>>>>> foo0 >>>>>>>> >>>>>>>> If we pick a sufficient large number for N and M (I suggest 100 each), >>>>>>>> I think this should provide sufficient context for debugging uses of >>>>>>>> Error.stack, while keeping an upper bound on how much memory and time >>>>>>>> we throw at capturing the exception stack. >>>>>>>> >>>>>>>> My plan for implementing this is: >>>>>>>> 1. change Exception::finishCreation() to only capture the N and M >>>>>>>> frames, plus possibly 1 ellipses placeholder in the between them. >>>>>>>> 2. change all clients of Exception::stack() to be able to recognize >>>>>>>> and render the ellipses. >>>>>>>> >>>>>>>> Does anyone object to doing this or have a compelling reason why this >>>>>>>> should not be done? >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> Mark >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> webkit-dev mailing list >>>>>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>>>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> webkit-dev mailing list >>>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>> <https://lists.webkit.org/mailman/listinfo/webkit-dev> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
