-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Timing issue can cause EIO_AfterWrite to throw exception #639
Comments
A workaround for this bug is to prevent |
I think this is fixed but I'll run your code and check it out. |
I can confirm this bug is fixed in #733
Please reopen if you're having any issues with the new version! Testing it out would help a lot! Thanks! |
@reconbot - Thanks so much! I will test out the new version ASAP and will write back if any issues occur. |
In some cases, calling
write()
while the SerialPort is being closed and a concurrent write is in progress can result in an uncaught exception. I'm not exactly sure why this is happening, but here's my hunch: the 2nd write is queued until the 1st write completes, and when the 2nd write is dequeued after the SerialPort has already closed, we have an exception.This error is apparently thrown in
EIO_AfterWrite
. Even if the SerialPort has an "error" event handler registered and even if the call towrite(buf, callback)
has acallback
specified, this error is still thrown as an uncaught exception.Code to reproduce:
Sample output from the above program looks like this:
Interestingly,
undefined:0
is printed from somewhere? It doesn't appear to be a call toconsole.log
orconsole.error
either... Then, of course, the TypeError is thrown and stack trace is printed.Note that the exception from
EIO_AfterWrite
does not occur if you do not pass a callback to thewrite()
routine. That is because of #638; the program will instead crash beforehand due to an Unhandled 'error' event.Also note that the exception from
EIO_AfterWrite
does not occur if the timing is changed. This bug might not occur on all systems, and the behavior might change if the baud rate is changed. For example, if the delay to close the serial port is increased to 100 ms. and the delay between queued writes is increased to 10 ms, this bug occurs about 50% of the time.Anyway, I'd be happy to provide more information about this bug if needed. The fix for this isn't very obvious to me because I'm not familiar with Node addons or libuv, but I'd be happy to help as much as possible.
The text was updated successfully, but these errors were encountered: