Not all variables are visible in Eclipse debugger 'Variables' view

[GoogleCodeExporter]

Eclipse version: 3.8.0
Chromium Javascript Remote Debugger version: 0.3.8.201210040400
Node.JS version: 0.6.19
OS + version: Ubuntu 12.10 (Linux Mint 14 Cinnamon)

What steps will reproduce the problem?

1. Set up a node.js server using:
require('http').createServer(function(request, response){ 
util.debug(request.connection.remoteAddress); // whatever... }).listen(8080);

2. Set breakpoint in the router function


3. The Variable Explorer will show no such attribute "remoteAddress" in 
"request.connection" even though it shows a whole bunch of other stuff.
Entering "request.connection.remoteAddress" in the Expression Window DOES 
however show "127.0.0.1"

What is the expected result?

request.connection.remoteAddress in the Variable window upon debug/break

What happens instead?

Bunch of other stuff is visible, but not remoteAddress. Makes one wonder what 
else is valid but hidden.

Original issue reported on code.google.com by redsandro on 22 Jan 2013 at 3:05

[GoogleCodeExporter]

Could you please check the following guess for me:

"remoteAddress" is a defined in prototype object. It's not a regular (data) 
property, but an accessor property, which means that only a getter function is 
actually stored in prototype, that is being called and gets the actual data 
from your instance.

Original comment by peter.ry...@gmail.com on 22 Jan 2013 at 4:38

[GoogleCodeExporter]

Wouldn't prototyped properties be visible when traversing down (constructorand)
__proto__ attributes? Including functions? Because remoteAddress, wether
it's a getter function or a value is nowhere to be found within these.
Any other way to verify this?

Original comment by redsandro on 22 Jan 2013 at 5:04

[GoogleCodeExporter]

Yes, it should be in prototype chain. Thanks for checking this. I will try to 
reproduce it.

Original comment by peter.ry...@gmail.com on 22 Jan 2013 at 6:58

[GoogleCodeExporter]

Reproduced on Node.JS v. 0.6.2:
"remoteAddress" is listed in prototype object. However it has an incorrect 
value 'undefined'.

Original comment by peter.ry...@gmail.com on 22 Jan 2013 at 7:11

[GoogleCodeExporter]

Accessor property is handled incorrectly by debugger, if property is defined in 
prototype object.
Probably, getter function is incorrectly called on prototype object rather than 
on original object.

Original comment by peter.ry...@gmail.com on 22 Jan 2013 at 7:13

• Changed state: Accepted

[GoogleCodeExporter]

Thanks for looking into this so quickly.
In my instance, I cannot find remoteAddress in the __proto__ chain, not even 
with value false.

It also doesn't show up when searching (Ctrl+F) the Variable window during 
break(point).

Original comment by redsandro on 22 Jan 2013 at 9:47

[GoogleCodeExporter]

If it doesn't show up in search but you did find it manually, can you tell me 
the object path so I can verify?

Original comment by redsandro on 22 Jan 2013 at 9:49

[GoogleCodeExporter]

I don't think that Ctrl+F works correctly for JavaScript variables. It knows 
nothing about proto chain and Eclipse API doesn't allow providing any logic 
there.

The path is simple: connection.__proto__ (1 step in prototype chain)

Original comment by peter.ry...@gmail.com on 22 Jan 2013 at 10:01

[GoogleCodeExporter]

I will verify it when I am back at the office, but just fyi, if you Ctrl+F
inside the Variable window and search for a variable for which you know it
is inside a __proto__, it will find it.
I think if the debug variable explorer can show it, then Ctrl+F can find it.

Original comment by redsandro on 23 Jan 2013 at 1:35

[GoogleCodeExporter]

Just double-checked, it's like I thought. On my machine is no remoteAddress. 
But when you request it in the expression editor, it does have a value of 
127.0.0.1.

Original comment by redsandro on 24 Jan 2013 at 8:18

[GoogleCodeExporter]

Attachment

Original comment by redsandro on 24 Jan 2013 at 8:21

Attachments:

• v8-remoteAddress-hidden.png

[GoogleCodeExporter]

Looks like you didn't open "connection" as you described initialy

Original comment by peter.ry...@gmail.com on 24 Jan 2013 at 8:47