-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-4274] [SQL] Fix NPE in printing the details of the query plan #3139
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
Conversation
|
Test build #23006 has started for PR 3139 at commit
|
|
Test build #23006 has finished for PR 3139 at commit
|
|
Test PASSed. |
|
@marmbrus @rxin @liancheng Any comments about this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In what case does the toString throw an exception? I think thats the real bug. Is it because Code Generation: ${executedPlan.codegenEnabled} is not wrapped in stringOrError?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See
protected abstract class QueryExecution {
...
override def toString: String =
s"""== Parsed Logical Plan ==
|${stringOrError(logical)}
|== Analyzed Logical Plan ==
|${stringOrError(analyzed)}
|== Optimized Logical Plan ==
|${stringOrError(optimizedPlan)}
|== Physical Plan ==
|${stringOrError(executedPlan)}
|Code Generation: ${executedPlan.codegenEnabled}
|== RDD ==
""".stripMargin.trim
}
logical, analyzed etc. will be computed(which probably cause exception) before passing into stringOrError, not happen inside of stringOrError.
Or you think we'd better to fix the toString here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think thats correct, stringOrError takes a closure so the actual calculation is done inside of the function and should be correctly caught:
scala> def stringOrError[A](f: => A): String =
| try f.toString catch { case e: Throwable => e.toString }
stringOrError: [A](f: => A)String
scala> stringOrError(sys.error("test"))
res0: String = java.lang.RuntimeException: test
scala> def error = sys.error("test")
error: Nothing
scala> stringOrError(error)
res1: String = java.lang.RuntimeException: testThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I didn't know this. Thank you @marmbrus very much for the code snippet.
After debugging, I think you are right, the exception is thrown by ${executedPlan.codegenEnabled}, the executedPlan is null if something wrong in parsing or analyzing etc. I've updated the code again.
d1bcee1 to
f5d7146
Compare
|
Test build #23118 has started for PR 3139 at commit
|
|
Test build #23118 has finished for PR 3139 at commit
|
|
Test PASSed. |
|
I've updated the title of this PR, this is quite simple and ready to be merged. |
|
Thanks, merged to master and 1.2. |
No description provided.