OSError: [Errno 9] Bad file descriptor

[jminardi]

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]

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

[foosel]

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]

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]

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

[foosel]

@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]

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]

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]

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]

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