167934 2017-02-07 07:12:16 -0800 Rethrowing error resets stack trace making debugging hard 2017-09-14 22:39:48 -0700 1 1 1 Unclassified WebKit JavaScriptCore Safari 10 All All RESOLVED DUPLICATE 174380 InRadar P2 Normal --- 174380 1 malte saam caitp dvoytenko fpizlo fred.wang saam webkit-bug-importer oldest_to_newest 1273981 0 malte 2017-02-07 07:12:16 -0800 In JavaScript it is common to rethrow errors when they cannot immediately be handled. Here is some example code: try { mayThrow(); } catch (e) { if (e.message == 'something I can handle') { handleError(e); } else { throw e; } } When executed in JavaScriptCore the error object created in the try block gets a new stack trace when it is rethrown. While there are situations when that might be desirable in the vast majority of cases it is not. Especially in this common pattern: try { mayThrow(); } catch (e) { // Don't interrupt execution flow, but do report error. setTimeout(function() { throw e; }); } Java solves this my making stack traces a linked list of places an exception haa been thrown. Since this is not available in JS, one must choose, and choosing the original location is better in the vast majority of cases. Here is a full repro case: http://output.jsbin.com/lufeqe/quiet Compare the console output between V8 and JavaScriptCore. In V8 it is immediately obvious what happened, while JSC provides no useful information for 2 of the 3 errors. 1274664 1 webkit-bug-importer 2017-02-08 17:21:52 -0800 <rdar://problem/30433531> 1325568 2 fred.wang 2017-07-05 08:11:57 -0700 Testing in Firefox, it seems that SpiderMonkey behaves the same as V8. 1325958 3 314702 fred.wang 2017-07-06 00:26:18 -0700 Created attachment 314702 Testcase (console output) 1325959 4 314703 fred.wang 2017-07-06 00:27:19 -0700 Created attachment 314703 Testcase (print stack trace) 1325960 5 314704 fred.wang 2017-07-06 00:27:47 -0700 Created attachment 314704 Testcase (to run in JSC) 1325963 6 fred.wang 2017-07-06 00:38:07 -0700 The stack trace of attachment 314704 seems correct using JSC (TOT): WebKitBuild/Release/bin/jsc -e "`curl https://bug-167934-attachments.webkit.org/attachment.cgi?id=314704`" Stack of an exception: throwError@[Command Line]:2:18 caller@[Command Line]:6:13 invokee@[Command Line]:10:9 root@[Command Line]:14:10 global code@[Command Line]:19:7 Stack of a rethrown exception: throwError@[Command Line]:2:18 caller@[Command Line]:6:13 invokee@[Command Line]:10:9 root@[Command Line]:14:10 global code@[Command Line]:28:9 Similarly, opening attachment 314703 in MiniBrowser (TOT) the exception stack trace are correctly printed in the textarea. Attachment 314702 is similar to the original test case (i.e. using separate script tags and checking the console) and indeed shows that the stack incorrect for the rethrown exception. Again, using TOT. 1325964 7 314706 fred.wang 2017-07-06 00:42:11 -0700 Created attachment 314706 Testcase (console output, only the rethrown error) This is a simplified version of attachment 314702 with only the rethrown exception and using only one <script> tag. It still exhibits the issue in MiniBrowser. 1327330 8 caitp 2017-07-10 19:39:09 -0700 Quick design for a fix: 1. In `JSC::Exception::create(VM&, JSValue);`: If thrownValue inherits ErrorInstance, and does not have a captured stacktrace already, store the captured stacktrace on it (private symbol, or member of ErrorInstance). 2. In createScriptCallStackFromException() (ScriptCallStackFactory.cpp): If exception->value() is an instance of ErrorInstance, load the stacktrace symbol, and use it to assemble the ScriptCallStack Console API adds the message like usual, and it should include the originally thrown stacktrace (provided the thrown object inherits(ErrorInstance::class())). --- This seems to more or less match the behaviour of Chromium, so although there are caveats, I don't know that anyone has found that behaviour problematic in Chromium yet. 1327671 9 caitp 2017-07-11 13:10:24 -0700 Prototype patch in bug 174380 1327929 10 fred.wang 2017-07-11 23:41:10 -0700 (In reply to Frédéric Wang (:fredw) from comment #6) > The stack trace of attachment 314704 [details] seems correct using JSC (TOT): > ... > Similarly, opening attachment 314703 [details] in MiniBrowser (TOT) the > exception stack trace are correctly printed in the textarea. Just to follow-up here. These test cases print Error.stack which is indeed the one requested in this bug report. Hence they can not exhibit the issue, contrary to the test cases requiring the use of the Web Inspector. It turns out that the Web Inspector prints the Exception object's stack (and does it on purpose), which indicates the location of when that exception was last (re)thrown and hence does not correspond to the behavior Chromium or Firefox's console. For details and ideas see the discussion on bug 174380. 1327930 11 314703 fred.wang 2017-07-11 23:42:06 -0700 Comment on attachment 314703 Testcase (print stack trace) This testcase won't allow to reproduce the issue per comment 10. 1327931 12 314704 fred.wang 2017-07-11 23:42:18 -0700 Comment on attachment 314704 Testcase (to run in JSC) This testcase won't allow to reproduce the issue per comment 10. 1349178 13 saam 2017-09-14 21:54:03 -0700 Looking into this now 1349185 14 saam 2017-09-14 22:38:23 -0700 It seems like all action is in https://bugs.webkit.org/show_bug.cgi?id=174380 Do we need two bugs for the same thing? 1349186 15 saam 2017-09-14 22:39:48 -0700 *** This bug has been marked as a duplicate of bug 174380 *** 314702 2017-07-06 00:26:18 -0700 2017-07-06 00:26:18 -0700 Testcase (console output) 167934-console.html text/html 430 fred.wang PCFET0NUWVBFIGh0bWw+CjxoMT5PcGVuIGNvbnNvbGUgYW5kIGNoZWNrIHRoZSBzdGFjayB0cmFj ZXMuIEFsbCBzaG91bGQgcG9pbnQgdG8gdGhlIHRocm93RXJyb3IgZnVuY3Rpb24gb2YgaGF2aW5n IHRocm93biBhbiBlcnJvcjwvaDE+CjxzY3JpcHQ+CmZ1bmN0aW9uIHRocm93RXJyb3IoKSB7CiAg dGhyb3cgbmV3IEVycm9yKCdJcyBteSBzdGFjayB0cmFjZSBoZWxwZnVsPycpOwp9CgpmdW5jdGlv biBjYWxsZXIoKSB7CiAgdGhyb3dFcnJvcigpOwp9CgpmdW5jdGlvbiBpbnZva2VlKCkgewogIGNh bGxlcigpOwp9CgpmdW5jdGlvbiByb290KCkgewogIGludm9rZWUoKTsKfQo8L3NjcmlwdD4KPHNj cmlwdD4KICByb290KCk7Cjwvc2NyaXB0Pgo8c2NyaXB0Pgp0cnkgewogIHJvb3QoKTsKfSBjYXRj aCAoZSkgewogIHRocm93IGU7Cn0KPC9zY3JpcHQ+Cg== 314703 2017-07-06 00:27:19 -0700 2017-07-11 23:42:06 -0700 Testcase (print stack trace) 167934.html text/html 588 fred.wang PCFET0NUWVBFIGh0bWw+Cjx0ZXh0YXJlYSBjb2xzPSI4MCIgcm93cz0iMjAiPjwvdGV4dGFyZWE+ CjxzY3JpcHQ+CmZ1bmN0aW9uIHRocm93RXJyb3IoKSB7CiAgdGhyb3cgbmV3IEVycm9yKCdJcyBt eSBzdGFjayB0cmFjZSBoZWxwZnVsPycpOwp9CgpmdW5jdGlvbiBjYWxsZXIoKSB7CiAgdGhyb3dF cnJvcigpOwp9CgpmdW5jdGlvbiBpbnZva2VlKCkgewogIGNhbGxlcigpOwp9CgpmdW5jdGlvbiBy b290KCkgewogIGludm9rZWUoKTsKfQoKZnVuY3Rpb24gcHJpbnQodGV4dCkgewogIGRvY3VtZW50 LmdldEVsZW1lbnRzQnlUYWdOYW1lKCd0ZXh0YXJlYScpWzBdLnZhbHVlICs9ICh0ZXh0IHx8ICcn KSArICdcbic7Cn0KCnByaW50KCdTdGFjayBvZiBhbiBleGNlcHRpb246JykKdHJ5IHsKICByb290 KCk7Cn0gY2F0Y2goZSkgewogIHByaW50KGUuc3RhY2spOwp9CnByaW50KCkKCnByaW50KCdTdGFj ayBvZiBhIHJldGhyb3duIGV4Y2VwdGlvbjonKQp0cnkgewogIHRyeSB7CiAgICByb290KCk7CiAg fSBjYXRjaCAoZSkgewogICAgdGhyb3cgZTsKICB9Cn0gY2F0Y2ggKGUpIHsKICBwcmludChlLnN0 YWNrKTsKfQo8L3NjcmlwdD4K 314704 2017-07-06 00:27:47 -0700 2017-07-11 23:42:18 -0700 Testcase (to run in JSC) 167934.js application/javascript 408 fred.wang ZnVuY3Rpb24gdGhyb3dFcnJvcigpIHsKICB0aHJvdyBuZXcgRXJyb3IoJ0lzIG15IHN0YWNrIHRy YWNlIGhlbHBmdWw/Jyk7Cn0KCmZ1bmN0aW9uIGNhbGxlcigpIHsKICB0aHJvd0Vycm9yKCk7Cn0K CmZ1bmN0aW9uIGludm9rZWUoKSB7CiAgY2FsbGVyKCk7Cn0KCmZ1bmN0aW9uIHJvb3QoKSB7CiAg aW52b2tlZSgpOwp9CgpwcmludCgnU3RhY2sgb2YgYW4gZXhjZXB0aW9uOicpCnRyeSB7CiAgcm9v dCgpOwp9IGNhdGNoKGUpIHsKICBwcmludChlLnN0YWNrKTsKfQpwcmludCgpCgpwcmludCgnU3Rh Y2sgb2YgYSByZXRocm93biBleGNlcHRpb246JykKdHJ5IHsKICB0cnkgewogICAgcm9vdCgpOwog IH0gY2F0Y2ggKGUpIHsKICAgIHRocm93IGU7CiAgfQp9IGNhdGNoIChlKSB7CiAgcHJpbnQoZS5z dGFjayk7Cn0K 314706 2017-07-06 00:42:11 -0700 2017-07-06 00:42:11 -0700 Testcase (console output, only the rethrown error) 167934-console-rethrown.html text/html 312 fred.wang PCFET0NUWVBFIGh0bWw+CjxoMT5PcGVuIGNvbnNvbGUgYW5kIGNoZWNrIHRoZSBzdGFjayB0cmFj ZS48L2gxPgo8c2NyaXB0PgpmdW5jdGlvbiB0aHJvd0Vycm9yKCkgewogIHRocm93IG5ldyBFcnJv cignSXMgbXkgc3RhY2sgdHJhY2UgaGVscGZ1bD8nKTsKfQoKZnVuY3Rpb24gY2FsbGVyKCkgewog IHRocm93RXJyb3IoKTsKfQoKZnVuY3Rpb24gaW52b2tlZSgpIHsKICBjYWxsZXIoKTsKfQoKZnVu Y3Rpb24gcm9vdCgpIHsKICBpbnZva2VlKCk7Cn0KCnRyeSB7CiAgcm9vdCgpOwp9IGNhdGNoIChl KSB7CiAgdGhyb3cgZTsKfQo8L3NjcmlwdD4K