Question

I am writing a Node.js application in which I fill an Object with data using string-turned-integers as keys (e.g. “62616324573”). Objects always store keys {key:} as Strings, which is ideal compared to the way javascript arrays and their [index] work:

An array defines a million times undefined, once for every index between defined indices.

However, I found that I cannot debug my new objects properly because the Variables panel in Eclipse displays Failed to read variables. Internally they seem to work fine.

Take the following code:

var util = require('util');
util.debug('Run this with --debug-brk=port, and press Resume (F8) to break at the breakpoint below.');

var debugMe = {
    "1000000000" : {
//  "2011743958" : {
        "some" : 1234,
        "random" : true,
        "data" : undefined
    },
//  "1000000001" : {
//  "8302611133" : {
    "3302611133" : {
        "some" : 12345678,
        "random" : false,
        "data" : null
    }
};

util.debug(JSON.stringify(debugMe)); // Look, it prints fine in all cases. This is internal javascript code.
util.debug('...');
util.inspect(debugMe); // And now it doesn't. This is V8 debugging code.

var breakpoint_here = true; // Set breakpoint here!

// hohoho

Set a breakpoint at breakpoint_here and run this with instant-break debugger, e.g. node --debug-brk=5858 debugtest.js. Press resume to jump from line 1 to the breakpoint. Go to your Variables panel and try to inspect debugMe: the panel will crash.

Try again with 10..00 and 10..01. No problem. Except, the numbers appear to be parsed as an array index (!) judging by the way it is written.

debugMe ->
  [1000000000] -> [Object]
  [1000000001] -> [Object]

Now try the 10..10 and 83..02. Suddenly, 83..33 is a normal JSON key instead of an array index, but 10..00 is still an array index. (?)

debugMe ->
  8302611133 ->  [Object]
  [1000000000] -> [Object]

Now try 10..00 and 33..33, and the Variables window will crash again. This is what I expected:

debugMe ->
  1000000000 -> [Object]
  3302611133 -> [Object]

This is what I am guessing is happening, although you can’t actually see it when debugging an object that still cooperates:

debugMe ->
  [1000000000] -> [Object]
  [1000000001] -> undefined
  // (...) // debugger memory fills up
  [3302611132] -> undefined
  [3302611133] -> [Object]

The problem I am guessing is that the numbers in this case are both array indices and the difference is too large, because the debugger will remember 2302611133 times undefined, a problem that should only exist when array is used in stead of JSON object.

• Why are some numbers taken as key (string) and others taken as index?
• Why do some combination of indices work in the debugger, and others don’t?
• Is the “million times undefined” problem without me knowing also happening with objects?

Let me recap:

• Small differences in string-cast integers ‘int’ seem to work fine, but in the debugger they become [indices]
• Big differences up to about a billion in the key don’t work, Variables window crashes. No console output.
• Even bigger differences work again, but some become [index] and others stay ‘key’.

Because I had to do manual crashtests, it has taken me forever to find out the problem was in the numbers, and not the contents of the objects themselves. It’s hard to imagine the problem affects only the debugger and not the application itself, because it’s the same (V8) engine. I’m hoping someone can point out all the facts and variables I am missing.

-update-

No one seems to know about this. Not known logic, nor a known bug. I filed a bug at Eclipse WDT, although I am not sure that’s the source of the behavior.

Answer 1

Asker here,

Short:
It’s a bug. Use potatoesalad as a workaround. (see other answer)

Longer:

The lack of response makes me believe there is no logic, and this is in fact a bug.

At first, I was unclear to the source of the bug (Eclipse/WDT/Node/V8), so I filed a bugreport at Eclipse.

The bug turned out to be not_eclipse, so I re-filed the bugreport at the Chrome Dev Tools project.

This bug was accepted, and turned out to be two bugs:
Issue 76, and
Issue 77.