[
https://issues.apache.org/jira/browse/SPARK-22982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16320664#comment-16320664
]
Josh Rosen commented on SPARK-22982:
------------------------------------
In theory this affects all 1.6.0+ versions.
It's going to be much harder to trigger in 1.6.0 because we shouldn't have as
many Janino-induced remote ClassNotFoundExceptions to trigger the error path.
We should probably port to other 2.x branches, with one caveat: we need to make
sure that my fix isn't relying on JRE 8.x functionality because I think at
least some of those older branches still have support for Java 7.
> Remove unsafe asynchronous close() call from FileDownloadChannel
> ----------------------------------------------------------------
>
> Key: SPARK-22982
> URL: https://issues.apache.org/jira/browse/SPARK-22982
> Project: Spark
> Issue Type: Bug
> Components: Spark Core
> Affects Versions: 1.6.0, 2.0.0, 2.1.0, 2.2.0
> Reporter: Josh Rosen
> Assignee: Josh Rosen
> Priority: Blocker
> Labels: correctness
> Fix For: 2.3.0
>
>
> Spark's Netty-based file transfer code contains an asynchronous IO bug which
> may lead to incorrect query results.
> At a high-level, the problem is that an unsafe asynchronous `close()` of a
> pipe's source channel creates a race condition where file transfer code
> closes a file descriptor then attempts to read from it. If the closed file
> descriptor's number has been reused by an `open()` call then this invalid
> read may cause unrelated file operations to return incorrect results due to
> reading different data than intended.
> I have a small, surgical fix for this bug and will submit a PR with more
> description on the specific race condition / underlying bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
