From user-return-634-archive-asf-public=cust-asf.ponee.io@arrow.apache.org Mon Aug 24 00:55:33 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mailroute1-lw-us.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with ESMTPS id 39F91180636 for ; Mon, 24 Aug 2020 02:55:33 +0200 (CEST) Received: from mail.apache.org (localhost [127.0.0.1]) by mailroute1-lw-us.apache.org (ASF Mail Server at mailroute1-lw-us.apache.org) with SMTP id 40694124381 for ; Mon, 24 Aug 2020 00:55:32 +0000 (UTC) Received: (qmail 40732 invoked by uid 500); 24 Aug 2020 00:48:51 -0000 Mailing-List: contact user-help@arrow.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@arrow.apache.org Delivered-To: mailing list user@arrow.apache.org Received: (qmail 40717 invoked by uid 99); 24 Aug 2020 00:48:51 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Aug 2020 00:48:51 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id C4F891A4218 for ; Mon, 24 Aug 2020 00:48:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id nLNlvnsDE6MA for ; Mon, 24 Aug 2020 00:48:48 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::841; helo=mail-qt1-x841.google.com; envelope-from=niyue.com@gmail.com; receiver= Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 7F9B47D228 for ; Mon, 24 Aug 2020 00:48:47 +0000 (UTC) Received: by mail-qt1-x841.google.com with SMTP id p36so1744708qtd.12 for ; Sun, 23 Aug 2020 17:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mDm/La5EZCBCJ5TxQKCdTLkEV9llfPQTKLhM6q4sWVg=; b=tby8iKm1hw/5jm6G7RJCOhTKTEoCKHdGErW2YSwAubkLVlEuySST6V9m1UkN/plcaC WyS6r9GF+RqiLwrgenV8l93Pk/CSQyAxeLGoNNT19dXmpRhskdAAEelDR+ccdxZZG0sJ RohHDtLYxuFJf9/bFyY1cMsFddtgs2Od6d5RfABCJKHAqWFgnUR/aCuKCoxvJrqUtTK2 Ziv9CutXjxMGzkozPcgy8thQLACUVRgvfmLqKP+OpVNTUS5Z4DLV/eCdLI/HLRf5tVDu 9z8ne/kRuTOwXc+S4NYJ8C02XthKkuf2FedArT5wdfdk0YaK/Hy8QkWpS8RKf8vM2s2Z +rwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mDm/La5EZCBCJ5TxQKCdTLkEV9llfPQTKLhM6q4sWVg=; b=HJp3bi88ilUtR0nkWKckR/tsJB7ivztcmqk1Bt9Wg3bDWvrvCR5I8qhtQGMxRuBgL3 gxxkp5eULUI2xLfJwUNSZadCBXPViVKpG/iHFIg4RgU+18tUzZp5GedD/4foqslGzwWp S56nVOCIynpF45ld2YwRS0aQvrZ6dh728bVk3dYOSB41Jwljq9/9gmDgmTsdB85EUphm /hutAdNl8XNu0fkzcXn1o+FO8FqOyDNe9CiDwobBYqHJ5csUswTMElaKFXsxYagOdMvd FDzsTHhZsb2hgaIIFg1JZ5QYEDF0AOziCXR2YmpZ+oAmxxQQOk1sx3msrZHKrD7nVQW6 bIlw== X-Gm-Message-State: AOAM533qZ7LmbMAcsVUJ02o+2/VO0BilUuwdQwlyttYm4S0G2gBSqLC6 6i3aX+KylMd86n736zFLV0/Ak8BFY80Olr49n0xyWuDXm/9vBEPI X-Google-Smtp-Source: ABdhPJwbhr2LDPh5CZIKLpAXJ8RLwuxAeFlVQCsQEWIZ6naYNN8w84kt773HJvJUxNsAQVsI+LhTY7FnpkKZ8bOlfyU= X-Received: by 2002:aed:3948:: with SMTP id l66mr726266qte.44.1598230126018; Sun, 23 Aug 2020 17:48:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yue Ni Date: Mon, 24 Aug 2020 08:48:10 +0800 Message-ID: Subject: Re: pyarrow + pybind11 segfault under Linux To: user@arrow.apache.org Content-Type: multipart/alternative; boundary="000000000000ee460005ad94f2aa" --000000000000ee460005ad94f2aa Content-Type: text/plain; charset="UTF-8" Thanks Wes. I should make it more clear, and I did check the status and validate the table previously, and the table can be validated successfully by calling `ValidateFull`. Previously I removed them all but in order to make the demonstration code shorter. Here is the same code with more status checked and info logged: ``` pybind11::object generate(const int32_t count) { _logger->info("generate_table"); shared_ptr array; arrow::Int64Builder builder; for (auto i = 0; i < count; i++) { auto status = builder.Append(i); if (!status.ok()) { _logger->error("failed_to_append_value"); } } auto array_status = builder.Finish(&array); if (!array_status.ok()) { _logger->error("failed_to_build_array"); } auto record_batch = RecordBatch::Make( arrow::schema(vector{arrow::field("int_value", arrow::int64())}), count, vector{array}); auto table = arrow::Table::FromRecordBatches(vector{record_batch}).ValueOrDie(); auto table_status = table->ValidateFull(); if (!table_status.ok()) { _logger->error("failed_to_validate_table"); } else { _logger->info("table_validated_successfully"); } auto result = arrow::py::import_pyarrow(); if (result == 0) { _logger->info("pyarrow_successfully_imported"); } else { _logger->error("failed_to_import_pyarrow"); } auto wrapped_table = pybind11::reinterpret_borrow(pybind11::handle(arrow::py::wrap_table(table))); return wrapped_table; ``` Here is the output when I run it under Debian Bullseye (inside a Docker container) + Python 3.8.5: ``` >>> table = binding.generate(100) [2020-08-24T08:29:27.035650+08:00] [info] [2172] [2172] [pyland] msg="generate_table" [2020-08-24T08:29:27.040507+08:00] [info] [2172] [2172] [pyland] msg="table_validated_successfully" [2020-08-24T08:29:27.312662+08:00] [info] [2172] [2172] [pyland] msg="pyarrow_successfully_imported" >>> print(table.num_rows) 100 >>> print(table.shape) (100, 1) >>> print(table.num_columns) 1 >>> print(table.column_names) [''] >>> print(table.columns) Segmentation fault ``` I think the problem may happen in the last two lines, either wrapping the table is problematic or converting the wrapped table into a python object is problematic, but I am far from understanding what happens under the hood, and there could be other reasons I am missing. On Sun, Aug 23, 2020 at 11:07 PM Wes McKinney wrote: > There are a lot of unchecked Statuses in your code. I would suggest > checking them all and additionally adding a (checked!) call to > Validate() or ValidateFull() to make sure that everything is well > formed (it seems like it should be, but this is a pre-requisite before > debugging further) > > On Sun, Aug 23, 2020 at 1:27 AM Yue Ni wrote: > > > > Hi there, > > > > I tried to create a Python binding our Apache Arrow C++ based program, > and used pybind11 and pyarrow wrapping code to do it. For some reason, the > code works on macOS however it causes segfault under Linux. > > > > I created a minimum test case to reproduce this behavior, is there > anyone who can help to take a look at what may go wrong here? > > > > Here is the C++ code for creating the binding (it simply generates a > fixed size array and puts it into record batch and then creates a table) > > ``` > > pybind11::object generate(const int32_t count) { > > shared_ptr array; > > arrow::Int64Builder builder; > > for (auto i = 0; i < count; i++) { > > auto _ = builder.Append(i); > > } > > auto _ = builder.Finish(&array); > > auto record_batch = RecordBatch::Make( > > arrow::schema(vector{arrow::field("int_value", arrow::int64())}), > count, vector{array}); > > auto table = > arrow::Table::FromRecordBatches(vector{record_batch}).ValueOrDie(); > > auto result = arrow::py::import_pyarrow(); > > auto wrapped_table = pybind11::reinterpret_borrow( > > pybind11::handle(arrow::py::wrap_table(table))); > > return wrapped_table; > > } > > ``` > > > > Here is the python code that uses the binding (it calls the binding to > generate a 100-length single column table, and print the number of rows and > table schema). > > ``` > > table = binding.generate(100) > > >>> print(table.num_rows) # this works correctly > > 100 > > >>> print(table.shape) # this works correctly > > (100, 1) > > >>> print(table.num_columns) # this works correctly > > 1 > > >>> print(table.column_names) # this prints an empty list, which is > incorrect, but the program still runs > > [''] > > >>> print(table.columns) # this causes the segfault > > Segmentation fault (core dumped) > > ``` > > > > The same code works completely fine and correct on macOS (Apple clang > 11, Python 3.7.5, arrow 1.0.0 C++ lib, pyarrow 1.0.0), but it doesn't work > on Debian bullseye (gcc 10.2.0, Python 3.8.5, arrow 1.0.1 C++ lib, pyarrow > 1.0.1). I tried switching to some combinations of Python 3.7.5 and > arrow/pyarrow 1.0.0 as well, but none of them works for me. > > > > I got the core dump and use gdb for some simple debugging, and it seems > the segfault happened when pyarrow tried to call `pyarrow_wrap_data_type` > when doing `Field.init`. > > > > Here is the core dump: > > ``` > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Core was generated by `python3'. > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x00007f604ea484cc in __pyx_f_7pyarrow_3lib_pyarrow_wrap_data_type > () from /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > [Current thread is 1 (Thread 0x7f60550bc740 (LWP 2205))] > > (gdb) where > > #0 0x00007f604ea484cc in __pyx_f_7pyarrow_3lib_pyarrow_wrap_data_type > () from /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #1 0x00007f604eb05df0 in > __pyx_f_7pyarrow_3lib_5Field_init(__pyx_obj_7pyarrow_3lib_Field*, > std::shared_ptr const&) () from > /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #2 0x00007f604ea35d80 in __pyx_f_7pyarrow_3lib_pyarrow_wrap_field () > from /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #3 0x00007f604ea68c8f in > __pyx_pw_7pyarrow_3lib_6Schema_28_field(_object*, _object*) () from > /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #4 0x00007f604ea69595 in __Pyx_PyObject_CallOneArg(_object*, _object*) > () from /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #5 0x00007f604ea755de in > __pyx_pw_7pyarrow_3lib_6Schema_7__getitem__(_object*, _object*) () from > /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #6 0x00007f604ea476f0 in __pyx_sq_item_7pyarrow_3lib_Schema(_object*, > long) () from /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #7 0x00007f604ead554e in > __pyx_pw_7pyarrow_3lib_5Table_55_column(_object*, _object*) () from > /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #8 0x00007f604ea69595 in __Pyx_PyObject_CallOneArg(_object*, _object*) > () from /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #9 0x00007f604ea8c8df in > __pyx_getprop_7pyarrow_3lib_5Table_columns(_object*, void*) () from > /usr/local/lib/python3.8/dist-packages/pyarrow/ > lib.cpython-38-x86_64-linux-gnu.so > > #10 0x000000000051bafa in ?? () > > #11 0x0000000000518b3f in _PyObject_GenericGetAttrWithDict () > > #12 0x0000000000505509 in _PyEval_EvalFrameDefault () > > #13 0x0000000000503b25 in _PyEval_EvalCodeWithName () > > #14 0x00000000005ce503 in PyEval_EvalCode () > > #15 0x00000000005ec461 in ?? () > > #16 0x00000000005e7a5f in ?? () > > #17 0x000000000045b2dc in ?? () > > #18 0x000000000045aee5 in PyRun_InteractiveLoopFlags () > > #19 0x00000000005ef745 in PyRun_AnyFileExFlags () > > #20 0x000000000044ddde in ?? () > > #21 0x00000000005c3899 in Py_BytesMain () > > #22 0x00007f60550e5cca in __libc_start_main (main=0x5c3860
, > argc=1, argv=0x7fffc5992db8, init=, fini=, > rtld_fini=, stack_end=0x7fffc5992da8) at > ../csu/libc-start.c:308 > > #23 0x00000000005c379a in _start () > > ``` > > > > Due to the complexity of the C++/Python conversion, I've no idea if this > is an issue of pyarrow or Cython or pybind11 in this case. Is there anyone > who can shed some light on it or how I can troubleshoot such an issue? > Thanks. > > > > Regards, > > Yue > > > --000000000000ee460005ad94f2aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks = Wes. I should make it more clear, and I did check the status and validate t= he table previously, and the table can be validated successfully by calling= `ValidateFull`. Previously I removed them all=C2=A0but in order to make th= e demonstration code shorter.

