Dealing with Bugs in Other Software

This is a well over due blog post. Honestly, we’ve been so busy with Popcorn Maker it’s been hard to just stop and take sometime to write one of these up 🙂 Anyway, I wanted to talk about one of the things that came along one day out of the blue.

Sometimes there actually isn’t bugs in your code!
We’ve always been striving to make our tests better and it’s an ongoing process. However one day out of the blue we quickly discovered that our tests literally would just stop running in Firefox after the update to version 14. Now our tests load a lot of video; It’s just part of the territory when your library is involved with video on the web it’s just going to happen. Now, recently in Firefox 14 there was a limit placed on the amount threads that can be used to decode media. Combine this with a bug in the code and our test runner would literally just stall in Firefox.

This is obviously a problem and we can’t just ignore the problem and let our tests just “not work” in Firefox until it gets fixed. At this point our tests were all grouped up into single files based on what they were testing. All media module tests were in one single test file, all trackevent test files were grouped together and so on. This meant that we weren’t giving the browser as much time as possible to teardown every single piece of media. In the end what we wound up doing was breaking down every single QUnit qsyncTest block we had into it’s HTML page. This not only means that it’s easier to trace problems with failing/stalling tests but it helps solve our issue of loading too much video too quickly for the browser.

Often one solution creates another problem
As the title suggests, this only opened the door for another problem with our how we load our node server locally. To replace having to use a generic makefile system we use shell.js along with various node modules like CSLINT, JSHINT etc and this allows us to avoid writing annoying makefile code with javascript instead. In particular we use their exec command which allows us to execute typical commands on the command line. For an easy way to start our server we have a shortcut command that changes into the cornfield app’s directory and starts the server.

Now the problem here was another bug that’s present with running shell.js’ exec function asynchronously. Without it our node app would eat a lot of system resources and with it our test runner would cause the server to crash by loading so many resources quickly. If you manually started the app no problems would arrise. Alas, we were blocked by another bug.

However, a clever solution was found! Our code went from:

target.server = function() {
  echo('### Serving butter');

  exec('node app.js', { async: true });


target.server = function() {
  echo('### Serving butter');


  // Use child_process.spawn here for a long-running server process
  // (replaces `exec('node app.js', { async: true });`).
  var server = spawn( 'node', [ 'app.js' ] );

  // Mostly stolen from
  server.stdout.on( 'data', function( data ) {
    process.stdout.write( data );

  server.stderr.on( 'data', function( data ) {
    process.stderr.write( "" + data );

  server.on( 'exit', function( code ) {
    console.log( 'server process exited with code ' + code );

This allowed us to properly have the server be started asynchronously and no longer have any issues with the tests running in Firefox!

Still need that continuous integration stuff though so we can have our tests always running upon checkin, allowing us to catch any problems earlier.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: