GH-35519: [C++][Parquet] Fixing exception handling in parquet FileSerializer

[mapleFU]

Rationale for this change

Mentioned in #35519

What changes are included in this PR?

Exception handling in CheckRowsWritten

Are these changes tested?

No, I don't know how to mock it currently

Are there any user-facing changes?

no

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[github-actions]

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[mapleFU]

@pitrou Would you mind take a look? Analyze is in #35519 (comment)

[github-actions]

⚠️ GitHub issue #35519has been automatically assigned in GitHub to PR creator.

[pitrou]

I think we should instead prevent RowGroupSerializer::Close from creating an invalid internal state. For example:

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
auto column_writers = std::move(columns_writers_);
for (constauto writer : column_writers) {
if (writer) {
total_bytes_written_ += writer->Close();
total_compressed_bytes_written_ +=
writer->total_compressed_bytes_written();
}
}
// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

[mapleFU]

@pitrou Good Idea! Fix as your advice

[pitrou]

Good catch!

[wgtmac]

Suggested change

	// If ColumnWriter::Close thrown an exception, avoid
	// have bad states in column_writers_.
	// Avoid invalid state if ColumnWriter::Close() throws internally.

[wgtmac]

If anything wrong happens here, should we let the FileSerializer know that it cannot accept any write any more?

[mapleFU]

it's already closed, whether success or not, no any write can comes to RowGroupSerializer. I guess it will cause FileSerializer destruct

[wgtmac]

This is true if the exception happens when calling FileSerializer::Close(). What if this happens when the user directly calls RowGroupWriter::Close() to close the current row group and starts a new one?

[mapleFU]

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
// ...// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

I guess it will mark closed_ first and throw exception. During stack unwind, the RowGroupSerializer will destruct. And during next time Close is called, it will do nothing

[mapleFU]

Comment resolved. I tried to solve some CI problems here: #35527

Seems CI failed frequently these days...

[pitrou]

Seems CI failed frequently these days...

