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

[CI] SocketStreamTest failing on CI #16119

Closed
MarcusDenker opened this issue Feb 8, 2024 · 2 comments
Closed

[CI] SocketStreamTest failing on CI #16119

MarcusDenker opened this issue Feb 8, 2024 · 2 comments
Milestone

Comments

@MarcusDenker
Copy link
Member

Bug description
some tests in SocketStreamTest are failing:

on Mac:

  • testFlushOtherEndClosed – MacOSX64.Network.Tests.SocketStreamTest
  • testNextPutAllFlushOtherEndClosed – MacOSX64.Network.Tests.SocketStreamTest

on Linux:

  • testFlushLargeMessageOtherEndClosed – Unix64.Network.Tests.SocketStreamTest
@MarcusDenker MarcusDenker added this to the 12.0.0 milestone Feb 14, 2024
@Rinzwind
Copy link
Contributor

These tests were added in pull request #15984 which was merged in commit 9a4b8d5.

That commit was used in builds 1336, 1337 and 1338 of the ‘Pharo12’ Jenkins job. Those all had #testFlushOtherEndClosed fail on macOS and #testFlushLargeMessageOtherEndClosed on Linux.

In build 1442, #testFlushOtherEndClosed and #testNextPutAllFlushOtherEndClosed failed on macOS, and #testFlushLargeMessageOtherEndClosed failed on Linux.

@daniels220: Could you check what the cause of those failures might be and how that can be fixed?

@daniels220
Copy link
Contributor

daniels220 commented Mar 25, 2024

This is fixed in #16172, which is a redo of a close follow-on to #15984. I meant to remind about getting it merged, but I've been unexpectedly busy. It would be great if it could be merged in time for Pharo 12—like I said, it's a really close follow-on to #15984, that just got roadblocked by a mistake on my part with the Semaphore API and then I never got back around to it. But, I understand if this is outside the scope of what's acceptable after code freeze. In that case I can move over the specific change that fixes the test, which is just adding a wait in an appropriate spot.

@guillep sounded like you were going to look at #16172, but it looks like it fell through the cracks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants