Closed Bug 783651 Opened 7 years ago Closed 6 years ago

Can't connect to marionette (and possibly other problems) after restarting b2g on pandaboard

Categories

(Core Graveyard :: Widget: Gonk, defect)

x86
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mdas, Unassigned)

References

Details

Attachments

(1 file)

Attached file logcat output
I've come across an issue where if you stop and start b2g a few times in a row (adb shell in, then run 'stop b2g' and 'stop b2g'), then the pandaboard goes into a strange state. You can still adb shell in, and the /system/b2g/b2g process still runs, but there is no visual output, I can't connect to marionette, and I don't see anything in the logcat other than "E/profiler(   576): Registering start signal". I've been able to reproduce this by stopping b2g , waiting a few seconds, then starting b2g, about 5 times in a row. 

This is an issue for automated tests against the pandaboard running b2g, since we stop and start b2g before running test suites.

I've attached the logcat.

mwu, do you have an idea of what's causing this?
This is still a problem.
Setting a more descriptive title + CCing tzimmermann.
Summary: Restart b2g problem on pandaboard → Can't connect to marionette (and possibly other problems) after restarting b2g on pandaboard
I observed this problem just now.
Here is a guess:

For the marionette problem, you should check if marionette's listening socket is created with SO_REUSEADDR (or whatever this flag is in marionette's programming language), and set it otherwise. This will allow later instances of marionette to re-use the address+port.

This thing is, when you abort b2g, the kernel's resources for that socket remain allocated until they timeout. (because TCP says so). Thus you cannot listen to the address+port with your new b2g process. Setting SO_REUSEADDR overrides this behavior and allows b2g to listen anyway.
Interesting.

<jgriffin> wlach: so we don't have this problem on e.g., an unagi, but let me see if I can figure out how the socket is being opened
<jgriffin> wlach: yes, the remote debugger uses https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIServerSocket, which doesn't expose that level of control
<jgriffin> so it isn't something we'd be able to easily change
<wlach> jgriffin: I guess as an experiment we could modify the low-level interface and see if it helps?
<jgriffin> yes, we could
<jgriffin> http://mxr.mozilla.org/mozilla-central/source/netwerk/base/src/nsServerSocket.cpp uses NSPR
No longer running b2g on pandaboards for automation.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.