[Python] macOS Segfault on Import, Both arm64 and x86_64 #37010
Comments
essandess
changed the title
|
Could you get backtrace by lldb? |
|
Here's the macOS Crash Reporter output. What's the Also, I've tried setting a few more |
|
Here's the lldb tracelldb trace/opt/local/bin/lldb-mp-16
(lldb) command script import pyarrow
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/local/libexec/llvm-16/bin/lldb
1. HandleCommand(command = "command script import pyarrow")
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 libLLVM.dylib 0x0000000113a91c6c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 56
1 libLLVM.dylib 0x0000000113a90c38 llvm::sys::RunSignalHandlers() + 112
2 libLLVM.dylib 0x0000000113a922f8 SignalHandler(int) + 344
3 libsystem_platform.dylib 0x000000018d386a24 _sigtramp + 56
4 libjemalloc.2.dylib 0x000000010f5940e0 je_free_default + 1104
5 libprotobuf.3.21.12.0.dylib 0x000000010f2471f0 google::protobuf::internal::ArenaStringPtr::Destroy() + 56
6 libprotobuf.3.21.12.0.dylib 0x000000010f2d0000 google::protobuf::FileDescriptorProto::SharedDtor() + 144
7 libprotobuf.3.21.12.0.dylib 0x000000010f2d00e4 google::protobuf::FileDescriptorProto::~FileDescriptorProto() + 48
8 libprotobuf.3.21.12.0.dylib 0x000000010f2ea634 google::protobuf::EncodedDescriptorDatabase::Add(void const*, int) + 168
9 libprotobuf.3.21.12.0.dylib 0x000000010f29e878 google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) + 40
10 libprotobuf.3.21.12.0.dylib 0x000000010f3056a8 google::protobuf::(anonymous namespace)::AddDescriptors(google::protobuf::internal::DescriptorTable const*) + 136
11 libprotobuf.3.21.12.0.dylib 0x000000010f3056dc google::protobuf::internal::AddDescriptorsRunner::AddDescriptorsRunner(google::protobuf::internal::DescriptorTable const*) + 24
12 dyld 0x000000018d01c1d8 invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const::$_0::operator()() const + 168
13 dyld 0x000000018d05de94 invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 340
14 dyld 0x000000018d0511a4 invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 528
15 dyld 0x000000018cffc2d8 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 296
16 dyld 0x000000018d0501cc dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 192
17 dyld 0x000000018d05d958 dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 516
18 dyld 0x000000018d01885c dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 448
19 dyld 0x000000018d018c10 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 220
20 dyld 0x000000018d018bec dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 184
21 dyld 0x000000018d018bec dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 184
22 dyld 0x000000018d018bec dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 184
23 dyld 0x000000018d018bec dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 184
24 dyld 0x000000018d018bec dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 184
25 dyld 0x000000018d01c264 dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const::$_1::operator()() const + 112
26 dyld 0x000000018d018d90 dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 304
27 dyld 0x000000018d036d58 dyld4::APIs::dlopen_from(char const*, int, void*) + 1440
28 Python 0x000000010378ae64 _imp_create_dynamic + 616
29 Python 0x00000001036ce5d0 cfunction_vectorcall_FASTCALL + 80
30 Python 0x0000000103760d94 _PyEval_EvalFrameDefault + 50396
31 Python 0x0000000103763424 _PyEval_Vector + 116
32 Python 0x000000010368859c object_vacall + 224
33 Python 0x0000000103688458 PyObject_CallMethodObjArgs + 92
34 Python 0x00000001037873a8 PyImport_ImportModuleLevelObject + 1224
35 Python 0x000000010375b8f0 _PyEval_EvalFrameDefault + 28728
36 Python 0x0000000103753d74 PyEval_EvalCode + 168
37 Python 0x0000000103750174 builtin_exec + 332
38 Python 0x00000001036ce6cc cfunction_vectorcall_FASTCALL_KEYWORDS + 76
39 Python 0x0000000103760d94 _PyEval_EvalFrameDefault + 50396
40 Python 0x0000000103763424 _PyEval_Vector + 116
41 Python 0x000000010368859c object_vacall + 224
42 Python 0x0000000103688458 PyObject_CallMethodObjArgs + 92
43 Python 0x00000001037873a8 PyImport_ImportModuleLevelObject + 1224
44 Python 0x000000010375b8f0 _PyEval_EvalFrameDefault + 28728
45 Python 0x0000000103753d74 PyEval_EvalCode + 168
46 Python 0x00000001037a5d38 run_eval_code_obj + 84
47 Python 0x00000001037a5c9c run_mod + 112
48 Python 0x00000001037a8084 PyRun_StringFlags + 112
49 liblldb.16.0.6.dylib 0x000000010469effc lldb_private::python::runStringMultiLine(llvm::Twine const&, lldb_private::python::PythonDictionary const&, lldb_private::python::PythonDictionary const&) + 120
50 liblldb.16.0.6.dylib 0x00000001046a5838 lldb_private::ScriptInterpreterPythonImpl::ExecuteMultipleLines(char const*, lldb_private::ExecuteScriptOptions const&) + 960
51 liblldb.16.0.6.dylib 0x00000001046ab314 lldb_private::ScriptInterpreterPythonImpl::LoadScriptingModule(char const*, lldb_private::LoadScriptOptions const&, lldb_private::Status&, std::__1::shared_ptr<lldb_private::StructuredData::Object>*, lldb_private::FileSpec) + 2092
52 liblldb.16.0.6.dylib 0x0000000104777158 CommandObjectCommandsScriptImport::DoExecute(lldb_private::Args&, lldb_private::CommandReturnObject&) + 328
53 liblldb.16.0.6.dylib 0x00000001043469c0 lldb_private::CommandObjectParsed::Execute(char const*, lldb_private::CommandReturnObject&) + 484
54 liblldb.16.0.6.dylib 0x000000010433d2e8 lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&) + 2136
55 liblldb.16.0.6.dylib 0x00000001043409a0 lldb_private::CommandInterpreter::IOHandlerInputComplete(lldb_private::IOHandler&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) + 852
56 liblldb.16.0.6.dylib 0x00000001042731a0 lldb_private::IOHandlerEditline::Run() + 304
57 liblldb.16.0.6.dylib 0x0000000104256968 lldb_private::Debugger::RunIOHandlers() + 140
58 liblldb.16.0.6.dylib 0x0000000104341c14 lldb_private::CommandInterpreter::RunCommandInterpreter(lldb_private::CommandInterpreterRunOptions&) + 156
59 liblldb.16.0.6.dylib 0x00000001040a0614 lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 124
60 lldb 0x0000000102ff48e0 Driver::MainLoop() + 2784
61 lldb 0x0000000102ff541c main + 2168
62 dyld 0x000000018cffff28 start + 2236
LLDB diagnostics will be written to /var/folders/2s/r9z6gsps7gn5wd89c0sqs8k80000gq/T/diagnostics-5f4976
Please include the directory content when filing a bug report
Segmentation fault: 11 |
|
Thanks. Could you try disabling jemalloc when you build Apache Arrow C++? |
|
Thank you, that fixes this issue. I'll bump this upstream to |
|
In general, jemalloc is faster than system memory allocator. Apache Arrow C++ uses bundled jemalloc instead of system jemalloc by default. It means that Apache Arrow C++ and Protobuf use different jemalloc in the same process. It may cause this problem. This problem may be solved by using system jemalloc by specifying |
|
Thanks. MacPorts’s |
|
Several people have pointed out that |
Well, it depends. Does this issue still happen if you disable Arrow's jemalloc integration with |
|
Whether this is the same issue or a different one, I am seeing a crash on 'import pyarrow'. But it is a BAD INSTRUCTION crash. Seeing this on both Apple Silicon M1, and Apple Silicon M1 Max. Big Sur and Ventura using the public wheels downloaded via pip. 12.0.1 is the last version that works, 13.0.0, 14.0.0, 14.0.1 and 14.0.2 all crash with the BAD INSTRUCTION. This is not being seen on a M2 Sonoma machine... Are the wheels being built on a M2 machine picking up a higher optimization or processor instruction flag? |
|
@prniii Can you get a low-level traceback like in #37010 (comment) ? |
|
Also this is running under Python.org 's 3.11.5 for macOS. Is this sufficient? |
|
I see that this crash dump may be related to openSSL because I am debugging. Looking at a crash dump file from a Release build, which is an address violation. Will post after I examine the release crash file |
|
@prniii Oops, it seems like running under lldb may produce the wrong traceback according to https://bugzilla.redhat.com/show_bug.cgi?id=1006474 There is something else that you could try:
|
|
Also cc @assignUser |
|
Is this issue being investigated? |
|
@antheus-s If you can reproduce the issue, perhaps you could help us by providing a stack trace of the crash? |
|
Sadly, I am not knowledgable enough in this library to help, I was just curious if anything was still being investigated, as the last reply was from January. I am using pythonnet, a library built upon Apache Arrow to run C# code in Python and vise versa. It currently causes a runtime exception when I try to import any python library. |
|
If it happens when you try to import any Python library, then you should report the issue to pythonnet. |
|
@pitrou, which I did months ago. However, the issue is caused by Apache Arrow, so I am wondering if anyone is working on a fix. |
|
How do you know that the issue is caused by Apache Arrow? Can you point us to an analysis of the issue? |
|
In my conversations with pythonnet contributors, it was explained to me as an issue that is currently fixed in this repo in this commit with a temporary workaround: 7f0c407. I am looking for progress, as I am currently forced to use a different setup for certain development tasks, but like I said, I am not familiar enough with this repository to dive into details. I'm just asking whether there is any ongoing investigation. |
|
Thanks for the pointer @antheus-s ! This does not seem related to Arrow since it occurs when importing any Python module IIUC. Also, now that the pythonnet project has a detailed analysis to work with, hopefully they can devise a reliable solution. |
Describe the bug, including details regarding any error messages, version, and platform.
The
pyarrowpackages create a segfault on import when compiled on macOS boxes. This happens on macOSarm64andx86_64, using (at least) version 12.0.0 and 13.0.0.Context: I am trying to update the MacPorts
apache-arrowports at macports/macports-ports#19664 and discovered this issue. MacPorts uses theapache-arrowbuild instructions and approach in python.rst#build-and-test and python_wheel_macos_build.sh.Behavior:
Component(s)
Python
The text was updated successfully, but these errors were encountered: