You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Will Berkeley (JIRA)" <ji...@apache.org> on 2019/05/02 23:59:00 UTC

[jira] [Created] (KUDU-2812) TOCTOU problem with error reporting in kudu-spark and kudu-backup

Will Berkeley created KUDU-2812:
-----------------------------------

             Summary: TOCTOU problem with error reporting in kudu-spark and kudu-backup
                 Key: KUDU-2812
                 URL: https://issues.apache.org/jira/browse/KUDU-2812
             Project: Kudu
          Issue Type: Bug
          Components: backup, spark
    Affects Versions: 1.9.0
            Reporter: Will Berkeley
             Fix For: 1.10.0


In KuduRestore.scala we have code like

{noformat}
          // Fail the task if there are any errors.
          val errorCount = session.getPendingErrors.getRowErrors.length
          if (errorCount > 0) {
            val errors =
              session.getPendingErrors.getRowErrors.take(5).map(_.getErrorStatus).mkString
            throw new RuntimeException(
              s"failed to write $errorCount rows from DataFrame to Kudu; sample errors: $errors")
          }
{noformat}

There's similar code in KuduContext.scala:

{noformat}
      val errorCount = pendingErrors.getRowErrors.length
      if (errorCount > 0) {
        val errors =
          pendingErrors.getRowErrors.take(5).map(_.getErrorStatus).mkString
        throw new RuntimeException(
          s"failed to write $errorCount rows from DataFrame to Kudu; sample errors: $errors")
      }
{noformat}

I've seen the former fail to print any sample errors. Taking a reference to {{session.getPendingErrors.getRowErrors}} and using that through fixes this, so it seems like there's some TOCTOU problem that can occur, probably because multiple batches can be in flight at once.

The latter is most likely vulnerable to this as well.

This issue made diagnosing KUDU-2809 harder.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)