Skip to content

Fix StackOverflowError with select expressions #1524

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Sep 21, 2019
Merged

Fix StackOverflowError with select expressions #1524

merged 1 commit into from
Sep 21, 2019

Conversation

elizarov
Copy link
Contributor

  • onSend/onReceive clauses on the same channel: Instead of
    StackOverflowError we throw IllegalStateException and leave
    the channel in the original state.
  • Fix SOE in select with "opposite channels" stress-test. The fix is
    based on the sequential numbering of atomic select operation.
    Deadlock is detected and the operation with the lower sequential
    number is aborted and restarted (with a larger number).

Fixes #504
Fixes #1411

@elizarov elizarov requested a review from qwwdfsad September 10, 2019 11:56
@elizarov elizarov changed the title Fix StackOverflowException with select expressions Fix StackOverflowError with select expressions Sep 10, 2019
@qwwdfsad qwwdfsad self-requested a review September 19, 2019 11:52
qwwdfsad
qwwdfsad approved these changes Sep 19, 2019
View reviewed changes
Copy link
Collaborator

@qwwdfsad qwwdfsad left a comment •
edited
Loading

Choose a reason for hiding this comment

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

LGTM, please squash and merge

@elizarov
Fix StackOverflowException with select expressions
6807cf0 
* onSend/onReceive clauses on the same channel: Instead of
  StackOverflowError we throw IllegalStateException and leave
  the channel in the original state.
* Fix SOE in select with "opposite channels" stress-test. The fix is
  based on the sequential numbering of atomic select operation.
  Deadlock is detected and the operation with the lower sequential
  number is aborted and restarted (with a larger number).

Fixes #504
Fixes #1411
@elizarov elizarov merged commit 3dbe82b into develop Sep 21, 2019
@elizarov elizarov deleted the select-send-receive branch September 21, 2019 14:11
elizarov added a commit that referenced this pull request Sep 22, 2019
@elizarov
Fix race condition in pair select
93d2fe7 
This bug was introduced by #1524. The crux of problem is that
TryOffer/PollDesc.onPrepare method is no longer allowed to update
fields in these classes (like "resumeToken" and "pollResult") after call
to tryResumeSend/Receive method, because the latter will complete
the ongoing atomic operation and helper method might find it complete
and try reading "resumeToken" which was not initialized yet.

This change removes "pollResult" field which was not really needed
("result.pollResult" field is used) and removes "resumeToken" by
exploiting the fact that current implementation of
CancellableContinuationImpl does not need a token anymore. However,
CancellableContinuation.tryResume/completeResume ABI is left intact,
because it is used by 3rd party code.

This fix lead to overall simplification of the code. A number of fields
and an auxiliary IdempotentTokenValue class are removed, tokens used to
indicate various results are consolidated, so that resume success
is now consistently indicated by a single RESUME_TOKEN symbol.

Fixes #1561
@elizarov elizarov mentioned this pull request Sep 22, 2019
Merged
elizarov added a commit that referenced this pull request Sep 23, 2019
@elizarov
Fix race condition in pair select
4396f38 
This bug was introduced by #1524. The crux of problem is that
TryOffer/PollDesc.onPrepare method is no longer allowed to update
fields in these classes (like "resumeToken" and "pollResult") after call
to tryResumeSend/Receive method, because the latter will complete
the ongoing atomic operation and helper method might find it complete
and try reading "resumeToken" which was not initialized yet.

This change removes "pollResult" field which was not really needed
("result.pollResult" field is used) and removes "resumeToken" by
exploiting the fact that current implementation of
CancellableContinuationImpl does not need a token anymore. However,
CancellableContinuation.tryResume/completeResume ABI is left intact,
because it is used by 3rd party code.

This fix lead to overall simplification of the code. A number of fields
and an auxiliary IdempotentTokenValue class are removed, tokens used to
indicate various results are consolidated, so that resume success
is now consistently indicated by a single RESUME_TOKEN symbol.

Fixes #1561
elizarov added a commit that referenced this pull request Sep 23, 2019
@elizarov
Fix race condition in pair select
8ccbf47 
This bug was introduced by #1524. The crux of problem is that
TryOffer/PollDesc.onPrepare method is no longer allowed to update
fields in these classes (like "resumeToken" and "pollResult") after call
to tryResumeSend/Receive method, because the latter will complete
the ongoing atomic operation and helper method might find it complete
and try reading "resumeToken" which was not initialized yet.

This change removes "pollResult" field which was not really needed
("result.pollResult" field is used) and removes "resumeToken" by
exploiting the fact that current implementation of
CancellableContinuationImpl does not need a token anymore. However,
CancellableContinuation.tryResume/completeResume ABI is left intact,
because it is used by 3rd party code.

