Closed Bug 1288293 Opened 4 years ago Closed 4 years ago

From ChromeWorker, using js-ctypes to `read`, `select`, or `poll` with libc is resulting in EINTR (regression)

Categories

(Core :: js-ctypes, defect)

48 Branch
Unspecified
Linux
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: noitidart, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

Attached file workerEINTR.xpi (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160711002726

Steps to reproduce:

I created a ChromeWorker, and with js-ctypes and am doing `read` on a pipe. This used to work fine prior to build - 40.0a1 - 2015-04-16 - however since then we are getting EINTR.

Here is a simple reproduction - https://github.com/Noitidart/workerEINTR

The README.md has some extra info. Like subprocess.jsm uses this same technique, but because it is not in a worker they are not having this issue I think.

Attached is the XPI from the workerEINTR repo above. It is a bug reproduction. Simply open browser console, and install the addon.


Actual results:

EINTR happened


Expected results:

EINTR should not happen
I also did a mozregression:

```
39.0a1 - 2015-02-24 - good
39.0a1 - 2015-03-28 - good
40.0a1 - 2015-04-13 - good
40.0a1 - 2015-04-15 - good
xxxxxxxxxxxxxxxxxxxx
40.0a1 - 2015-04-16 - bad
40.0a1 - 2015-04-17 - bad
40.0a1 - 2015-04-21 - bad
40.0a1 - 2015-04-29 - bad

16:18.22 INFO: Narrowed nightly regression window from > [2015-04-15, 2015-04-17] (2 days) to [2015-04-15, 2015-04-16] > (1 days) (~0 steps left)
16:18.22 INFO: Got as far as we can go bisecting nightlies...
16:18.22 INFO: Last good revision: a6f7a33731bc (2015-04-15)
16:18.22 INFO: First bad revision: a35163f83d22 (2015-04-16)
16:18.22 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a6f7a33731bc&tochange=a35163f83d22
```
Component: Untriaged → js-ctypes
Product: Firefox → Core
OS: Unspecified → Linux
Actually subprocess.jsm is also doing `poll` in a ChromeWorker, that's interesting, I don't know why they aren't getting EINTR and the test case her is getting EINTR.
I don't see the proximate cause of this change, but if you're calling system functions you have to be prepared for normal error codes like EINTR. I don't think ctypes can or should insulate your code from this.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
Thanks much for taking a look Benjamin

I'll look more into it. I was making a call to `poll` in a file watcher here for Android - https://github.com/Noitidart/jscFileWatcher/blob/master/DirectoryWatcherPollWorker.js#L418

Was hoping to land this for the file watching bug here - https://bugzilla.mozilla.org/show_bug.cgi?id=958280

What's really interesting is the subprocess.jsm is not even checking for EINTR in the call to `poll` - https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/system/child_process/subprocess_worker_unix.js#200

Would you or anyone have any ideas why the simple test case and my file watcher are hitting EINTR but subprocess.jsm is not?
Attaching a XPI with updated repo, it shows the error in browser console in a cleaner way. I loop it 100, or 1k, times but get EINTR every time - https://github.com/Noitidart/workerEINTR/blob/master/worker.js#L18
Attachment #8773119 - Attachment is obsolete: true
For now, I ended up not being able to avoid EINTR, it's really weird though that in the child_subprocess file I would never get EINTR -  (I edited that file in a build using janitor).

So I'm living with the EINTR and had to get around a race condition, you can see it here - https://bugzilla.mozilla.org/show_bug.cgi?id=958280#c43
You need to log in before you can comment on or make changes to this bug.