Repository navigation
GH-45497: [C++][CSV] Avoid buffer overflow when a line has too many columns - #45498
Conversation
|
@github-actions crossbow submit -g cpp |
|
@ursabot please benchmark |
|
Benchmark runs are scheduled for commit 463fe8c23da28dcea4c7fae2d712cc661295a844. Watch https://buildkite.com/apache-arrow and https://conbench.ursa.dev for updates. A comment will be posted here when the runs are complete. |
This comment was marked as outdated.
This comment was marked as outdated.
|
@zanmato1984 Sorry for pinging you once again! I'm looking for reviewers on this PR :) |
|
Thanks for your patience. Conbench analyzed the 4 benchmarking runs that have been run so far on PR commit 463fe8c23da28dcea4c7fae2d712cc661295a844. There were 14 benchmark results indicating a performance regression:
The full Conbench report has more details. |
There was a problem hiding this comment.
If the Resize() failed, is values_[values_size_++] = v safe?
There was a problem hiding this comment.
Hmm, that's a good point. We might adopt the same kind of approach as in the presized writer below.
There was a problem hiding this comment.
Why do we need 2, 5, 10 here? 1, 100 aren't enough?
There was a problem hiding this comment.
The conditions for triggering the issue are bit mysterious, so I thought it would be safer to ensure non-regression with a larger set of parameters. I can trim it down a bit of course.
There was a problem hiding this comment.
Do we need all these cases?
It seems that -1, 1, 32767 are enough.
There was a problem hiding this comment.
when !status_.ok(), the values_buffer_ isn't gurantee to exist?
There was a problem hiding this comment.
It will probably exist, but it might not be large enough.
zanmato1984
left a comment
There was a problem hiding this comment.
Other than kou's comment about the writing in ResizableValueDescWriter when Resize failed, this LGTM.
…many columns * Add guard against going past the buffer's end, while minimizing the performance overhead of the runtime check * Add error propagation for buffer (re)allocation, instead of aborting
|
@github-actions crossbow submit -g cpp |
|
@ursabot please benchmark |
|
Benchmark runs are scheduled for commit 2d1965f. Watch https://buildkite.com/apache-arrow and https://conbench.ursa.dev for updates. A comment will be posted here when the runs are complete. |
|
Revision: 2d1965f Submitted crossbow builds: ursacomputing/crossbow @ actions-4b9f129152 |
|
(by the way, do we have an open issue for the failing Debian builds? @kou) |
|
I think I've addressed all review comments. Does someone want to take a quick look or should I merge? |
| } | ||
| status_ &= std::move(resize_status); | ||
| } | ||
| if (ARROW_PREDICT_TRUE(status_.ok())) { |
There was a problem hiding this comment.
Why not the same approach as PresizedValueDescWriter as you mentioned before? Less perf hurting?
There was a problem hiding this comment.
As mentioned by @mapleFU above, the pointer might not be valid anymore if the resize failed.
Also, this is less performance-critical as this is normally run only on the first line of data.
There was a problem hiding this comment.
I could add comments to explain this if that's useful.
There was a problem hiding this comment.
As mentioned by @mapleFU above, the pointer might not be valid anymore if the resize failed.
Ah, good point.
Also, this is less performance-critical as this is normally run only on the first line of data.
I don't think that's necessary. Do it as you wish.
|
Thanks for your patience. Conbench analyzed the 4 benchmarking runs that have been run so far on PR commit 2d1965f. There were 9 benchmark results indicating a performance regression:
The full Conbench report has more details. |
|
After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 25d8bed. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 15 possible false positives for unstable benchmarks that are known to sometimes produce them. |
What changes are included in this PR?
With these changes, a CSV line with an unexpectedly large number of columns will raise an error such as "CSV parse error: Expected 13 columns, got ...".
Are these changes tested?
Yes, by additional unit tests.
Are there any user-facing changes?
No.