zeroshade commented on code in PR #34631:
URL: https://github.com/apache/arrow/pull/34631#discussion_r1158685566
##########
go/parquet/pqarrow/encode_arrow_test.go:
##########
@@ -1517,6 +1531,24 @@ func (ps *ParquetIOTestSuite)
TestArrowMapTypeRoundTrip() {
ps.roundTripTable(tbl, true)
}
+func (ps *ParquetIOTestSuite) TestArrowExtensionTypeRoundTrip() {
+ var testUUID = uuid.New()
Review Comment:
you can muck with the env vars `ARROW_CHECKED_ALLOC_FRAMES` and
`ARROW_CHECKED_REALLOC_FRAMES` (which default to `4` and `3` respectively) when
running the tests. They control how many stack frames up are used to print out
the location of the allocation that leaked. By increasing those you can
pinpoint which allocation of memory is leaking which can help identify the leak.
You can also step through with the debugger and watch the ref counts of the
record/array/data objects respectively to ensure the ref counting goes up and
down appropriately.
Most likely there's a case where a new array is being created, or a new
ChunkedArray is being created and the original sources aren't getting released
(since `NewData`, `NewChunked`, and `MakeFromData` all call retain on their
arguments to ensure they don't get wiped out from below them).
--
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]
