socket.py Bad file descriptor

[GoogleCodeExporter]

when run this:
python jsleakcheck.py -d closure-disposable -v

throw error :

File 
"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threadin
g.py", line 522, in __bootstrap_inner
  File "../../pyautolib/remote_inspector_client.py", line 361, in run
    self._client.SendMessage(str(request))
  File "../../pyautolib/remote_inspector_client.py", line 166, in SendMessage
    self._Write('\x00' + msg.encode('utf-8') + '\xff')
  File "../../pyautolib/remote_inspector_client.py", line 175, in _Write
    self.handle_write()
  File "../../pyautolib/remote_inspector_client.py", line 181, in handle_write
    sent = self.send(self._write_buffer)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/asyncore.py", line 349, in send
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.py", line 165, in _dummy
error: [Errno 9] Bad file descriptor

I want known where the problems are? thanks

Original issue reported on code.google.com by thinkabl...@gmail.com on 23 Aug 2012 at 10:47

[GoogleCodeExporter]

Issue 7 has been merged into this issue.

Original comment by marja@google.com on 23 Aug 2012 at 11:27

[GoogleCodeExporter]

Which operating system are you using?

I've never bumped into this one before...

Original comment by marja@google.com on 23 Aug 2012 at 11:27

[GoogleCodeExporter]

Also, which version of chrome are you running? Can you try with a recent 
version (22 or 23)? (It's a good idea to backup your profile before installing 
the new version, in case you want to go back to the old one.)

Original comment by marja@google.com on 23 Aug 2012 at 11:29

[GoogleCodeExporter]

the current version is 22; 

Original comment by thinkabl...@gmail.com on 23 Aug 2012 at 11:43

[GoogleCodeExporter]

dennisjeffrey, btw, have you seen anything like this when working with the 
remote inspector client?

Original comment by marja@google.com on 23 Aug 2012 at 11:56

[GoogleCodeExporter]

Can you try the following:
- Patch remote inspector client with the attached patch:
your-repo$ patch -p1 < ric1.patch
- And run again and attach the output to this bug.

Thanks for your efforts!

(I'm adding more debug options to jsleakcheck so that these could be enabled 
with a command line switch...)

Original comment by marja@google.com on 23 Aug 2012 at 3:44

[GoogleCodeExporter]

Instead of the patch you can now update your checkout to the latest version, 
and change the line:
self._show_socket_messages = show_socket_messages
to:
self._show_socket_messages = True

in pyautolib/remote_inspector_client.py.

Original comment by marja@google.com on 24 Aug 2012 at 7:28

[GoogleCodeExporter]

Actually, this has started appearing for me too; no need to send debug info, 
I'm able to reproduce this now.

Original comment by marja@google.com on 24 Aug 2012 at 7:39

[GoogleCodeExporter]

Ok, so, it seems this error occurs when we're done and we try to stop the 
remote inspector. It shouldn't affect the results jsleakcheck produces, but ofc 
we'll try to get it fixed..

thinkable.love, do you still get meaningful results despite this error?

Original comment by marja@google.com on 24 Aug 2012 at 7:46

[GoogleCodeExporter]

thanks, I find the fault:

change 
 # f = urllib2.urlopen('http://localhost:9222/json')

to

f = urllib2.urlopen('http://127.0.0.1:9222/json')

then ok!  thanks very much

Original comment by thinkabl...@gmail.com on 24 Aug 2012 at 7:48

[GoogleCodeExporter]

Hmm? Using 127.0.0.1 shouldn't have anything to do with the "Bad file 
descriptor" problem.

Python 2.6 might not be recent enough, pls see this bug: 
http://bugs.python.org/issue5798

Original comment by marja@google.com on 24 Aug 2012 at 8:32

[GoogleCodeExporter]

I have come across the "Bad file descriptor" error in the past while working on 
the remote inspector client, but it typically happened for me when I tried 
making more than one connection to the remote inspector client at the same 
time.  If it's now happening when we try to stop the remote inspector, then 
that is a new manifestation of it for me.

I'm also curious why changing "localhost" to "127.0.0.1" might seem to avoid 
the problem.

Original comment by dennisjeffrey@chromium.org on 28 Aug 2012 at 10:02

[GoogleCodeExporter]

Now this happens very reproducibly when closing the remote inspector client. Do 
you need a smaller reproduction case or could you try out with jsleakcheck? Now 
there is a debug option --remote-inspector-client-debug and the instructions on 
how to run it are on the project page.

I don't think localhost has anything to do with it, it's just that for some mac 
users their DNS is borked, and that circumvents that.

Original comment by marja@google.com on 29 Aug 2012 at 5:56

[GoogleCodeExporter]

I tried running the remote inspector client with a separate pyauto test and 
wasn't able to get the socket error to appear.  I also downloaded jsleakcheck 
and followed the instructions for running it (with the test-page.html), but I 
tried running it more than 10 times and never got the socket error (it seems to 
run successfully and finds "Leak: 1 MyObj").

I'm running it on a linux box.  Are you seeing it on linux?  Maybe a smaller 
repro case might help for me to repro the issue.

Original comment by dennisjeffrey@chromium.org on 30 Aug 2012 at 1:10

[GoogleCodeExporter]

Ahh, no, this only appears on mac! Sorry for not being more specific about it 
in comment 8,

Original comment by marja@google.com on 30 Aug 2012 at 7:04

[GoogleCodeExporter]

Aha, good to know the issue seems to be platform-specific.

If it's true that the issue happens when we invoke Stop() to close the 
connection to the remote inspector, then the error trace given in the original 
post for this issue is surprising because that code should only be invoked when 
we're in the middle of making a request to the remote inspector.

I looked at the jsleakcheck code and it looks like the only 2 ways in which the 
remote inspector client is used is (1) calling HeapSnapshot() and (2) calling 
EvaluateJavaScript().  Both of those should block until the requests are fully 
serviced and a result is produced.  So I wouldn't expect any requests to be 
in-progress at the time in which the remote inspector client is being shut down.

Marja, do you have cycles to investigate this further on your Mac?  Meanwhile 
I'll update this issue if I can get a Mac and learn anything new about it.

Original comment by dennisjeffrey@chromium.org on 30 Aug 2012 at 5:38

[GoogleCodeExporter]

The stack for the "bad file descriptor" error I get in Stop is not the same as 
in the original post.

I ended up in a dead end when trying to investigate this on mac. I'm not sure 
if this could be a python bug, or if RemoteInspectorClient is misusing the 
asyncore. One thread is blocked in poll(), while the other threads are possibly 
chancing the set of sockets, is it expected that this will work?

Original comment by marja@google.com on 30 Aug 2012 at 5:45

[GoogleCodeExporter]

Could you send the stack trace you're getting?

I don't have a good understanding for how poll() is working in asyncore.  The 
original reason I added "use_poll=True" to the asyncore.loop calls was because 
it didn't work without that, even though I didn't completely understand why.  I 
just tried setting  "use_poll=False" with a pyauto test that invokes the remote 
inspector client, and it worked this time.  Could you try that and see if it 
avoids the problem in your case?

It's possible that when I originally added use_poll=True, that concealed some 
bugs that ended up getting fixed by our more recent changes to the remote 
inspector client code.  Maybe use_poll=True is not needed anymore?  But it 
would still be good to dig down and understand what's going on behind the 
scenes here.

Original comment by dennisjeffrey@chromium.org on 30 Aug 2012 at 6:37

[GoogleCodeExporter]

I tried with use_poll=False, but it didn't help. Internet said that use_poll = 
True would be needed when trying to modify the set of file descriptors, because 
select will get confused if the set is modified when it's in progress, and poll 
should be less confused.

I'm starting to suspect it's just asyncore misuse in the remote inspector 
client, with the multiple threads... I wonder if it was possible to rewrite it 
to not use threads like this. Or not use asyncore.

I'll add the exact stack trace tomorrow.

Original comment by marja@google.com on 30 Aug 2012 at 9:12

[GoogleCodeExporter]

Okay,  so, the stack trace is:
Exception in thread Thread-2:

Traceback (most recent call last):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "../../pyautolib/remote_inspector_client.py", line 590, in run
    asyncore.loop(timeout=1, count=1, use_poll=True)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 214, in loop
    poll_fun(timeout, map)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/asyncore.py", line 140, in poll
    r, w, e = select.select(r, w, e, timeout)
error: (9, 'Bad file descriptor')

With use_poll = False, it crashes the same way with the same stack trace 
(except the part which lists the params, ofc).

Original comment by marja@google.com on 31 Aug 2012 at 11:26

[GoogleCodeExporter]

A-ha!

So, it's a bit weird that poll in asyncore does select instead of poll. :) 
Anyway:

I think this is the difference:

On Mac:
$ python
>>> import select
>>> hasattr(select, "poll")
False

On Linux:
True

So, when hasattr(select, "poll"), it uses poll2 instead of poll in asyncore, 
and that actually does select.poll, and not select.select.

Anyway, assuming that select.poll and select.select are not confusingly named, 
and do the poll and select syscalls, respectively: this is just normal. Remote 
inspector client ends up doing a select and modifies the set of file 
descriptors while the select is running.

Original comment by marja@google.com on 31 Aug 2012 at 11:33

[GoogleCodeExporter]

I am having a little trouble parsing this thread to determine if there is a 
workaround for this issue. Is there one?
 I am running on a Mac with Python v 2.7 and Chrome 21.0.1180.89.  

Original comment by arwenp...@hotmail.com on 18 Sep 2012 at 9:48

[GoogleCodeExporter]

No workaround yet, but this only happens at shutdown, so the results should 
still be valid.

Original comment by marja@google.com on 19 Sep 2012 at 7:57

[GoogleCodeExporter]

I am also having either this problem or the buffer overrun on heap snapshot 
problem everytime on my own app. Test app works but I get bad file descriptor 
after run.

Original comment by m...@zoosk.com on 5 Oct 2012 at 6:19

[GoogleCodeExporter]

btw I am running Chrome Version 22.0.1229.79 on OS X 10.7.5

Original comment by m...@zoosk.com on 5 Oct 2012 at 6:20