CoffeeScript now supports source maps - and correct line number mapping with errors.

http://jashkenas.github.com/coffee-script/documentation/docs/coffee-script.html

However, when longjohn is require'd, it messes with the line mapping (I imagine it's something to do with the override of Error.prepareStackTrace).

I have used Node.js (0.10.33) quite long time with 'longjohn' in the clustered application. No any bad affect of 'longjohn' was detected there. The application worked stable and used about 20% of CPU time. Recently I have updated my Nodejs engine up to latest version (0.12.5) and correspondingly did update for all dependencies. The 'longjonh' was updated to 0.2.7 version. But, unfortunately, after restart my application began to eat up to 95-100% of CPU time. The commenting of 'var longjohn = require('longjohn');' fixed the situation and now it's using no more than 20% of CPU time. Can you please explain what is happening? Is it my fault? Or there is some bug?

Test script:

var longjohn = require('longjohn');
longjohn.async_trace_limit = -1;

function timeoutHandler() {
  console.log('timeout fired!');
  throw new Error('EXPLODE');
}

function createTimeout() {
  setTimeout(timeoutHandler, 1000);
}

createTimeout();

Results:

In my app I am json-sending errors to the client for some development environments so that these become visible on the browser.

I understand that longjohn is adding circular stuff to the default error instances. And so, Express' res.json cannot deal with these error instances anymore.

So, do you have any tricks or an advice for that?

An example stack trace:

"RangeError: Invalid array length",
"    at onwrite (_stream_writable.js:265:15)",
"    at WritableState.onwrite (_stream_writable.js:96:5)",
"    at Socket._write (net.js:653:5)",
"    at doWrite (_stream_writable.js:225:10)",
"    at writeOrBuffer (_stream_writable.js:215:5)",
"    at Writable.write (_stream_writable.js:182:11)",
"    at Socket.write (net.js:615:40)",

But these came up from a few other places too. We solved the problem by reverting to 0.2.2

Every so often, we'll run into an error that longjohn tries to serialize, and in attempting to do so will peg the CPU and gobble up RAM (like 1+GB).

It seems like it attempts to serialize our entire application in a single Object graph...

