Sqlite building failure using rtems-source-builder
jbkim at e-coretech.kr
Mon Apr 1 06:34:09 UTC 2019
I tried to use "unix-dotfile" according to your comment.
I am successful for testing sqlite.
I attached my testing code.
Thank you very much.
From: Jonathan Brandmeyer <jbrandmeyer at planetiq.com>
Sent: Saturday, March 30, 2019 3:50 AM
To: JunBeom Kim <jbkim at e-coretech.kr>
Cc: users at rtems.org
Subject: Re: Sqlite building failure using rtems-source-builder
On Fri, Mar 29, 2019 at 12:57 AM JunBeom Kim <jbkim at e-coretech.kr> wrote:
> Because there is file locking problem due to fcntl(F_SETLK) unsupported feature, DB file access is error.
SQLite3 ships with a set of VFS methods that avoid file locking entirely, named "unix-none". There are several methods available to pick this style of locking. Since my application is being tested on both a general-purpose POSIX OS as well as RTEMS, I change the VFS type in my RTEMS startup code using sqlite3_vfs_find() and sqlite3_vfs_register(). There is also a "unix-dotfile" method available, and we may switch over to that for better error-handling paths.
In the case of the "unix-none" locking mode, you must maintain the invariant that there is exactly one database connection per database file in the entire application. That seems OK to me, so we set the
-DSQLITE_DEFAULT_LOCKING_MODE=1 (EXCLUSIVE) to help enforce it in the testing environment.
> After I modify this, there is not problem using simple sqlite example code(attached: main.c).
> But, there is side-effect(for example: memory leaking issue by locking patch code) in my customer side using RTEMS.
Regarding your memory leak, don't forget to sqlite3_close() the database. This must be done even if sqlite3_open() fails.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the users