Here is the same code with= more status checked and info logged:
```
pybind11::= object generate(const int32_t count) {
=C2=A0 _logger->info(&q= uot;generate_table");
=C2=A0 shared_ptr<arrow::Array> = array;
=C2=A0 arrow::Int64Builder builder;
=C2=A0 for (= auto i =3D 0; i < count; i++) {
=C2=A0 =C2=A0 auto status =3D = builder.Append(i);
=C2=A0 =C2=A0 if (!status.ok()) {
= =C2=A0 =C2=A0 =C2=A0 _logger->error("failed_to_append_value");=
=C2=A0 =C2=A0 }
=C2=A0 }
=C2=A0 auto array_s= tatus =3D builder.Finish(&array);
=C2=A0 if (!array_status.ok= ()) {
=C2=A0 =C2=A0 _logger->error("failed_to_build_array= ");
=C2=A0 }

=C2=A0 auto record_bat= ch =3D RecordBatch::Make(
=C2=A0 =C2=A0 =C2=A0 arrow::schema(vect= or{arrow::field("int_value", arrow::int64())}), count, vector{arr= ay});
=C2=A0 auto table =3D arrow::Table::FromRecordBatches(vecto= r{record_batch}).ValueOrDie();
=C2=A0 auto table_status =3D table= ->ValidateFull();
=C2=A0 if (!table_status.ok()) {
= =C2=A0 =C2=A0 _logger->error("failed_to_validate_table");
=C2=A0 } else {
=C2=A0 =C2=A0 _logger->info("table_= validated_successfully");
=C2=A0 }
=C2=A0 auto res= ult =3D arrow::py::import_pyarrow();
=C2=A0 if (result =3D=3D 0) = {
=C2=A0 =C2=A0 _logger->info("pyarrow_successfully_impor= ted");
=C2=A0 } else {
=C2=A0 =C2=A0 _logger->e= rror("failed_to_import_pyarrow");
=C2=A0 }
= =C2=A0 auto wrapped_table =3D pybind11::reinterpret_borrow<pybind11::obj= ect>(pybind11::handle(arrow::py::wrap_table(table)));
=C2=A0 r= eturn wrapped_table;
```

