Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OSError: [Errno 9] Bad file descriptor #1021

Closed
jminardi opened this issue Aug 11, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@jminardi
Copy link
Contributor

commented Aug 11, 2015

  1. What were you doing?

Disconnecting from the printer

  1. What did you expect to happen?

Printer to disconnect without error

  1. What happened instead?

printer disconnected with the error pasted below

  1. Branch & Commit or Version of OctoPrint:

Version: 1.3.0.dev179+g214b484 (HEAD branch)
also happens on latest master

  1. Printer model & used firmware incl. version
    (if applicable - always include if unsure):

Marlin Integration Branch

  1. Browser and Version of Browser, Operating
    System running Browser (if applicable - always
    include if unsure):

latest chrome on os x

  1. Link to octoprint.log on gist.github.com or pastebin.com
    (ALWAYS INCLUDE AND DO NOT TRUNCATE):

http://pastebin.com/UtZv4svz

  1. Link to contents of terminal tab or serial.log on
    gist.github.com or pastebin.com (if applicable - always
    include if unsure or reporting communication issues AND
    DO NOT TRUNCATE):

relevant error pasted below

  1. Link to contents of Javascript console in the browser
    on gist.github.com or pastebin.com or alternatively a
    screenshot (if applicable - always include if unsure
    or reporting UI issues):

n/a

  1. Screenshot(s) showing the problem (if applicable - always
    include if unsure or reporting UI issues):

n/a

I have read the FAQ.

Error message:

Traceback (most recent call last):
  File "/Users/jack/code/voxel8/OctoPrint/src/octoprint/util/comm.py", line 824, in _monitor
    line = self._readline()
  File "/Users/jack/code/voxel8/OctoPrint/src/octoprint/util/comm.py", line 1327, in _readline
    self.close(True)
  File "/Users/jack/code/voxel8/OctoPrint/src/octoprint/util/comm.py", line 407, in close
    self._serial.close()
  File "build/bdist.macosx-10.5-x86_64/egg/serial/serialposix.py", line 437, in close
    os.close(self.fd)
OSError: [Errno 9] Bad file descriptor
2015-08-10 22:43:39,492 - octoprint.util.comm - ERROR - Something crashed inside the serial connection loop, please report this in OctoPrint's bug tracker:
Traceback (most recent call last):
  File "/Users/jack/code/voxel8/OctoPrint/src/octoprint/util/comm.py", line 824, in _monitor
    line = self._readline()
  File "/Users/jack/code/voxel8/OctoPrint/src/octoprint/util/comm.py", line 1327, in _readline
    self.close(True)
  File "/Users/jack/code/voxel8/OctoPrint/src/octoprint/util/comm.py", line 407, in close
    self._serial.close()
AttributeError: 'NoneType' object has no attribute 'close'
@jminardi

This comment has been minimized.

Copy link
Contributor Author

commented Aug 11, 2015

The disconnect does work though, and I can reconnect again just fine...

@foosel

This comment has been minimized.

Copy link
Owner

commented Aug 11, 2015

Nothing that OctoPrint can do anything about I fear. If it tries to close the serial line like it is supposed to and that causes an error, that's a problem on the operating system level, nothing I can handle in user space.

I might be able to catch the error there and stop it from propagating, but I'm not sure if I should since it hints at a possible problem the user should investigate.

@nophead

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2015

It could be a user space error. It is saying self.fd is not a valid file
descriptor, so it could be closing a file that has already been closed, for
example.

On 11 August 2015 at 06:56, Gina Häußge notifications@github.com wrote:

Nothing that OctoPrint can do anything about I fear. If it tries to close
the serial line like it is supposed to and that causes an error, that's a
problem on the operating system level, nothing I can handle in user space.

I might be able to catch the error there and stop it from propagating, but
I'm not sure if I should since it hints at a possible problem the user
should investigate.


Reply to this email directly or view it on GitHub
#1021 (comment).

@jminardi

This comment has been minimized.

Copy link
Contributor Author

commented Aug 11, 2015

Is there anything I can do to debug this or is it safe to just ignore?

@foosel

This comment has been minimized.

Copy link
Owner

commented Aug 11, 2015

@nophead you are right, wrong perspective on my end. Still out of reach for OctoPrint though I fear, the error is raised within pyserial.

@jminardi Can you reliably reproduce that? Or is that something that only happened once? If you can reliably reproduce it it might be worth looking further into what's causing that/under which specific circumstances it reproduces. Might make it easier to decide if action needs to be taken (in case of some timing issue) or not. In any case I'm still undecided on what the best course of action is here - should something like this be assumed "normal" and just logged within the closing function, or should it still raise that amount of noise.

@jminardi

This comment has been minimized.

Copy link
Contributor Author

commented Aug 11, 2015

I can reliably reproduce it, happens every time I disconnect when using my mac laptop. I was not seeing the error on my raspi fwiw

@foosel

This comment has been minimized.

Copy link
Owner

commented Aug 11, 2015

But only on the Mac? Hm... I have a Mac Mini here, I'll try to see if that behaves similar some time later this week (still working through the backlog from my two week vacation).

@markwal

This comment has been minimized.

Copy link
Collaborator

commented Aug 11, 2015

Seems like it could be a race between the monitoring thread and another thread (api request perhaps)? It may only happen on a mac based on differences about when the library holds the lock. That code doesn't expect another thread to close and set _serial to None while this thread is in or returning from _readline.

foosel added a commit that referenced this issue Aug 13, 2015

Properly handle serial close on Macs
Readline could still be stuck in a read loop, leading to an exception on Mac
when closing the connection from another thread. This should now be captured
correctly.

Fixes #1021

foosel added a commit that referenced this issue Aug 13, 2015

Use connection closing flag only for exception handling
Otherwise we kill the beforePrinterDisconnected gcode script...

See #1021
@foosel

This comment has been minimized.

Copy link
Owner

commented Aug 13, 2015

@markwal was right, it was a race condition that for whatever reason seems to be reliably reproducible on Macs and never said hello to me before on other systems.

I introduced a new flag into the comm object that will now be set to True if the closing of the serial connection has been triggered and will prevent exceptions (that I can't prevent from occurring here since the readline has to block) from bubbling up in that case. Both reading from and writing to the serial port are now adjusted that way.

I also added an error handler to the self._serial.close() call since it was missing so far.

Fixed in devel (see the above commits), will also be ported to what is going to become the 1.2.5 release.

@foosel foosel closed this Aug 13, 2015

foosel added a commit that referenced this issue Aug 26, 2015

Properly handle serial close on Macs
Readline could still be stuck in a read loop, leading to an exception on Mac
when closing the connection from another thread. This should now be captured
correctly.

Fixes #1021
(cherry picked from commit c829b27)

foosel added a commit that referenced this issue Aug 26, 2015

Use connection closing flag only for exception handling
Otherwise we kill the beforePrinterDisconnected gcode script...

See #1021
(cherry picked from commit 2fe956e)

foosel added a commit that referenced this issue Aug 26, 2015

Properly handle serial close on Macs
Readline could still be stuck in a read loop, leading to an exception on Mac
when closing the connection from another thread. This should now be captured
correctly.

Fixes #1021
(cherry picked from commit c829b27)

foosel added a commit that referenced this issue Aug 26, 2015

Use connection closing flag only for exception handling
Otherwise we kill the beforePrinterDisconnected gcode script...

See #1021
(cherry picked from commit 2fe956e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.