srvrX0r commented on issue #51393:
URL: https://github.com/apache/arrow/issues/51393#issuecomment-5972214802
| Updates as of 10./08/26
|
|____________ ___________ ________________________________________________|
Hello @all @danielle060821 @marinelay @iliasabk:
After running some debugs, scans, queries and analyzing the repository
workflow pipeline , my analysis on the testing of the initial Bug resulted in
this output:
-> Confirm that pyarrow.arange(-(1 << 63), 0) now raises the expected error
instead of returning <Invalid array: Array length is negative>
-> The knowledge sources do not explicitly mention the exact version or
commit where this behavior was updated, but the output I receiced explains why
no segmentation fault occurred:
I accidentally was running the development build (26.0.0a1.dev...): The
crash in issue #51393 was reported on PyArrow 25.0.1. By cloning and building
from the main branch, I accidentally build ver. 26.0.0.-dev. (force-of-habit
from DEV ENVs, my bad).
Howeve,r , the crash has been avoided: Instead of terminating with SIGSEGV,
the operation completed and returned:
`<Invalid array: Array length is negative>`
According to the issue description and the documentation for pyarrow.arange,
the function is expected to raise an exception—such as an ArrowInvalid error,
rather than returning an invalid, malformed array object in Python
[pyarrow.arange](https://arrow.apache.org/docs/python/generated/pyarrow.arange.html)
. Returning an invalid array object <Invalid array: Array length is
negative> rather than raising a Python exception might still be considered
incorrect behavior or an unhandled boundary condition.
-> Because 0 - (-2^63) overflows a signed 64-bit integer into a negative
value, Arrow detected that the calculated length is invalid/negative rather
than attempting an illegal memory allocation or out-of-bounds write.
Because the process does not terminate with SIGSEGV here, running it under
gdb exits normally with No stack.
I have noticed that @liasabk added 2 commits on Sept 19, 2026 upon noticing
the bug and engaged in the responding to the event. The provided knowledge
sources do not contain specific information about the code changes in those
files for issue #51393. However, based on Apache Arrow's standard development
workflow and component layout, those target files align directly with how such
an issue is resolved:
Commit 1): Implementation through
(python/pyarrow/src/arrow/python/util.cc):
- > This C++ source file handles underlying Python/C++ utility logic and
kernel conversions.
-> Modifying it to fix the signed 64-bit integer overflow prevents negative
or overflowing range-length computations and allows Arrow to return a
descriptive failure status rather than proceeding with an invalid length.
Commit 2): Regression Tests (python/pyarrow/tests/test_array.py):
- > When contributing bug fixes to Arrow, developers are required to add
unit tests covering the edge cases .
- > [Pull request and
review](https://arrow.apache.org/docs/developers/overview.html#pull-request-and-review)
.-> Adding test cases here ensures that boundary inputs, such as extreme
negative starts or large ranges, properly raise the expected exception (like
ArrowInvalid .
->
[pyarrow.arange](https://arrow.apache.org/docs/python/generated/pyarrow.arange.html)
) and will prevent regressions in the test suite .
According to the issue description and the documentation for pyarrow.arange,
the function is expected to raise an exception—such as an ArrowInvalid error,
athother than returning an invalid, malformed array object in Python .
[pyarrow.arange](https://arrow.apache.org/docs/python/generated/pyarrow.arange.html)
. Returning an invalid array object <Invalid array: Array length is
negative> rather than raising a Python exception might still be considered
incorrect behavior or an unhandled boundary condition.
-> [Adding a test]
(https://arrow.apache.org/docs/developers/guide/tutorials/python_tutorial.html#adding-a-test)
In Summary: Since an Initial Commit followed by because those commits
contain both the core implementation fix and the regression tests, the solution
is already being handled in that contributor's branch.
To help move the issue forward according to the Arrow review guidelines :
- > [Pull request and
review](https://arrow.apache.org/docs/developers/overview.html#pull-request-and-review)
- > Check out the contributor's branch locally
- > Recompile PyArrow and run the test suite for array tests (e.g., using
pytest pyarrow/t.
I will continue debugging and attempting to resolve this bug.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
