13

Here is the situation: A complex web app is not working, and it is possible to produce undesired behavior consistently. The cause of the problem is not known.

Proposal: Trace the execution paths of all javascript code. Essentially, produce two monstrous logs which can then be fed into a diff algorithm to determine where the behavior related to the bug begins to diverge (as the cause is not apparent from application behavior, and both comprehending and obtaining a copy of the actual JS code being run is difficult, due to the many pages that must be switched to and copied out from the web inspector. Making it difficult is the fact that all pages are dynamically spliced together with Perl code, where significant portions of JS code exist only as (dynamic...) Perl strings).

The Web Inspector in Chrome does not have an option that I know about for logging an execution trace. Basically what I would like is a log of every line of JS that is executed, in the order that they are executed. I don't see this as being a difficult thing to obtain given that the JS VM is single-threaded. The problem is simply that the existing user-facing tools are not designed for quite this much hardcore debugging. If we look at the Profiler in the Dev Tools, it's clearly capable of the kind of instrumentation that I need, but it is fundamentally designed to do profiling instead of tracing.

How can I get started with this? Is there some way I can build Chrome from source, where I can

  • switch off JIT in V8?
  • log every single javascript expression evaluated by V8 to a file

I have zero experience with the development side of Chrome. So e.g. links to dev-builds/branches/versions/distros of Chrome/Chromium/Canary (what's the difference?) are welcome.

At this point it appears that instrumenting the browser with powerful js tracing is still likely to be easier than redesigning the buggy app. The architecture of the page is a disaster, but the functionality is complex, and it almost fully works. I just have to find the one missing piece.

Alternatively, if tools of this sort already exist, what are some other keywords I can search for them with? "Code Tracing" is pretty much the only thing I can come up with.

I tested dynaTrace, which was a happy coincidence as our app supports IE (indeed Chrome support just came out of beta), but this does not produce a text dump, it basically produces a massive Win32 UI expando-tree, which is impossible to diff. This makes me really sad because I know how much more difficult it was to make the representation of the trace show up that way, and yet it turns out being almost utterly useless. Who's going to scroll up and down that tree view and see anything really useful in it, in anything other than a toy example of a web app?

Steven Lu
  • 41,389
  • 58
  • 210
  • 364
  • I know this is not what you're asking for, but did you try setting breakpoints in the debugger and manually following the execution path? – bfavaretto Jul 19 '13 at 17:55
  • I'm not about to sit there for two days clicking on 180,000 lines of JS code to set breakpoints on them. For one, I doubt my 8GB of RAM is enough. I don't believe the Inspector UI is scalable enough for this. It should be done at the VM level. – Steven Lu Jul 19 '13 at 18:05
  • 1
    you can compile V8 yourself, and enable all sort of debugging output dumping from stack traces to the actual assembly code V8 generates from JS. – dandavis Jul 19 '13 at 18:18
  • you can also iterate to find all functions, and re-define them with a logging wrapper that then returns fn.apply(this,arguments), which SHOULD be transparent to your code. – dandavis Jul 19 '13 at 18:20
  • @dandavis Interesting idea. Not sure if that's enough granularity. thanks – Steven Lu Jul 19 '13 at 18:39
  • @dandavis It's good to know V8 can do that. Have you any tips for how to "drop in" a V8 that is instrumented like that into a Chrome that I can run? – Steven Lu Jul 19 '13 at 19:16
  • no, you have to compile yourself AFAIK. – dandavis Jul 19 '13 at 20:21
  • When you say *"it almost fully works"* you really mean **it does not work at all**. – Bart Jan 27 '14 at 20:22
  • Do you have a last known working state? Maybe you could diff to that. – Bart Jan 27 '14 at 22:55
  • I have the same need. Do you have found a solution ? – asicfr Jun 13 '17 at 14:01

3 Answers3

2

I would suggest a divide and conquer strategy, first via logging, and second via code. Wrap suspect methods of the code with console logging in and out events and when the bug occurs hopefully it is occurring between or after some event. If event logging will not shed light, bring parts of the code into a new page/app. Divide and conquer will find when the error starts occurring.

ledlogic
  • 774
  • 1
  • 9
  • 19
2

If you are developing a big web app, it is always good to follow a test driven strategy for the coding part of it. Using just a few tips allows you to make a simple unit testing script (using QUnit) to test pretty much all aspects of your app. Here are some potential errors and some ways of solving them.

  1. Make yourself handlers to register long living Objects and a handler to close them the safe way. If the safe way does not succeed then it is the management of the Object itself failing. One example would be Backbone zombie views. Either the view has bad code in the close section, the parent close is not hooked or an infinite loop happened. Testing all view events is also good, although tedious.

  2. By putting all the code for data fetching inside a certain module (I often use a bunch of Backbone.Model objects for each table/document in my DB) and handlers for each using a reqres pattern, you can test them 1 by 1 to see if they all fetch and save correctly.

  3. If complex computation is needed, abstract it in a function or module so that it can be easily tested with known data.

  4. If your app uses data binding, a good policy is to have a JSON schema for all data to be tested against your views containing your bindings. Check against the schema all the data required. This is applied to your Backbone.Model also.

  5. Using a good IDE also helps. PyCharm (if you use Python for backend) or WebStorm are extremely good for testing and developing JavaScript/CoffeeScript. You can breakpoint and study your code at specific locations, inside your browser! Also it runs your code for auto-completion and you can see some of the errors that way.

  6. I just cannot encourage enough the use of modules in your code. Although there is no JavaScript official way of doing it (next ECMAScript draft has it), you can still use good libraries for it. Good ones are: RequireJS, CommonJS or Marionette.Module (if you use Marionette as your framework). I think Ember/AngularJS also offers this kind of functionality but I did not work with them personally so I am not sure.

This might not give you an immediate solution to your problem and I don't think (IMO) there is an easy one either. My focus was to show you ways to develop so that errors can be easily spotted and countered, and all of it (depending on your Unit Testing) during development phase. Errors will always happen, as much as our programmer ego wants us to believe the contrary. Hope I helped :)

AlexandruB
  • 678
  • 3
  • 15
  • This is good advice. Also use explicitly named functions as handlers since they are easier to find/track/debug and provide more context then anonymous ones. – Bart Jan 27 '14 at 22:58
  • Yep, this is all the stuff that this problem would have been avoided with. – Steven Lu Jan 27 '14 at 23:19
1

So it seems you're in the realm of weird already, so I'm thinking of a weird solution. I know nothing about the backend of chrome myself so we're in the same boat, but if you're feeling bold here's an idea. Maybe you could find/replace every newline in your javascript files with a piece of code that logs either to a global string or to the console a) what file you're in, b) the contents of "this" or something useful to you, and maybe even c) the time. This would at least get you started. Make sure it's wrapped in something distinct so you can just as easily remove it.

matty-d
  • 2,623
  • 3
  • 18
  • 21
  • Yup, I've certainly thought about this, but the problem would then expand to require dynamically parsing millions of lines of Perl code (for which you may be aware that parsing is undecidable) to instrument all the javascript contained within in Perl strings. This is clearly not feasible. The best I can attempt is to instrument Apache to do this, so every bit of JS it sends out is instrumented thusly. However this only reduces it to an HTML parsing problem rather than a Perl parsing problem. – Steven Lu Jul 19 '13 at 18:06
  • Ah... I think I understand your problem more fully now. And it seems like what you want would be a hook into chrome somehow. Best of luck sir! – matty-d Jul 19 '13 at 18:14