Double free?

[ignatz]

Hi Alex, really cool stuff you're doing with sqlite 👏

I had a brief look at this crates and saw a bunch of TODOs, i.e.:

https://github.com/asg017/sqlite-jsonschema/blob/main/src/jsonschema.rs#L74
https://github.com/asg017/sqlite-loadable-rs/blob/2c5c049c0c9e010a70b458fde459facf294befce/src/api.rs#L390

and they surprised me.

AFAICT based on https://sqlite.org/c3ref/get_auxdata.html, you pass sqlite the data and a cleanup function, i.e. sqlite manages that memory.

In other words, there shouldn't be a leak but maybe worse, https://github.com/asg017/sqlite-jsonschema/blob/main/src/jsonschema.rs#L41 is (re-) taking ownership of memory that belongs to sqlite.

I haven't tested it but at first glance this seems rather off. Does that make sense? If so, happy to send you a patch. Let me know what you think.

Best,
Sebastian

[ignatz]

I also just realized that auxdata lives way shorter than i thought, typically until a statement is finalized. I guess that explains why users haven't experienced the double free, i.e. for most use-cases you'll only have misses because sqlite has cleaned house long before a hit erroneously could takes ownership.

I guess that raises the question if compiling/caching even makes sense here or whether one should roll their own global/thread-local cache 🤷

[ignatz]

Closing the loop, I sent asg017/sqlite-loadable-rs#22 your way, which would have prevented this double free (non)issue here.