Re: [Chrome DevTools] Object Ids among mutiple snapshot in remote debugging

[Yury Semikhatsky]

On Wed, Feb 13, 2013 at 9:47 PM, masoomeh <masoomeh....@gmail.com> wrote:

Hi there,
As mentioned in the following:
https://developers.google.com/chrome-developer-tools/docs/heap-profiling#views_summary
The object IDs are the same among multiple snapshot taken. This is true when using Chrome Developer Tools in the browser. However, this is not true when using remote debugging to take heap snapshot. Is this a bug? Is there any fix for it?

The behavior should be exactly the same in case of remote debugging. Why do you think it is not true for remote debugging? Can you describe you scenario?

Yury

 

Thanks

--
You received this message because you are subscribed to the Google Groups "Google Chrome Developer Tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-chrome-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Masoomeh Rudafshani]

I expect the behaviour to be the same, but it is not.
This is the scenario: I take two consecutive snapshots from a page using remote debugging (profiler domain). This is implemented as an extension for chrome browser. The extension takes a snapshot and writes each object ID and corresponding class name to a file. When I compared IDs of corresponding objects in two snapshots, I noticed that the IDs are different. Although this is not for all objects, I mean for some of them the IDs are the same.

However, if I take two snapshots using chrome developer tools in browsers, the ids of corresponding objects are the same.

[Ilya Tikhonovsky]

It could be a bug. Do you have a working scenario?

Regards,
Tim.

[Masoomeh Rudafshani]

I don't have a working scenario. I checked it for an empty document and also for Gmail page and in both cases I noticed the IDs discrepancy. Attached you can find the list of objects from two snapshots.

Thanks,
Masoomeh

[Yury Semikhatsky]

There is a known bug that sometimes object ids can be reused after the object is collected and another one is allocated at the same address. Here is a bug report for tracking the issue: https://code.google.com/p/v8/issues/detail?id=2189

[Masoomeh Rudafshani]

Does this mean that if an object is not collected, its object id remains the same?

According to the experiment I've done, object ids do not remain the same when remotely debugging a page. I checked it on an empty page, taking two snapshots using chrome developer tools in the browser. The object ids were the same as far as I checked. However, when using remote debugging protocol the object ids of corresponding objects were different.

Is the part of code responsible for generating heap snapshot in remote debugging protocol different from the part that is used in chrome developer tools in browser?

How is it possible to fix this bug for remote debugging?

Thanks

[Yury Semikhatsky]

On Mon, Feb 25, 2013 at 10:25 PM, Masoomeh Rudafshani <masoomeh....@gmail.com> wrote:

Does this mean that if an object is not collected, its object id remains the same?

Yes, if a tracked object survives GC then its id will be the same.

 

According to the experiment I've done, object ids do not remain the same when remotely debugging a page. I checked it on an empty page, taking two snapshots using chrome developer tools in the browser. The object ids were the same as far as I checked. However, when using remote debugging protocol the object ids of corresponding objects were different.

Note that remote objects ids used in remote debugging protocol has nothing to do with the heap profiler object ids. They are to different worlds and in the remote debuggin protocol we currently may return new id for the same object when you say evaluate an expression that results in the object. You shouldn't mix remote object id with heap snapshot object ids.

 

Is the part of code responsible for generating heap snapshot in remote debugging protocol different from the part that is used in chrome developer tools in browser?

Yes. Object id returned in reply to Runtime.evaluate command has nothing to do with heap snapshot ids.

 

How is it possible to fix this bug for remote debugging?

There is HeapProfiler.getObjectByHeapObjectId command that allows to translate heap snapshot object id into remote object id.

[Masoomeh Rudafshani]

When I'm talking about object ids, I mean the object ids that are included in the heap snapshot. I use the Profiler domain in remote debugging protocol, take the whole snapshot, and find the object ids. It has nothing to do with Runtime domain.
I use the following command:

chrome.debugger.sendCommand(debuggee, "Profiler.takeHeapSnapshot", {"detailed":true}, callback);

and then process the heapsnapshot considering the following meta information:

Object {node_fields: Array[5], node_types: Array[7], edge_fields: Array[3],edge_types: Array[3]}

1. edge_fields: Array[3]
2. edge_types: Array[3]
3. node_fields: Array[5]
1. 0: "type"
2. 1: "name"
3. 2: "id"
4. 3: "self_size"
5. 4: "edge_count"
6. length: 5
7. __proto__: Array[0]
4. node_types: Array[7]
5. __proto__: Object

The object IDs are the third field  as indicated above. Are you saying the above ID is equal to remote object id in runtime domain?

Would you please answer my previous questions regarding this clarification as those questions are yet unanswered.

Thanks

[Yury Semikhatsky]

On Tue, Feb 26, 2013 at 7:10 PM, Masoomeh Rudafshani <masoomeh....@gmail.com> wrote:

When I'm talking about object ids, I mean the object ids that are included in the heap snapshot. I use the Profiler domain in remote debugging protocol, take the whole snapshot, and find the object ids. It has nothing to do with Runtime domain.
I use the following command:

chrome.debugger.sendCommand(debuggee, "Profiler.takeHeapSnapshot", {"detailed":true}, callback);