Her= e is the output when I run it under Debian Bullseye (inside a Docker contai= ner) + Python 3.8.5:
```
>>> table =3D bi= nding.generate(100)
[2020-08-24T08:29:27.035650+08:00] [info] [21= 72] [2172] [pyland] msg=3D"generate_table"
[2020-08-24T= 08:29:27.040507+08:00] [info] [2172] [2172] [pyland] msg=3D"table_vali= dated_successfully"
[2020-08-24T08:29:27.312662+08:00] [info= ] [2172] [2172] [pyland] msg=3D"pyarrow_successfully_imported"
>>> print(table.num_rows)
100
>>= > print(table.shape)
(100, 1)
>>> print(tab= le.num_columns)
1
>>> print(table.column_names= )
['']
>>> print(table.columns)
<= div>Segmentation fault
```

I think= the problem may happen in the last two lines, either wrapping the table is= problematic or converting the wrapped table into a python object is proble= matic, but I am far from understanding what happens under the hood, and the= re could be other reasons I am missing.

On Sun, Aug = 23, 2020 at 11:07 PM Wes McKinney <wesmckinn@gmail.com> wrote:
There are a = lot of unchecked Statuses in your code. I would suggest
checking them all and additionally adding a (checked!) call to
Validate() or ValidateFull() to make sure that everything is well
formed (it seems like it should be, but this is a pre-requisite before
debugging further)

