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

throw error :

File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.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

Issue 7 has been merged into this issue.

Which operating system are you using?

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

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.)

the current version is 22;

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

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...)

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.

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

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?

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

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

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.

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.

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.

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

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.

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?

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.

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.

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).

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.

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.

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

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.

btw I am running Chrome Version 22.0.1229.79 on OS X 10.7.5