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

Handle case where output buffer is closed during shutdown #365

Merged
merged 2 commits into from
Dec 16, 2019

Conversation

pbaughman
Copy link
Contributor

@pbaughman pbaughman commented Dec 13, 2019

  • Prevent crash during launch shutdown when a process IO event happens
    after the buffers have been closed

  • Use unbuffered output in that case so IO still has a chance of being seen

Fixes #364

Signed-off-by: Pete Baughman [email protected]

  - Prevent crash during launch shutdown when a process IO event happens
    after the buffers have been closed
  - Use unbuffered output in that case so IO still has a chance of being seen

Signed-off-by: Pete Baughman <[email protected]>
@pbaughman
Copy link
Contributor Author

@ivanpauno Some code duplication, but fixes the crash on shutdown in the nightly docker image

@dejanpan
Copy link

@wjwwood fyi and ask if we can get this in a little faster.

self.__stdout_buffer.write(last_line)
except ValueError:
# __stdout_buffer was probably closed by __flush_buffers on shutdown. Output without
# buffering.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pbaughman why not checking if self.__stdout_buffer.closed instead of hoping ValueError was raised for the reasons you expect?

self.__stderr_buffer.write(last_line)
except ValueError:
# __stderr buffer was probably closed by __flush_buffers on shutdown. Output without
# buffering.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pbaughman same as above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hidmic Yeah, I was coming at this from the approach of "this is a race condition" but this method is synchronized with the one that closes the buffers, right? They're not going to get closed out from under us while the method is running?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's asyncio, so no, that won't happen. There're no guarantees regarding execution order, and that's what probably caused this issue in the first place.

Signed-off-by: Pete Baughman <[email protected]>
@pbaughman
Copy link
Contributor Author

@hidmic I've addressed your comments

Copy link
Contributor

@hidmic hidmic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM pending green CI

Copy link
Member

@ivanpauno ivanpauno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@hidmic
Copy link
Contributor

hidmic commented Dec 16, 2019

CI (up to launch, test_launch_ros, test_communication)

  • Linux Build Status
  • Linux-aarch64 Build Status
  • macOS Build Status
  • Windows Build Status

@pbaughman
Copy link
Contributor Author

@hidmic The windows failure looks like a problem with building, not testing.

@hidmic
Copy link
Contributor

hidmic commented Dec 16, 2019

Alright, going in!

@hidmic hidmic merged commit de4c697 into ros2:master Dec 16, 2019
@pbaughman pbaughman deleted the FIX364_IO_on_shutdown branch December 16, 2019 19:51
ivanpauno pushed a commit that referenced this pull request Jan 17, 2020
* Handle case where output buffer is closed during shutdown

  - Prevent crash during launch shutdown when a process IO event happens
    after the buffers have been closed
  - Use unbuffered output in that case so IO still has a chance of being seen

Signed-off-by: Pete Baughman <[email protected]>

* Address MR feedback

Signed-off-by: Pete Baughman <[email protected]>
ivanpauno pushed a commit that referenced this pull request Jan 20, 2020
* Handle case where output buffer is closed during shutdown

  - Prevent crash during launch shutdown when a process IO event happens
    after the buffers have been closed
  - Use unbuffered output in that case so IO still has a chance of being seen

Signed-off-by: Pete Baughman <[email protected]>

* Address MR feedback

Signed-off-by: Pete Baughman <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>
ivanpauno added a commit that referenced this pull request Jan 21, 2020
* Handle case where output buffer is closed during shutdown (#365)

* Handle case where output buffer is closed during shutdown

  - Prevent crash during launch shutdown when a process IO event happens
    after the buffers have been closed
  - Use unbuffered output in that case so IO still has a chance of being seen

Signed-off-by: Pete Baughman <[email protected]>

* Address MR feedback

Signed-off-by: Pete Baughman <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>

* Import test file without contaminating sys.modules (#360)

Signed-off-by: Pete Baughman <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>

* Release loop lock before waiting for it to do work (#369)

Main thread can be blocked trying to acquire
__loop_from_run_thread_lock while emit_event() in another thread is
holding that lock and waiting for the main thread to emit the event.
This change releases the lock before blocking.

Signed-off-by: Shane Loretz <[email protected]>
Signed-off-by: Ivan Santiago Paunovic <[email protected]>

Co-authored-by: Peter Baughman <[email protected]>
Co-authored-by: Shane Loretz <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

I/O operation on closed file in __on_process_stderr
4 participants