Freeing sqlite3_module after registering
(1) By anonymous on 2020-12-01 03:42:01 [source]
When registering a module via
sqlite3_create_module_v2, is it safe to free the memory being used for the name and
sqlite3_module arguments after the call returns? Or does the memory need to remain valid until the module is dropped? https://www.sqlite.org/c3ref/create_module.html
(2) By jake on 2020-12-01 04:26:09 in reply to 1 [link] [source]
It looks like SQLite makes a copy of the name, so it should be safe to free after registering the module. Generally though the module name would be a constant.
sqlite3_module should not be freed as per the docs (https://www.sqlite.org/c3ref/module.html):
The content of this structure must not change while it is registered with any database connection.
(3) By anonymous on 2020-12-01 04:36:36 in reply to 2 [link] [source]
Thanks! As a follow up, is it safe to have the destructor function (i.e.,
xDestroy) free the memory of the
sqlite3_module struct? Or does it need to remain valid even during that call?
(4) By Keith Medcalf (kmedcalf) on 2020-12-01 05:32:06 in reply to 3 [link] [source]
Apply this new-fangled thing called LOGIC.
What is it that is being destroyed? Is that the thing you are destroying?
This should answer your question with no further possible confusion.
But in case you are still confused and unable to apply logic, are you "destroying" the entire module, or a "connection" to a module?
If you are destroying a "connection" to a module then you should be destroying things related to that "connection" to a module, but not the module itself. On the gripping hand, if you are destroying "the module itself" and there is still a "connection" to the module, then you should throw up your arms in disgust (ie, throw an error).
To express this alternately, a module provides a FACTORY for CONNECTIONS to a module. You can consider the FACTORY to be something like a Ford car factory. The FACTORY provides an interface for the creation and destruction of CARS, not factories. Why on earth when requested to demolish a car made in your factory would you think the appropriate response is to blow up the factory?
(5) By jake on 2020-12-01 05:36:08 in reply to 3 [link] [source]
xDestroy param of
sqlite3_create_module_v2 is the destructor for
xDestroy just before dereferencing the internal module object, so you could theoratically pass your module structure as the
pClientData to be cleaned up by your
Note: this information is being provided from a quick analysis of the source code, not from experience or an officially documented reference.
(6) By anonymous on 2020-12-01 15:34:31 in reply to 4 [link] [source]
I was referring to the
xDestroy parameter of
sqlite3_create_module_v2, not the field of
sqlite3_module. The documentation describes it in terms of destroying
pClientData, but it is unclear if it is acceptable for it to destroy the
(7) By Gunter Hick (gunter_hick) on 2020-12-02 06:38:38 in reply to 6 [link] [source]
Why do you need to destroy the sqlite3_module structure? Are you really building it in heap memory at runtime instead of putting it into static initialized memory and letting the compiler and loader handle it? What is the rationale behind making the method table and the methods go out of scope at all (if you need them once, you are very likely to need them again), let alone independently?
(8) By anonymous on 2020-12-02 16:27:22 in reply to 7 [link] [source]
I am interfacing with SQLite using another programming language via a wrapper library. Due to the rules and restrictions of the foreign function interface, attempting to put a statically initialized
sqlite3_module object in user code and pass it into the library would be extremely cumbersome, so it makes much more sense for the library to construct this object instead. Of course, the library is generic, so attempting to use a static C object has its own complications. For this reason I am wondering if the library can just
malloc the module object, but then the question is when it is safe to
(9.1) By Keith Medcalf (kmedcalf) on 2020-12-02 17:52:26 edited from 9.0 in reply to 8 [link] [source]
When the module is unloaded from memory or is no longer registered on any connection then you may dispose of the module object. This is the same as the rules that would apply to any dynamically allocated memory object.
For the greater certainty, once you have determined that there is no longer any need for the existence of the allocated memory object (that it has no referents) then you may release it.
If you release the memory object before it is no longer required (has no referents) you are likely to get a "use after free" error because you failed to maintain the object while it was referenced.
What is all the concern about a few paragraphs of memory? Is your memory so constrained that maintaining a teeny-weeny structure from first use until the end of the program (termination) is a major difficulty?