DO NOT MERGE: Try to reproduce wheel failures

[lidavidm]

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[github-actions]

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

In the case of PARQUET issues on JIRA the title also supports:

PARQUET-${JIRA_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - How to contribute patches

[lidavidm]

@github-actions crossbow submit wheel-manylinux2014-*-amd64

[github-actions]

Revision: 5d2bce6

Submitted crossbow builds: ursacomputing/crossbow @ actions-f3e3650a1c

Task	Status
wheel-manylinux2014-cp310-amd64
wheel-manylinux2014-cp311-amd64
wheel-manylinux2014-cp37-amd64
wheel-manylinux2014-cp38-amd64
wheel-manylinux2014-cp39-amd64

[lidavidm]

@github-actions crossbow submit wheel-manylinux2014-*-amd64

[github-actions]

Revision: dc01372

Submitted crossbow builds: ursacomputing/crossbow @ actions-89f91f1eb7

Task	Status
wheel-manylinux2014-cp310-amd64
wheel-manylinux2014-cp311-amd64
wheel-manylinux2014-cp37-amd64
wheel-manylinux2014-cp38-amd64
wheel-manylinux2014-cp39-amd64

[jorisvandenbossche]

For the faulthandler part, I tried this a while ago as well to debug some other segfault in CI, and my conclusion then was that pytest nowadays already does that by default: https://docs.pytest.org/en/7.1.x/how-to/failures.html#faulthandler

[lidavidm]

Hmm, interesting, because I don't actually see the traceback in past runs. Possibly there is no Python-side traceback then, in which case hopefully catchsegv grabs it.

[jorisvandenbossche]

Yeah, also from local development, my experience is that enabling the python faulthandler module most of the time doesn't actually result in more information being printed (at least when developing arrow, unless I am all the time using it wrongly)

[lidavidm]

Ah right, now I remember why catchsegv isn't great. We're building in release mode...

Backtrace:
/usr/local/lib/python3.9/site-packages/pyarrow/libarrow.so.1100(+0x17b5bb7)[0x7fed49842bb7]
/usr/local/lib/python3.9/site-packages/pyarrow/libarrow.so.1100(+0x17a1d83)[0x7fed4982ed83]
/usr/local/lib/python3.9/site-packages/pyarrow/libarrow.so.1100(+0x591c6a)[0x7fed4861ec6a]
/usr/local/lib/python3.9/site-packages/pyarrow/libarrow.so.1100(+0x16d882f)[0x7fed4976582f]
/usr/local/lib/python3.9/site-packages/pyarrow/libarrow.so.1100(+0x591c6a)[0x7fed4861ec6a]
/usr/local/lib/python3.9/site-packages/pyarrow/libarrow.so.1100(+0x12d5a94)[0x7fed49362a94]
/usr/local/lib/python3.9/site-packages/pyarrow/libarrow.so.1100(+0x591c6a)[0x7fed4861ec6a]
/lib/x86_64-linux-gnu/libc.so.6(+0x3b4d7)[0x7fed4c6c94d7]
/lib/x86_64-linux-gnu/libc.so.6(+0x3b67a)[0x7fed4c6c967a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fed4c6b1d11]
python(_start+0x2a)[0x559a27a1508a]

[lidavidm]

Reconstructed backtrace on #15054