This fix lead to overall simplification of the code. A number of fields
and an auxiliary IdempotentTokenValue class are removed, tokens used to
indicate various results are consolidated, so that resume success
is now consistently indicated by a single RESUME_TOKEN symbol.

Fixes #1561
elizarov added a commit that referenced this pull request Sep 26, 2019
@elizarov
Fix race condition in pair select
ddd2d9c 
This bug was introduced by #1524. The crux of problem is that
TryOffer/PollDesc.onPrepare method is no longer allowed to update
fields in these classes (like "resumeToken" and "pollResult") after call
to tryResumeSend/Receive method, because the latter will complete
the ongoing atomic operation and helper method might find it complete
and try reading "resumeToken" which was not initialized yet.

This change removes "pollResult" field which was not really needed
("result.pollResult" field is used) and removes "resumeToken" by
exploiting the fact that current implementation of
CancellableContinuationImpl does not need a token anymore. However,
CancellableContinuation.tryResume/completeResume ABI is left intact,
because it is used by 3rd party code.

This fix lead to overall simplification of the code. A number of fields
and an auxiliary IdempotentTokenValue class are removed, tokens used to
indicate various results are consolidated, so that resume success
is now consistently indicated by a single RESUME_TOKEN symbol.

Fixes #1561
elizarov added a commit that referenced this pull request Sep 26, 2019
@elizarov
Fix race condition in pair select
2f8bff1 
This bug was introduced by #1524. The crux of problem is that
TryOffer/PollDesc.onPrepare method is no longer allowed to update
fields in these classes (like "resumeToken" and "pollResult") after call
to tryResumeSend/Receive method, because the latter will complete
the ongoing atomic operation and helper method might find it complete
and try reading "resumeToken" which was not initialized yet.

This change removes "pollResult" field which was not really needed
("result.pollResult" field is used) and removes "resumeToken" by
exploiting the fact that current implementation of
CancellableContinuationImpl does not need a token anymore. However,
CancellableContinuation.tryResume/completeResume ABI is left intact,
because it is used by 3rd party code.

This fix lead to overall simplification of the code. A number of fields
and an auxiliary IdempotentTokenValue class are removed, tokens used to
indicate various results are consolidated, so that resume success
is now consistently indicated by a single RESUME_TOKEN symbol.

Fixes #1561
elizarov added a commit that referenced this pull request Oct 2, 2019
@elizarov
Fix race in channel select/cancel
9c769c8 
This bug was introduced by PR #1524. It was reproducing when there
is a regular "send" operation on one side of a channel and
"select { onReceive }" on another side of the channel and the
"send" coroutine gets cancelled. The problem is that
SendElement.tryResumeSend implementation was calling finishPrepare
before it has successfully resumed continuation, so if that
continuation was already cancelled, the code in "finishPrepare" had
already stored the wrong affected node which it would later try to
call "completeResume" on.

This patch also adds hexAddress to the debug toString method of
all internal node classes in channel implementation.

Fixes #1588
@elizarov elizarov mentioned this pull request Oct 2, 2019
Merged
elizarov added a commit that referenced this pull request Oct 2, 2019
@elizarov
Fix race in channel select/cancel
af09e01 
This bug was introduced by PR #1524. It was reproducing when there
is a regular "send" operation on one side of a channel and
"select { onReceive }" on another side of the channel and the
"send" coroutine gets cancelled. The problem is that
SendElement.tryResumeSend implementation was calling finishPrepare
before it has successfully resumed continuation, so if that
continuation was already cancelled, the code in "finishPrepare" had
already stored the wrong affected node which it would later try to
call "completeResume" on.

This patch also adds hexAddress to the debug toString method of
all internal node classes in channel implementation.

Fixes #1588
elizarov added a commit that referenced this pull request Oct 3, 2019
@elizarov
Fix race in channel select/cancel
d9d3574 
This bug was introduced by PR #1524. It was reproducing when there
is a regular "send" operation on one side of a channel and
"select { onReceive }" on another side of the channel and the
"send" coroutine gets cancelled. The problem is that
SendElement.tryResumeSend implementation was calling finishPrepare
before it has successfully resumed continuation, so if that
continuation was already cancelled, the code in "finishPrepare" had
already stored the wrong affected node which it would later try to
call "completeResume" on.

This patch also adds hexAddress to the debug toString method of
all internal node classes in channel implementation.

Fixes #1588
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@qwwdfsad qwwdfsad qwwdfsad approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@elizarov @qwwdfsad