uncaughtException: { [Error: Invalid timestamp. Please provide timezone as fallback]
  __cached_trace__: 
   [ { receiver: 
        { localTime: [Function],
          humanizeDuration: [Function] },
       fun: [Function],
       pos: 401 },
     { receiver: undefined,
       fun: [Function: grouper],
       pos: 4432 },
     { receiver: 
        { ArrayBuffer: [Function: ArrayBuffer],
          Int8Array: { [Function: Int8Array] BYTES_PER_ELEMENT: 1 },
          Uint8Array: { [Function: Uint8Array] BYTES_PER_ELEMENT: 1 },
          Uint8ClampedArray: { [Function: Uint8ClampedArray] BYTES_PER_ELEMENT: 1 },
          Int16Array: { [Function: Int16Array] BYTES_PER_ELEMENT: 2 },
          Uint16Array: { [Function: Uint16Array] BYTES_PER_ELEMENT: 2 },
          Int32Array: { [Function: Int32Array] BYTES_PER_ELEMENT: 4 },
          Uint32Array: { [Function: Uint32Array] BYTES_PER_ELEMENT: 4 },
          Float32Array: { [Function: Float32Array] BYTES_PER_ELEMENT: 4 },
          Float64Array: { [Function: Float64Array] BYTES_PER_ELEMENT: 8 },
          DataView: [Function: DataView],
          global: [Circular],
          process: 
           { title: 'node',
             version: 'v0.8.21',
             moduleLoadList: 
              [ 'Binding evals',
                'Binding natives',
                'NativeModule events',
                'NativeModule buffer',
                'Binding buffer',
                'NativeModule assert',
                // several thousands of additional lines omitted ...

It might be worth using util's inspect to mitigate this.

CoffeeScript supports source maps - and correct line number mapping with errors.

http://jashkenas.github.com/coffee-script/documentation/docs/coffee-script.html

However, when longjohn is require'd, it messes with the line mapping -- probably something to do with the override of Error.prepareStackTrace. It would be great if longjohn could be fixed to show coffeescript source line numbers, when a coffeescript source map is available.

No need to import the entirety of grunt-contrib.

Upgraded to grunt 0.4.0 so we can use the newest grunt-contrib-coffee version. File syntax is a little different so I updated that. Tests & compiles are still working.

I’m using the latest version of babel-node and with the version of source-map-support pinned by longjohn the symbolicated stack traces are incorrect. This change allows newer versions, I did constraint it to < 1.0.0 just in case, but I don’t feel strongly about it so can remove it if you prefer.

Hello,

At work we are using longjohn together with our own async library, which works wonders, only recently we began parsing gzipped files.

The issue is that when using longjohn that the gunzip of the zlib core module virtually stops responding. We have tested and it responds after a few hours.

I will include the code that will give this issue:

var zlib = require('zlib'),
    request = require('request'),
    longjohn = require('longjohn');

request({ url: 'http://www.jaap.nl/sitemaps/sitemap1.xml.gz', encoding: null }, function(error, response, body) {
  if(response.statusCode === 200) {
    zlib.gunzip(body, function (err, data) {
      console.log(data); // This callback is never executed.
    });
  }
});

When removing the require of longjohn the callback is called without any issue.

I hope this issue can be fixed.

Kind regards and Thanks in advance,

Jasper van Rijbroek

Fixes the error: TypeError: Cannot call method 'getFunctionName' of undefined

In longjohn.js:call_stack_location(), if the object stack[2] is not defined it crashes the server with an uncaught exception.

Signed-off-by: Jim Knochelmann [email protected]

Seeing an issue where .once( 'data' ... ) on a stream will only be hit if there is an .on( 'data'... ) call somewhere on the same eventemitter object.

I've spent an hour or so in the code trying to figure out the issue, but I am stumped. Could you give me any guidance on why a .once() would not be hit unless there's a .on() for the same event type?

Specifically I am seeing this using the node-postgres module with longjohn included. In their connection module, I tracked it down to this:

  // without this, .once below seems inconsistent
  this.stream.on( 'data', function() {
    var nop = 1;
  });

  this.stream.once('data', function(buffer) {
    var responseCode = buffer.toString('utf8');
    if(responseCode != 'S') {
      return self.emit('error', new Error('The server does not support SSL connections'));
    }
    var tls = require('tls');
    self.stream = tls.connect({
      socket: self.stream,
      servername: host,
      rejectUnauthorized: self.ssl.rejectUnauthorized,
      ca: self.ssl.ca,
      pfx: self.ssl.pfx,
      key: self.ssl.key,
      passphrase: self.ssl.passphrase,
      cert: self.ssl.cert,
      NPNProtocols: self.ssl.NPNProtocols
    });
    self.attachListeners(self.stream);
    self.emit('sslconnect');

    self.stream.on('error', function(error){
      self.emit('error', error);
    });
  });

If I don't add the .on( 'data'...) the .once( 'data'... will never be hit while longjohn is loaded.

All I get is:

    at Promise.resolve.then (/usr/src/app/lib/promises/index.js:61:15)
    at process._tickDomainCallback (internal/process/next_tick.js:129:7)

Is this project still alive?

I'm using TypeScript and would like to use longjohn conditionally just in dev mode. Documentation suggests using conditional require:

if (process.env.NODE_ENV !== 'production'){
  require('longjohn');
}

However, TypeScript imports are restricted to top-level, making it impossible to do such conditional check without falling back to commonJS-style require.

There is also a related issue: https://github.com/mattinsler/longjohn/issues/61 - having the ability to disable longjohn after require would be a sufficient fix.

I'm writing some tests where I want longjohn on and others when it should be off. I could just run the non long john tests first, but it'd be nice to just be able to turn it on and off depending on the sub test suite.

Is there a way?

Thanks in advance, Francois

The way how longjohn wraps EventEmitter is incompatible with other modules doing a similar/same wrapping. I tested by creating a clone of longjohn (incl. modifiny the 'longjohn' property of on()) and used it together with unmodified longjohn in following script:

require('longjohn');

var assert = require('assert');
var EventEmitter = require('events').EventEmitter;

function onListener() {}
function onceListener() {}

function test() {
    var emitter = new EventEmitter;
    emitter.on('xxx', onListener);
    emitter.once('xxx', onceListener);
    assert.equal(emitter.listenerCount('xxx'), 2);

    emitter.removeListener('xxx', onListener);
    // fails on second call as onListener was not removed
    assert.equal(emitter.listenerCount('xxx'), 1);

    emitter.removeListener('xxx', onceListener);
    assert.equal(emitter.listenerCount('xxx'), 0);
}

test();

require('longjohn-clone');

test();