Unfortunately :-( Are there issues already open for these failures?

[pitrou]

Thanks @mapleFU . This looks ok now.

[pitrou]

Hmm, the R CI failure may be related as it seems to succeed on git main:
https://github.com/apache/arrow/actions/runs/4937417890/jobs/8826087049

[mapleFU]

Yeah, I don't want to rebase this because there are still too much failed tests :-(
Just wait others idea on this patch or merge if you think it's ok

[pitrou]

We can't merge until we make sure the R CI failure is unrelated.

[pitrou]

Hmm, actually the segfault is already known:
#35391

[mapleFU]

😭Hurt by so many failed

[mapleFU]

[ RUN ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r
unknown file: error: SEH exception with code 0xc00000fd thrown in the test body.
[ FAILED ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r, where GetParam() = Threaded16b1024r (314 ms)

I guess this is unrelated. https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/47021836

[mapleFU]

@pitrou Seems R failed is not related. Would you mind take a look?

[pitrou]

I'm restarting CI a last time but it looks like this is ready to go.

[ursabot]

Benchmark runs are scheduled for baseline = e2e3a9d and contender = 2d76d9a. 2d76d9a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.26% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.51% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.42% ⬆️0.03%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 2d76d9a5 ec2-t3-xlarge-us-east-2
[Finished] 2d76d9a5 test-mac-arm
[Finished] 2d76d9a5 ursa-i9-9960x
[Finished] 2d76d9a5 ursa-thinkcentre-m75q
[Finished] e2e3a9df ec2-t3-xlarge-us-east-2
[Finished] e2e3a9df test-mac-arm
[Finished] e2e3a9df ursa-i9-9960x
[Finished] e2e3a9df ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[mapleFU]

Rationale for this change

Mentioned in #35519

What changes are included in this PR?

Exception handling in CheckRowsWritten

Are these changes tested?

No, I don't know how to mock it currently

Are there any user-facing changes?

no

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[github-actions]

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[mapleFU]

@pitrou Would you mind take a look? Analyze is in #35519 (comment)

[github-actions]

⚠️ GitHub issue #35519has been automatically assigned in GitHub to PR creator.

[pitrou]

I think we should instead prevent RowGroupSerializer::Close from creating an invalid internal state. For example:

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
auto column_writers = std::move(columns_writers_);
for (constauto writer : column_writers) {
if (writer) {
total_bytes_written_ += writer->Close();
total_compressed_bytes_written_ +=
writer->total_compressed_bytes_written();
}
}
// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

[mapleFU]

@pitrou Good Idea! Fix as your advice

[pitrou]

Good catch!

[wgtmac]

Suggested change

	// If ColumnWriter::Close thrown an exception, avoid
	// have bad states in column_writers_.
	// Avoid invalid state if ColumnWriter::Close() throws internally.

[wgtmac]

If anything wrong happens here, should we let the FileSerializer know that it cannot accept any write any more?

[mapleFU]

it's already closed, whether success or not, no any write can comes to RowGroupSerializer. I guess it will cause FileSerializer destruct

[wgtmac]

This is true if the exception happens when calling FileSerializer::Close(). What if this happens when the user directly calls RowGroupWriter::Close() to close the current row group and starts a new one?

[mapleFU]

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
// ...// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

I guess it will mark closed_ first and throw exception. During stack unwind, the RowGroupSerializer will destruct. And during next time Close is called, it will do nothing

[mapleFU]

Comment resolved. I tried to solve some CI problems here: #35527

Seems CI failed frequently these days...

[pitrou]

Seems CI failed frequently these days...

Unfortunately :-( Are there issues already open for these failures?

[pitrou]

Thanks @mapleFU . This looks ok now.

[pitrou]

Hmm, the R CI failure may be related as it seems to succeed on git main:
https://github.com/apache/arrow/actions/runs/4937417890/jobs/8826087049

[mapleFU]

Yeah, I don't want to rebase this because there are still too much failed tests :-(
Just wait others idea on this patch or merge if you think it's ok

[pitrou]

We can't merge until we make sure the R CI failure is unrelated.

[pitrou]

Hmm, actually the segfault is already known:
#35391

[mapleFU]

😭Hurt by so many failed

[mapleFU]

[ RUN ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r
unknown file: error: SEH exception with code 0xc00000fd thrown in the test body.
[ FAILED ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r, where GetParam() = Threaded16b1024r (314 ms)

I guess this is unrelated. https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/47021836

[mapleFU]

@pitrou Seems R failed is not related. Would you mind take a look?

[pitrou]

I'm restarting CI a last time but it looks like this is ready to go.

[ursabot]

Benchmark runs are scheduled for baseline = e2e3a9d and contender = 2d76d9a. 2d76d9a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.26% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.51% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.42% ⬆️0.03%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 2d76d9a5 ec2-t3-xlarge-us-east-2
[Finished] 2d76d9a5 test-mac-arm
[Finished] 2d76d9a5 ursa-i9-9960x
[Finished] 2d76d9a5 ursa-thinkcentre-m75q
[Finished] e2e3a9df ec2-t3-xlarge-us-east-2
[Finished] e2e3a9df test-mac-arm
[Finished] e2e3a9df ursa-i9-9960x
[Finished] e2e3a9df ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[mapleFU]

Rationale for this change

Mentioned in #35519

What changes are included in this PR?

Exception handling in CheckRowsWritten

Are these changes tested?

No, I don't know how to mock it currently

Are there any user-facing changes?

no

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[github-actions]

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[mapleFU]

@pitrou Would you mind take a look? Analyze is in #35519 (comment)

[github-actions]

⚠️ GitHub issue #35519has been automatically assigned in GitHub to PR creator.

[pitrou]

I think we should instead prevent RowGroupSerializer::Close from creating an invalid internal state. For example:

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
auto column_writers = std::move(columns_writers_);
for (constauto writer : column_writers) {
if (writer) {
total_bytes_written_ += writer->Close();
total_compressed_bytes_written_ +=
writer->total_compressed_bytes_written();
}
}
// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

[mapleFU]

@pitrou Good Idea! Fix as your advice

[pitrou]

Good catch!

[wgtmac]

Suggested change

	// If ColumnWriter::Close thrown an exception, avoid
	// have bad states in column_writers_.
	// Avoid invalid state if ColumnWriter::Close() throws internally.

[wgtmac]

If anything wrong happens here, should we let the FileSerializer know that it cannot accept any write any more?

[mapleFU]

it's already closed, whether success or not, no any write can comes to RowGroupSerializer. I guess it will cause FileSerializer destruct

[wgtmac]

This is true if the exception happens when calling FileSerializer::Close(). What if this happens when the user directly calls RowGroupWriter::Close() to close the current row group and starts a new one?

[mapleFU]

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
// ...// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

I guess it will mark closed_ first and throw exception. During stack unwind, the RowGroupSerializer will destruct. And during next time Close is called, it will do nothing

[mapleFU]

Comment resolved. I tried to solve some CI problems here: #35527

Seems CI failed frequently these days...

[pitrou]

Seems CI failed frequently these days...

Unfortunately :-( Are there issues already open for these failures?

[pitrou]

Thanks @mapleFU . This looks ok now.

[pitrou]

Hmm, the R CI failure may be related as it seems to succeed on git main:
https://github.com/apache/arrow/actions/runs/4937417890/jobs/8826087049

[mapleFU]

Yeah, I don't want to rebase this because there are still too much failed tests :-(
Just wait others idea on this patch or merge if you think it's ok

[pitrou]

We can't merge until we make sure the R CI failure is unrelated.

[pitrou]

Hmm, actually the segfault is already known:
#35391

[mapleFU]

😭Hurt by so many failed

[mapleFU]

[ RUN ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r
unknown file: error: SEH exception with code 0xc00000fd thrown in the test body.
[ FAILED ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r, where GetParam() = Threaded16b1024r (314 ms)

I guess this is unrelated. https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/47021836

[mapleFU]

@pitrou Seems R failed is not related. Would you mind take a look?

[pitrou]

I'm restarting CI a last time but it looks like this is ready to go.

[ursabot]

Benchmark runs are scheduled for baseline = e2e3a9d and contender = 2d76d9a. 2d76d9a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.26% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.51% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.42% ⬆️0.03%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 2d76d9a5 ec2-t3-xlarge-us-east-2
[Finished] 2d76d9a5 test-mac-arm
[Finished] 2d76d9a5 ursa-i9-9960x
[Finished] 2d76d9a5 ursa-thinkcentre-m75q
[Finished] e2e3a9df ec2-t3-xlarge-us-east-2
[Finished] e2e3a9df test-mac-arm
[Finished] e2e3a9df ursa-i9-9960x
[Finished] e2e3a9df ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[mapleFU]

Rationale for this change

Mentioned in #35519

What changes are included in this PR?

Exception handling in CheckRowsWritten

Are these changes tested?

No, I don't know how to mock it currently

Are there any user-facing changes?

no

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[github-actions]

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[mapleFU]

@pitrou Would you mind take a look? Analyze is in #35519 (comment)

[github-actions]

⚠️ GitHub issue #35519has been automatically assigned in GitHub to PR creator.

[pitrou]

I think we should instead prevent RowGroupSerializer::Close from creating an invalid internal state. For example:

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
auto column_writers = std::move(columns_writers_);
for (constauto writer : column_writers) {
if (writer) {
total_bytes_written_ += writer->Close();
total_compressed_bytes_written_ +=
writer->total_compressed_bytes_written();
}
}
// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

[mapleFU]

@pitrou Good Idea! Fix as your advice

[pitrou]

Good catch!

[wgtmac]

Suggested change

	// If ColumnWriter::Close thrown an exception, avoid
	// have bad states in column_writers_.
	// Avoid invalid state if ColumnWriter::Close() throws internally.

[wgtmac]

If anything wrong happens here, should we let the FileSerializer know that it cannot accept any write any more?

[mapleFU]

it's already closed, whether success or not, no any write can comes to RowGroupSerializer. I guess it will cause FileSerializer destruct

[wgtmac]

This is true if the exception happens when calling FileSerializer::Close(). What if this happens when the user directly calls RowGroupWriter::Close() to close the current row group and starts a new one?

[mapleFU]

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
// ...// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

I guess it will mark closed_ first and throw exception. During stack unwind, the RowGroupSerializer will destruct. And during next time Close is called, it will do nothing

[mapleFU]

Comment resolved. I tried to solve some CI problems here: #35527

Seems CI failed frequently these days...

[pitrou]

Seems CI failed frequently these days...

Unfortunately :-( Are there issues already open for these failures?

[pitrou]

Thanks @mapleFU . This looks ok now.

[pitrou]

Hmm, the R CI failure may be related as it seems to succeed on git main:
https://github.com/apache/arrow/actions/runs/4937417890/jobs/8826087049

[mapleFU]

Yeah, I don't want to rebase this because there are still too much failed tests :-(
Just wait others idea on this patch or merge if you think it's ok

[pitrou]

We can't merge until we make sure the R CI failure is unrelated.

[pitrou]

Hmm, actually the segfault is already known:
#35391

[mapleFU]

😭Hurt by so many failed

[mapleFU]

[ RUN ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r
unknown file: error: SEH exception with code 0xc00000fd thrown in the test body.
[ FAILED ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r, where GetParam() = Threaded16b1024r (314 ms)

I guess this is unrelated. https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/47021836

[mapleFU]

@pitrou Seems R failed is not related. Would you mind take a look?

[pitrou]

I'm restarting CI a last time but it looks like this is ready to go.

[ursabot]

Benchmark runs are scheduled for baseline = e2e3a9d and contender = 2d76d9a. 2d76d9a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.26% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.51% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.42% ⬆️0.03%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 2d76d9a5 ec2-t3-xlarge-us-east-2
[Finished] 2d76d9a5 test-mac-arm
[Finished] 2d76d9a5 ursa-i9-9960x
[Finished] 2d76d9a5 ursa-thinkcentre-m75q
[Finished] e2e3a9df ec2-t3-xlarge-us-east-2
[Finished] e2e3a9df test-mac-arm
[Finished] e2e3a9df ursa-i9-9960x
[Finished] e2e3a9df ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[mapleFU]

Rationale for this change

Mentioned in #35519

What changes are included in this PR?

Exception handling in CheckRowsWritten

Are these changes tested?

No, I don't know how to mock it currently

Are there any user-facing changes?

no

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[github-actions]

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[mapleFU]

@pitrou Would you mind take a look? Analyze is in #35519 (comment)

[github-actions]

⚠️ GitHub issue #35519has been automatically assigned in GitHub to PR creator.

[pitrou]

I think we should instead prevent RowGroupSerializer::Close from creating an invalid internal state. For example:

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
auto column_writers = std::move(columns_writers_);
for (constauto writer : column_writers) {
if (writer) {
total_bytes_written_ += writer->Close();
total_compressed_bytes_written_ +=
writer->total_compressed_bytes_written();
}
}
// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

[mapleFU]

@pitrou Good Idea! Fix as your advice

[pitrou]

Good catch!

[wgtmac]

Suggested change

	// If ColumnWriter::Close thrown an exception, avoid
	// have bad states in column_writers_.
	// Avoid invalid state if ColumnWriter::Close() throws internally.

[wgtmac]

If anything wrong happens here, should we let the FileSerializer know that it cannot accept any write any more?

[mapleFU]

it's already closed, whether success or not, no any write can comes to RowGroupSerializer. I guess it will cause FileSerializer destruct

[wgtmac]

This is true if the exception happens when calling FileSerializer::Close(). What if this happens when the user directly calls RowGroupWriter::Close() to close the current row group and starts a new one?

[mapleFU]

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
// ...// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

I guess it will mark closed_ first and throw exception. During stack unwind, the RowGroupSerializer will destruct. And during next time Close is called, it will do nothing

[mapleFU]

Comment resolved. I tried to solve some CI problems here: #35527

Seems CI failed frequently these days...

[pitrou]

Seems CI failed frequently these days...

Unfortunately :-( Are there issues already open for these failures?

[pitrou]

Thanks @mapleFU . This looks ok now.

[pitrou]

Hmm, the R CI failure may be related as it seems to succeed on git main:
https://github.com/apache/arrow/actions/runs/4937417890/jobs/8826087049

[mapleFU]

Yeah, I don't want to rebase this because there are still too much failed tests :-(
Just wait others idea on this patch or merge if you think it's ok

[pitrou]

We can't merge until we make sure the R CI failure is unrelated.

[pitrou]

Hmm, actually the segfault is already known:
#35391

[mapleFU]

😭Hurt by so many failed

[mapleFU]

[ RUN ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r
unknown file: error: SEH exception with code 0xc00000fd thrown in the test body.
[ FAILED ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r, where GetParam() = Threaded16b1024r (314 ms)

I guess this is unrelated. https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/47021836

[mapleFU]

@pitrou Seems R failed is not related. Would you mind take a look?

[pitrou]

I'm restarting CI a last time but it looks like this is ready to go.

[ursabot]

Benchmark runs are scheduled for baseline = e2e3a9d and contender = 2d76d9a. 2d76d9a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.26% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.51% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.42% ⬆️0.03%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 2d76d9a5 ec2-t3-xlarge-us-east-2
[Finished] 2d76d9a5 test-mac-arm
[Finished] 2d76d9a5 ursa-i9-9960x
[Finished] 2d76d9a5 ursa-thinkcentre-m75q
[Finished] e2e3a9df ec2-t3-xlarge-us-east-2
[Finished] e2e3a9df test-mac-arm
[Finished] e2e3a9df ursa-i9-9960x
[Finished] e2e3a9df ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[mapleFU]

Rationale for this change

Mentioned in #35519

What changes are included in this PR?

Exception handling in CheckRowsWritten

Are these changes tested?

No, I don't know how to mock it currently

Are there any user-facing changes?

no

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[github-actions]

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[mapleFU]

@pitrou Would you mind take a look? Analyze is in #35519 (comment)

[github-actions]

⚠️ GitHub issue #35519has been automatically assigned in GitHub to PR creator.

[pitrou]

I think we should instead prevent RowGroupSerializer::Close from creating an invalid internal state. For example:

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
auto column_writers = std::move(columns_writers_);
for (constauto writer : column_writers) {
if (writer) {
total_bytes_written_ += writer->Close();
total_compressed_bytes_written_ +=
writer->total_compressed_bytes_written();
}
}
// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

[mapleFU]

@pitrou Good Idea! Fix as your advice

[pitrou]

Good catch!

[wgtmac]

Suggested change

	// If ColumnWriter::Close thrown an exception, avoid
	// have bad states in column_writers_.
	// Avoid invalid state if ColumnWriter::Close() throws internally.

[wgtmac]

If anything wrong happens here, should we let the FileSerializer know that it cannot accept any write any more?

[mapleFU]

it's already closed, whether success or not, no any write can comes to RowGroupSerializer. I guess it will cause FileSerializer destruct

[wgtmac]

This is true if the exception happens when calling FileSerializer::Close(). What if this happens when the user directly calls RowGroupWriter::Close() to close the current row group and starts a new one?

[mapleFU]

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
// ...// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

I guess it will mark closed_ first and throw exception. During stack unwind, the RowGroupSerializer will destruct. And during next time Close is called, it will do nothing

[mapleFU]

Comment resolved. I tried to solve some CI problems here: #35527

Seems CI failed frequently these days...

[pitrou]

Seems CI failed frequently these days...

Unfortunately :-( Are there issues already open for these failures?

[pitrou]

Thanks @mapleFU . This looks ok now.

[pitrou]

Hmm, the R CI failure may be related as it seems to succeed on git main:
https://github.com/apache/arrow/actions/runs/4937417890/jobs/8826087049

[mapleFU]

Yeah, I don't want to rebase this because there are still too much failed tests :-(
Just wait others idea on this patch or merge if you think it's ok

[pitrou]

We can't merge until we make sure the R CI failure is unrelated.

[pitrou]

Hmm, actually the segfault is already known:
#35391

[mapleFU]

😭Hurt by so many failed

[mapleFU]

[ RUN ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r
unknown file: error: SEH exception with code 0xc00000fd thrown in the test body.
[ FAILED ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r, where GetParam() = Threaded16b1024r (314 ms)

I guess this is unrelated. https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/47021836

[mapleFU]

@pitrou Seems R failed is not related. Would you mind take a look?

[pitrou]

I'm restarting CI a last time but it looks like this is ready to go.

[ursabot]

Benchmark runs are scheduled for baseline = e2e3a9d and contender = 2d76d9a. 2d76d9a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.26% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.51% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.42% ⬆️0.03%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 2d76d9a5 ec2-t3-xlarge-us-east-2
[Finished] 2d76d9a5 test-mac-arm
[Finished] 2d76d9a5 ursa-i9-9960x
[Finished] 2d76d9a5 ursa-thinkcentre-m75q
[Finished] e2e3a9df ec2-t3-xlarge-us-east-2
[Finished] e2e3a9df test-mac-arm
[Finished] e2e3a9df ursa-i9-9960x
[Finished] e2e3a9df ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[mapleFU]

Rationale for this change

Mentioned in #35519

What changes are included in this PR?

Exception handling in CheckRowsWritten

Are these changes tested?

No, I don't know how to mock it currently

Are there any user-facing changes?

no

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[github-actions]

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[mapleFU]

@pitrou Would you mind take a look? Analyze is in #35519 (comment)

[github-actions]

⚠️ GitHub issue #35519has been automatically assigned in GitHub to PR creator.

[pitrou]

I think we should instead prevent RowGroupSerializer::Close from creating an invalid internal state. For example:

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
auto column_writers = std::move(columns_writers_);
for (constauto writer : column_writers) {
if (writer) {
total_bytes_written_ += writer->Close();
total_compressed_bytes_written_ +=
writer->total_compressed_bytes_written();
}
}
// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

[mapleFU]

@pitrou Good Idea! Fix as your advice

[pitrou]

Good catch!

[wgtmac]

Suggested change

	// If ColumnWriter::Close thrown an exception, avoid
	// have bad states in column_writers_.
	// Avoid invalid state if ColumnWriter::Close() throws internally.

[wgtmac]

If anything wrong happens here, should we let the FileSerializer know that it cannot accept any write any more?

[mapleFU]

it's already closed, whether success or not, no any write can comes to RowGroupSerializer. I guess it will cause FileSerializer destruct

[wgtmac]

This is true if the exception happens when calling FileSerializer::Close(). What if this happens when the user directly calls RowGroupWriter::Close() to close the current row group and starts a new one?

[mapleFU]

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
// ...// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

I guess it will mark closed_ first and throw exception. During stack unwind, the RowGroupSerializer will destruct. And during next time Close is called, it will do nothing

[mapleFU]

Comment resolved. I tried to solve some CI problems here: #35527

Seems CI failed frequently these days...

[pitrou]

Seems CI failed frequently these days...

Unfortunately :-( Are there issues already open for these failures?

[pitrou]

Thanks @mapleFU . This looks ok now.

[pitrou]

Hmm, the R CI failure may be related as it seems to succeed on git main:
https://github.com/apache/arrow/actions/runs/4937417890/jobs/8826087049

[mapleFU]

Yeah, I don't want to rebase this because there are still too much failed tests :-(
Just wait others idea on this patch or merge if you think it's ok

[pitrou]

We can't merge until we make sure the R CI failure is unrelated.

[pitrou]

Hmm, actually the segfault is already known:
#35391

[mapleFU]

😭Hurt by so many failed

[mapleFU]

[ RUN ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r
unknown file: error: SEH exception with code 0xc00000fd thrown in the test body.
[ FAILED ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r, where GetParam() = Threaded16b1024r (314 ms)

I guess this is unrelated. https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/47021836

[mapleFU]

@pitrou Seems R failed is not related. Would you mind take a look?

[pitrou]

I'm restarting CI a last time but it looks like this is ready to go.

[ursabot]

Benchmark runs are scheduled for baseline = e2e3a9d and contender = 2d76d9a. 2d76d9a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.26% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.51% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.42% ⬆️0.03%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 2d76d9a5 ec2-t3-xlarge-us-east-2
[Finished] 2d76d9a5 test-mac-arm
[Finished] 2d76d9a5 ursa-i9-9960x
[Finished] 2d76d9a5 ursa-thinkcentre-m75q
[Finished] e2e3a9df ec2-t3-xlarge-us-east-2
[Finished] e2e3a9df test-mac-arm
[Finished] e2e3a9df ursa-i9-9960x
[Finished] e2e3a9df ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

[mapleFU]

Rationale for this change

Mentioned in #35519

What changes are included in this PR?

Exception handling in CheckRowsWritten

Are these changes tested?

No, I don't know how to mock it currently

Are there any user-facing changes?

no

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[github-actions]

• Closes: [C++][Parquet] Segfault when exception handling and closing RowGroupSerializer #35519

[mapleFU]

@pitrou Would you mind take a look? Analyze is in #35519 (comment)

[github-actions]

⚠️ GitHub issue #35519has been automatically assigned in GitHub to PR creator.

[pitrou]

I think we should instead prevent RowGroupSerializer::Close from creating an invalid internal state. For example:

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
auto column_writers = std::move(columns_writers_);
for (constauto writer : column_writers) {
if (writer) {
total_bytes_written_ += writer->Close();
total_compressed_bytes_written_ +=
writer->total_compressed_bytes_written();
}
}
// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

[mapleFU]

@pitrou Good Idea! Fix as your advice

[pitrou]

Good catch!

[wgtmac]

Suggested change

	// If ColumnWriter::Close thrown an exception, avoid
	// have bad states in column_writers_.
	// Avoid invalid state if ColumnWriter::Close() throws internally.

[wgtmac]

If anything wrong happens here, should we let the FileSerializer know that it cannot accept any write any more?

[mapleFU]

it's already closed, whether success or not, no any write can comes to RowGroupSerializer. I guess it will cause FileSerializer destruct

[wgtmac]

This is true if the exception happens when calling FileSerializer::Close(). What if this happens when the user directly calls RowGroupWriter::Close() to close the current row group and starts a new one?

[mapleFU]

voidClose() override {
if (!closed_) {
closed_ = true;
CheckRowsWritten();
// ...// Ensures all columns have been written
metadata_->set_num_rows(num_rows_);
metadata_->Finish(total_bytes_written_, row_group_ordinal_);
}
}

I guess it will mark closed_ first and throw exception. During stack unwind, the RowGroupSerializer will destruct. And during next time Close is called, it will do nothing

[mapleFU]

Comment resolved. I tried to solve some CI problems here: #35527

Seems CI failed frequently these days...

[pitrou]

Seems CI failed frequently these days...

Unfortunately :-( Are there issues already open for these failures?

[pitrou]

Thanks @mapleFU . This looks ok now.

[pitrou]

Hmm, the R CI failure may be related as it seems to succeed on git main:
https://github.com/apache/arrow/actions/runs/4937417890/jobs/8826087049

[mapleFU]

Yeah, I don't want to rebase this because there are still too much failed tests :-(
Just wait others idea on this patch or merge if you think it's ok

[pitrou]

We can't merge until we make sure the R CI failure is unrelated.

[pitrou]

Hmm, actually the segfault is already known:
#35391

[mapleFU]

😭Hurt by so many failed

[mapleFU]

[ RUN ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r
unknown file: error: SEH exception with code 0xc00000fd thrown in the test body.
[ FAILED ] TestScan/TestCsvFileFormatScan.ScanBatchSize/0Threaded16b1024r, where GetParam() = Threaded16b1024r (314 ms)

I guess this is unrelated. https://ci.appveyor.com/project/ApacheSoftwareFoundation/arrow/builds/47021836

[mapleFU]

@pitrou Seems R failed is not related. Would you mind take a look?

[pitrou]

I'm restarting CI a last time but it looks like this is ready to go.

[ursabot]

Benchmark runs are scheduled for baseline = e2e3a9d and contender = 2d76d9a. 2d76d9a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Finished ⬇️0.0% ⬆️0.0%] ec2-t3-xlarge-us-east-2
[Finished ⬇️0.26% ⬆️0.0%] test-mac-arm
[Finished ⬇️0.51% ⬆️0.0%] ursa-i9-9960x
[Finished ⬇️0.42% ⬆️0.03%] ursa-thinkcentre-m75q
Buildkite builds:
[Finished] 2d76d9a5 ec2-t3-xlarge-us-east-2
[Finished] 2d76d9a5 test-mac-arm
[Finished] 2d76d9a5 ursa-i9-9960x
[Finished] 2d76d9a5 ursa-thinkcentre-m75q
[Finished] e2e3a9df ec2-t3-xlarge-us-east-2
[Finished] e2e3a9df test-mac-arm
[Finished] e2e3a9df ursa-i9-9960x
[Finished] e2e3a9df ursa-thinkcentre-m75q
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java