Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

c/driver/sqlite: Possible memory leak on ingest #1211

Closed
paleolimbot opened this issue Oct 19, 2023 · 2 comments · Fixed by #1219
Closed

c/driver/sqlite: Possible memory leak on ingest #1211

paleolimbot opened this issue Oct 19, 2023 · 2 comments · Fixed by #1219

Comments

@paleolimbot
Copy link
Member

From the extended R checks added in #1210.

 ==6428== 4,104 bytes in 1 blocks are possibly lost in loss record 679 of 2,839
==6428==    at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==6428==    by 0x204315EA: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==6428==    by 0x20435899: sqlite3Malloc (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==6428==    by 0x20447773: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==6428==    by 0x203CA147: ??? (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==6428==    by 0x20478E8F: sqlite3VdbeExec (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==6428==    by 0x2048781E: sqlite3_step (in /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==6428==    by 0x2037842F: SqliteStatementInitIngest (sqlite.c:1232)
==6428==    by 0x2037865D: SqliteStatementExecuteIngest (sqlite.c:1273)
==6428==    by 0x2037885C: SqliteStatementExecuteQuery (sqlite.c:1316)
==6428==    by 0x1EF468F8: RAdbcStatementExecuteQuery (radbc.cc:515)
==6428==    by 0x495C96D: R_doDotCall (dotcode.c:874)

These tests run on CRAN and I don't see a valgrind error there, so perhaps this can be fixed by forcing use of the vendored SQLite (which is probably a much newer version than that packaged with Ubuntu).
@lidavidm
Copy link
Member

Possibly something similar to https://github.com/SRombauts/SQLiteCpp/issues/309 - maybe we aren't cleaning things up in time at exit?

@paleolimbot
Copy link
Member Author

That's possible...there's a thing about R external pointers and whether or not the finalizer runs on exit and I forget the default is.

@paleolimbot paleolimbot mentioned this issue Oct 23, 2023
Merged
paleolimbot added a commit that referenced this issue Oct 23, 2023
@paleolimbot
fix(r/adbcsqlite): Fix incomplete cleanup in adbcsqlite tests (#1219)
80f87b3 
Closes #1211.

It wasn't an external pointer issue, it was just not cleaning up
properly in some tests. These tests were written before `with_adbc()`
and `local_adbc()`...the tests for all the drivers could be refactored
to use them (but perhaps not today).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(r/adbcsqlite): Fix incomplete cleanup in adbcsqlite tests paleolimbot/arrow-adbc
2 participants
@lidavidm @paleolimbot