[+v8-users; chromium-discuss to BCC] Hi,
On Mon, Aug 5, 2013 at 2:50 PM, Elias Weingärtner < [email protected]> wrote: > Folks, > > we have recently run into troubles, because one of our Web-based software > products crashes the current stable of Chrome, more precicely V8.It is > possible to track down the source of the crash (a chrome tab hangs > entirely) > Does the tab hang, or does it crash? When you enable crash reporting ("Automatically send usage statistics and crash reports to Google" in Settings -> Show advanced settings) and then reproduce the problem, do you get a crash ID in chrome://crashes? > to V8 using tracing JS-PREFS. > I have no idea what that means. > More specifically, we observe that V8 does not complete the last logging > statement and thus attribute the problem to a bug/issue in V8 triggered by > our Javascript conglomerate. > Well, it could be a bug in V8, but it could also be an endless loop or an uncaught exception or something else in your code... Have you checked the JS console in Chrome's Developer Tools? > Due to the complexity of V8 and the non-deterministic nature of the > observed "tab freez", we have not further tried to track down the problem > what exactly (call sequences, V8 settings, concurrencies) makes V8 stumble. > In addtion, we cannot reproduce the bug in recent Dev and Nightly Builds of > Chrome/Canary anymore and hence assume that the root issue has been fixed > in the meanwhile. > > Despite the assumption that we won't run into this issue with Dev becoming > stable anymore, we are interested in developing a workaround so that our > Javascript conglomerate (generated mostly by GWT) does not trigger the > V8 failure anymore. For this purpose, we look for answers/comments/ideas to > the following questions: > > 1) What call sequences in Javascript, concurrent activities in V8, > environment settings etc. make V8 fail? > V8 is under active development. There are no known ways how to cause failures in V8. When we learn of one, it's a bug, and we'll fix it as soon as we can (including back-merging the patch to Chrome Stable if necessary/feasible). In order to do so, we'd need to monitor the Javascript processing at the > Broser down to the JIT compilation steps. Any suggestions how to do this? > You can trace JIT code generation by running Chrome with --js-flags="--print-code --print-opt-code --code-comments", but that'll spit out a huge amount of assembly code and will probably not be helpful. (On Linux, the output will go directly to stdout; on Windows, it will be saved to the file chrome_debug.log in Chrome's user data directory (in the parent directory of Default/); I'm not sure about Mac.) Your best bet is probably to try to reduce the input program to the smallest possible snippet that triggers the problem. Just keep taking away parts of it until the failure no longer happens. 2) We have observed this freezing in the current stable (Version > 28.0.1500.95) and probably as early as .27 - Are there common patterns or > GWT uses that are known to cause V8 crashes? Maybe there are already > workarounds... > Nope, there are no known patterns that must be avoided, and hence no known workarounds. Do you have a test case you can share that we could take a look at? The smaller it is and the easier and more reliable to reproduce, the better. Feel free to send it just to me if you don't want to share it on a public mailing list. Regards, Jakob > Best Regards, > Elias Weingärtner, Software Architect > Haufe-Lexware, Germany > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
