I'm experiencing an odd problem with nodejs on raspbian and I kindly ask help to you because I'm starting to tear my hair. Here it follows.

I've installed raspbian (through NOOBS lite 1.3.4) on my raspberry, so I set up nodejs 0.10.1 (while trying to solve this problem I've installed it downloading the arm-ready raspberry pi package and in a latter moment I already compiled it) and finally put the source code of my nodejs app in it.

Well, I've launched npm install, started the app and everything seemed fine: I was able to reach the login page. without problems.

Problems come out after the login: login data gets correctly processed by the server side, which completes all his stuff and tries to render the view. While rendering the view node crashes all the times.

In the console there happens the following line:


The odd thing is that that source code works on my Ubuntu machine and also on other qemu arm machines: this made me think that there's an issue with dependencies/nodejs version running, so I've tried the following things:

  • compiling node (took 2h 30min...) following http://elsmorian.com/post/23474168753/node-js-on-raspberry-pi
  • tried to empty entirely the view (which is EJS), leaving only a console.log statement: it worked, i.e. the view was rendered;
  • tried node 0.11.9 from arm package;
  • updated express version from 3.0.6 to 3.4.x.

Have you got some hints? I'm here for updating the post if necessary.


Made some more troubleshoointg; I confirm that the problem happens during the EJS view rendering, with the following results:

  • emptying the view works (as stated above);
  • fulfilling view only with HTML works;
  • fulfilling view with nodejs server side directives works;
  • including other ejs files with include works;
  • including other ejs files which include even only one EJS themselves does not work (even if the latest view contains only plain HTML/is whitespace only/is empty).

So it seems that the problem happens in the ejs rendering engine with too much nesting (in this case the second level): I'm going to prepare an viable proof-of-concept (hoping that someone experienced this problem and managed to solve it).

It's still a very odd thing since the ejs dependency (https://github.com/visionmedia/ejs) is javascript-only code (I mean there's nothing to compile) so the same stuff should work in many environments given the same version of node interpreter and same dependencies (which are defined in the package.json file with precise versions).

Update 2

Managed to create a proof-of-concept which also helped me to narrow the field around the problem: it happens with too much ejs's include, only if the server side render directive runs under synchronize.fiber.

For seeing the problem using the POC:

  • put it in your raspbian and in another machine, e.g. Ubuntu (wheezy, 7);
  • unpack it;
  • run npm install.

You can leverage on the file views/view2_second_level.ejs commenting/de-commenting the line which includes the third level view: under raspbian it will work only if commented. Under ubuntu it will work in any case.

The problem displays about exactly like in our real application (the POC shows more or less always the same error, our app shows it randomly but it's fairly more complex): I'm hopefully that this is due to compilation/installation problems of fibers (it contains C/C++ code which must be compiled).

  • Interesting issue. I think you should also raise this as a bug on the ejs project.
    – Jivings
    Jan 15, 2014 at 17:41
  • Thank you: while preparing the Proof Of Concept I unveiled the implication of synchronize module. So I will make some more investigation/troubleshooting on it before issuing something.
    – reallynice
    Jan 15, 2014 at 17:43
  • You might get more answers to this on StackOverflow, even though it seems to be specific to the Pi.
    – TomG
    Jan 16, 2014 at 2:51

1 Answer 1


With a great help from the viable example, I've been luckily able to solve the problem: since fibers is a compiled dependency I leveraged on synchronize dependency version update, hoping that the problem was been solved.

Making the "micro" update of synchronize, from 0.5.1 to 0.5.4, its fibers made a big jump, from 0.6.x to 1.0.x: it seems that the problem was a bug in fibers resolved in the meanwhile.

I've made a few testing, with a special look also to other dependencies with C/C++ code, and everything seems working fine, so I take the liberty to say that fibers 0.6.x does not work on raspbian 2014-01-07-wheezy-raspbian (from http://www.raspberrypi.org/downloads), while fibers 1.0.x does work on raspbian 2014-01-07-wheezy-raspbian.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.