and then process the heapsnapshot considering the following meta information:

Object {node_fields: Array[5], node_types: Array[7], edge_fields: Array[3],edge_types: Array[3]}

1. edge_fields: Array[3]
2. edge_types: Array[3]
3. node_fields: Array[5]
1. 0: "type"
2. 1: "name"
3. 2: "id"
4. 3: "self_size"
5. 4: "edge_count"
6. length: 5
7. __proto__: Array[0]
4. node_types: Array[7]
5. __proto__: Object

The object IDs are the third field  as indicated above. Are you saying the above ID is equal to remote object id in runtime domain?

No, I'm saying that they are *different* and should never be compared to each other.

 

Would you please answer my previous questions regarding this clarification as those questions are yet unanswered.

Sorry, as far as I can see I replied to all your questions. Can you repeat the questions that are still not clear?

[Masoomeh Rudafshani]

The clarifications are inlined.

On Tue, Feb 26, 2013 at 7:11 AM, Yury Semikhatsky <yu...@chromium.org> wrote:

On Mon, Feb 25, 2013 at 10:25 PM, Masoomeh Rudafshani <masoomeh....@gmail.com> wrote:

Does this mean that if an object is not collected, its object id remains the same?

Yes, if a tracked object survives GC then its id will be the same.

 

According to the experiment I've done, object ids do not remain the same when remotely debugging a page. I checked it on an empty page, taking two snapshots using chrome developer tools in the browser. The object ids were the same as far as I checked. However, when using remote debugging protocol the object ids of corresponding objects were different.

Note that remote objects ids used in remote debugging protocol has nothing to do with the heap profiler object ids. They are to different worlds and in the remote debuggin protocol we currently may return new id for the same object when you say evaluate an expression that results in the object. You shouldn't mix remote object id with heap snapshot object ids.

 

Please note that I'm not mixing remote object id with heap snapshot object ids. I'm always talking about heap snapshot ids. So, the above question in unanswered yet! Basically what I'm asking is the different behaviour I see when taking a heap snapshot manually (using chrome developer tools) and when taking a snapshot by a program using profiler domain.

 

Is the part of code responsible for generating heap snapshot in remote debugging protocol different from the part that is used in chrome developer tools in browser?

Yes. Object id returned in reply to Runtime.evaluate command has nothing to do with heap snapshot ids.

Again this question in unanswered since I'm not at all taking about Runtime domain. I'm always taking about profiler domain, The question is how come the part responsible for generating heap snapshot object id is different (in Chrome developer tools and in Profiler domain of remote debugging) while they both produce a heap snapshot?

 

 

How is it possible to fix this bug for remote debugging?

There is HeapProfiler.getObjectByHeapObjectId command that allows to translate heap snapshot object id into remote object id.

 

Again I'm not talking about remote object ids in the above question.

[Yury Semikhatsky]

On Wed, Feb 27, 2013 at 5:37 PM, Masoomeh Rudafshani <masoomeh....@gmail.com> wrote:

The clarifications are inlined.

On Tue, Feb 26, 2013 at 7:11 AM, Yury Semikhatsky <yu...@chromium.org> wrote:

On Mon, Feb 25, 2013 at 10:25 PM, Masoomeh Rudafshani <masoomeh....@gmail.com> wrote:

Does this mean that if an object is not collected, its object id remains the same?

Yes, if a tracked object survives GC then its id will be the same.

 

According to the experiment I've done, object ids do not remain the same when remotely debugging a page. I checked it on an empty page, taking two snapshots using chrome developer tools in the browser. The object ids were the same as far as I checked. However, when using remote debugging protocol the object ids of corresponding objects were different.

Note that remote objects ids used in remote debugging protocol has nothing to do with the heap profiler object ids. They are to different worlds and in the remote debuggin protocol we currently may return new id for the same object when you say evaluate an expression that results in the object. You shouldn't mix remote object id with heap snapshot object ids.

 

Please note that I'm not mixing remote object id with heap snapshot object ids. I'm always talking about heap snapshot ids. So, the above question in unanswered yet! Basically what I'm asking is the different behaviour I see when taking a heap snapshot manually (using chrome developer tools) and when taking a snapshot by a program using profiler domain.

The only difference on the backend side when you use built-in client vs. remote client is that some domains may be off in case of remote debugging protocol. Some of the domains execute JS code while processing protocol messages and that may affect heap profile. That the only difference I can think of. DevTools front-end lives in a separate process so it should not affect heap snapshots.

 

 

Is the part of code responsible for generating heap snapshot in remote debugging protocol different from the part that is used in chrome developer tools in browser?

Yes. Object id returned in reply to Runtime.evaluate command has nothing to do with heap snapshot ids.

Again this question in unanswered since I'm not at all taking about Runtime domain. I'm always taking about profiler domain,

I see, sorry for the confusion.

 

The question is how come the part responsible for generating heap snapshot object id is different (in Chrome developer tools and in Profiler domain of remote debugging) while they both produce a heap snapshot?

The mechanism used to generate object ids is exactly same in both cases. Could you share with us the code where you observe the discrepancy?