On Sun, Aug 23, 2020 at 1:27 AM Yue Ni <niyue.com@gmail.com> wrote:
>
> Hi there,
>
> I tried to create a Python binding our Apache Arrow C++ based program,= and used pybind11 and pyarrow wrapping code to do it. For some reason, the= code works on macOS however it causes segfault under Linux.
>
> I created a minimum test case to reproduce this behavior, is there any= one who can help to take a look at what may go wrong here?
>
> Here is the C++ code for creating the binding (it simply generates a f= ixed size array and puts it into record batch and then creates a table)
> ```
> pybind11::object generate(const int32_t count) {
>=C2=A0 =C2=A0shared_ptr<arrow::Array> array;
>=C2=A0 =C2=A0arrow::Int64Builder builder;
>=C2=A0 =C2=A0for (auto i =3D 0; i < count; i++) {
>=C2=A0 =C2=A0 =C2=A0auto _ =3D builder.Append(i);
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0auto _ =3D builder.Finish(&array);
>=C2=A0 =C2=A0auto record_batch =3D RecordBatch::Make(
>=C2=A0 =C2=A0 =C2=A0 =C2=A0arrow::schema(vector{arrow::field("int_= value", arrow::int64())}), count, vector{array});
>=C2=A0 =C2=A0auto table =3D arrow::Table::FromRecordBatches(vector{reco= rd_batch}).ValueOrDie();
>=C2=A0 =C2=A0auto result =3D arrow::py::import_pyarrow();
>=C2=A0 =C2=A0auto wrapped_table =3D pybind11::reinterpret_borrow<pyb= ind11::object>(
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pybind11::handle(arrow::py::wrap_table(table= )));
>=C2=A0 =C2=A0return wrapped_table;
> }
> ```
>
> Here is the python code that uses the binding (it calls the binding to= generate a 100-length single column table, and print the number of rows an= d table schema).
> ```
> table =3D binding.generate(100)
> >>> print(table.num_rows) # this works correctly
> 100
> >>> print(table.shape) # this works correctly
> (100, 1)
> >>> print(table.num_columns) # this works correctly
> 1
> >>> print(table.column_names) # this prints an empty list, wh= ich is incorrect, but the program still runs
> ['']
> >>> print(table.columns) # this causes the segfault
> Segmentation fault (core dumped)
> ```
>
> The same code works completely fine and correct on macOS (Apple clang = 11, Python 3.7.5, arrow 1.0.0 C++ lib, pyarrow 1.0.0), but it doesn't w= ork on Debian bullseye (gcc 10.2.0, Python 3.8.5, arrow 1.0.1 C++ lib, pyar= row 1.0.1). I tried switching to some combinations of Python 3.7.5 and arro= w/pyarrow 1.0.0 as well, but none of them works for me.
>
> I got the core dump and use gdb for some simple debugging, and it seem= s the segfault happened when pyarrow tried to call `pyarrow_wrap_data_type`= when doing `Field.init`.
>
> Here is the core dump:
> ```
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_= db.so.1".
> Core was generated by `python3'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0=C2=A0 0x00007f604ea484cc in __pyx_f_7pyarrow_3lib_pyarrow_wrap_data= _type () from /usr/local/lib/python3.8/dist-packages/pyarrow/lib.cpython-38-x86_64-linux-gnu.so
> [Current thread is 1 (Thread 0x7f60550bc740 (LWP 2205))]
> (gdb) where
> #0=C2=A0 0x00007f604ea484cc in __pyx_f_7pyarrow_3lib_pyarrow_wrap_data= _type () from /usr/local/lib/python3.8/dist-packages/pyarrow/lib.cpython-38-x86_64-linux-gnu.so
> #1=C2=A0 0x00007f604eb05df0 in __pyx_f_7pyarrow_3lib_5Field_init(__pyx= _obj_7pyarrow_3lib_Field*, std::shared_ptr<arrow::Field> const&) = () from /usr/local/lib/python3.8/dist-packages/pyarrow/lib.= cpython-38-x86_64-linux-gnu.so
> #2=C2=A0 0x00007f604ea35d80 in __pyx_f_7pyarrow_3lib_pyarrow_wrap_fiel= d () from /usr/local/lib/python3.8/dist-packages/pyarrow/li= b.cpython-38-x86_64-linux-gnu.so
> #3=C2=A0 0x00007f604ea68c8f in __pyx_pw_7pyarrow_3lib_6Schema_28_field= (_object*, _object*) () from /usr/local/lib/python3.8/dist-packages/pyarrow= /lib.cpython-38-x86_64-linux-gnu.so
> #4=C2=A0 0x00007f604ea69595 in __Pyx_PyObject_CallOneArg(_object*, _ob= ject*) () from /usr/local/lib/python3.8/dist-packages/pyarrow/lib.cpython-38-x86_64-linux-gnu.so
> #5=C2=A0 0x00007f604ea755de in __pyx_pw_7pyarrow_3lib_6Schema_7__getit= em__(_object*, _object*) () from /usr/local/lib/python3.8/dist-packages/pya= rrow/lib.cpython-38-x86_64-linux-gnu.so
> #6=C2=A0 0x00007f604ea476f0 in __pyx_sq_item_7pyarrow_3lib_Schema(_obj= ect*, long) () from /usr/local/lib/python3.8/dist-packages/pyarrow/lib.cpython-38-x86_64-linux-gnu.so
> #7=C2=A0 0x00007f604ead554e in __pyx_pw_7pyarrow_3lib_5Table_55_column= (_object*, _object*) () from /usr/local/lib/python3.8/dist-packages/pyarrow= /lib.cpython-38-x86_64-linux-gnu.so
> #8=C2=A0 0x00007f604ea69595 in __Pyx_PyObject_CallOneArg(_object*, _ob= ject*) () from /usr/local/lib/python3.8/dist-packages/pyarrow/lib.cpython-38-x86_64-linux-gnu.so
> #9=C2=A0 0x00007f604ea8c8df in __pyx_getprop_7pyarrow_3lib_5Table_colu= mns(_object*, void*) () from /usr/local/lib/python3.8/dist-packages/pyarrow= /lib.cpython-38-x86_64-linux-gnu.so
> #10 0x000000000051bafa in ?? ()
> #11 0x0000000000518b3f in _PyObject_GenericGetAttrWithDict ()
> #12 0x0000000000505509 in _PyEval_EvalFrameDefault ()
> #13 0x0000000000503b25 in _PyEval_EvalCodeWithName ()
> #14 0x00000000005ce503 in PyEval_EvalCode ()
> #15 0x00000000005ec461 in ?? ()
> #16 0x00000000005e7a5f in ?? ()
> #17 0x000000000045b2dc in ?? ()
> #18 0x000000000045aee5 in PyRun_InteractiveLoopFlags ()
> #19 0x00000000005ef745 in PyRun_AnyFileExFlags ()
> #20 0x000000000044ddde in ?? ()
> #21 0x00000000005c3899 in Py_BytesMain ()
> #22 0x00007f60550e5cca in __libc_start_main (main=3D0x5c3860 <main&= gt;, argc=3D1, argv=3D0x7fffc5992db8, init=3D<optimized out>, fini=3D= <optimized out>, rtld_fini=3D<optimized out>, stack_end=3D0x7ff= fc5992da8) at ../csu/libc-start.c:308
> #23 0x00000000005c379a in _start ()
> ```
>
> Due to the complexity of the C++/Python conversion, I've no idea i= f this is an issue of pyarrow or Cython or pybind11 in this case. Is there = anyone who can shed some light on it or how I can troubleshoot such an issu= e? Thanks.
>
> Regards,
> Yue
>
--000000000000ee460005ad94f2aa--