1173376 - residentUnique write error when Developer Tools option on Firefox OS is on

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Developer Tools, defect)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I am seeing the following error when enabling "Developer Tools" on Firefox OS Simulator:

Settings -> Developer -> Developer HUD -> Developer Tools

It's happening in a loop till I switch the option off.


From the OS console:

     at Actor<.writeError (resource://gre/modules/commonjs/toolkit/loader.js -> r
esource://gre/modules/devtools/server/protocol.js:902:undefined)
exports.Memory<.residentUnique@resource://gre/modules/commonjs/toolkit/loader.js
 -> resource://gre/modules/devtools/shared/memory.js:334:5
actorBridge/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gr
e/modules/devtools/server/actors/common.js:535:12
actorProto/</handler@resource://gre/modules/commonjs/toolkit/loader.js -> resour
ce://gre/modules/devtools/server/protocol.js:1008:19
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre
/modules/devtools/server/main.js:1474:15
ChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/commonjs/
toolkit/loader.js -> resource://gre/modules/devtools/transport/transport.js:742:
5


Honza

Comment 1

[Jordan Santell [:jsantell] [@jsantell]]

Due to this happening before bug 1172182 (via https://pastebin.mozilla.org/8836386), I no longer think it's a refactoring issue, but that the memory module is returning a non-number, causing the protocol to unable to write.

I don't have a pipeline for easy deploying latest fx-team to b2g, nor do I know the XPCOM memory component, so unassigning myself, but if you can see if toolkit/devtools/shared/memory:334 is returning, I'm guessing it's returning a non-number, in which case, it can either fall back to 0, or something someone on the memory team could check out to see why it's undefind (my guess) in the first place

Comment 2

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #1)
> I don't have a pipeline for easy deploying latest fx-team to b2g

As an aside, here is the process[1] I use.  It's a bit of setup work, but in the end you can test local b2g changes roughly as fast as ones to Firefox.

[1]: https://gist.github.com/jryans/b7e190342ab49c16ccca

Comment 3

[Jordan Santell [:jsantell] [@jsantell]]

That's exactly what I need, jryans, thanks -- I'll report back if I learn anything new about the HUD issue

Comment 4

[Jordan Santell [:jsantell] [@jsantell]]

Can anyone see if its an issue with residentUnique method returning a non-number? Easy fix on our end if so (just return a 0).

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Jan, any ideas on this?

Comment 6

[Jan Keromnes [:janx]]

Honza, what platform are you using? I'm not able to reproduce the issue on Linux.

Measuring USS (`residentUnique`) can only work on Linux because it uses a system call. On other platforms, that function should return 0 or something falsy. Maybe Jordan is right by suggesting we make the memory actor return 0 if `residentUnique` returns something falsy?

Comment 7

[Jan Keromnes [:janx]]

Attachment: Ensure residentUnique always respects the devtools protocol.

Honza, could you please verify if this change fixes the issue you're seeing?

Comment 8

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I am seeing the issue on Win7 64 bits

Unfortunately, the patch doesn't help, I can still see the exception...

Honza

Comment 9

[BMO Automation]

Firefox OS is not being worked on