GH-51095: [CI][C++] Fix core file detection in run-test.sh

[hiroyuki-sato]

Rationale for this change

In #50934, find was used instead of (ls /tmp | grep $PATTERN) to find core files in a ShellCheck-safe way, but using find can cause a race condition when files or directories under /tmp are removed by another process while find is scanning the directory.

What changes are included in this PR?

This change uses shell globbing instead of find to avoid this issue.

Are these changes tested?

Yes.

Are there any user-facing changes?

No.

• GitHub Issue: [C++] Sporadic test errors in parallel mode #51095

[github-actions]

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

[pitrou]

This seems to fix #51095 for me but I'm not sure why.

If this is just ignoring the error in case of a race condition, it means that in some cases the coredumps might not be detected.

[hiroyuki-sato]

@pitrou

It looks like I misunderstood which part needed to be fixed after looking at this error and the suggested change below it.
#51095 (comment)

find: ‘/tmp/buffered-test-0gzee19x’: Aucun fichier ou dossier de ce nom

means No such file or directory, so the error occurs because it is trying to find /tmp/buffered-test-0gzee19x.

The part I changed is related to files whose names start with core, so my change is not related to this error.

I'll take another careful look.

[hiroyuki-sato]

@kou@pitrou Could you take a look again when you get a chance?

Two of the three CI failures produced core files, so in a sense, it seems to be working as expected.
(Although I think this error needs to be fixed separately.)

ARM64 Ubuntu 22.04 C++
https://github.com/apache/arrow/actions/runs/33577007730/job/100083130605?pr=51121#step:8:7779
https://github.com/apache/arrow/actions/runs/33577007730/job/100083130605?pr=51121#step:8:10298

AMD64 Conda C++ AVX2
https://github.com/apache/arrow/actions/runs/33577007730/job/100083130684?pr=51121#step:8:8257
https://github.com/apache/arrow/actions/runs/33577007730/job/100083130684?pr=51121#step:8:10788

[kou]

Could you call print_coredumps only when the test is failed?

[hiroyuki-sato]

@kou Thank you for your review. Applied suggested change

Could you call print_coredumps only when the test is failed?

Does this mean the following?

if [ "$STATUS"-ne 0 ] ;then
print_coredumps
fi

[pitrou]

Two of the three CI failures produced core files, so in a sense, it seems to be working as expected.
(Although I think this error needs to be fixed separately.)

Wow. We never noticed this before. Do you think those were ignored silently @kou ?

Edit: Ah, it's a ASSERT_DEATH test. Nevermind.

[kou]

+1