SQLITE_MISUSE on clone

(1) By andygoth on 2020-07-18 00:59:45 [link] [source]

The following commands:

mkdir fossil-crash
cd fossil-crash
fossil open ~/repos/fossil.fossil f8d210aa1c150d13d6ca9d58abf9cec461e4b8c4
./configure
make
./fossil clone http://fossil-scm.org/ fossil.fossil

result in this error:

SQLITE_MISUSE(21): API call with NULL database connection pointer
SQLITE_MISUSE(21): misuse at line 128813 of [067291143a]
Database error: out of memory
SELECT value FROM config WHERE name='sync-url:http://fossil-scm.org/'

The same failure happens with other protocols besides http.

Bisection reveals the failure was introduced by f11c863d91c251d0, which is a shame because I could use that feature on this project.

(2) By andygoth on 2020-07-18 01:34:37 in reply to 1 [link] [source]

For now I've backed out the commit in question, along with a few things downstream of it. Here's the backout: https://fossil-scm.org/home/info/0a7526522085631f.

(3) By andygoth on 2020-07-18 04:28:19 in reply to 2 [link] [source]

Now fixed, thanks to https://fossil-scm.org/home/info/857777f117eb0d5a.

(4) By Marcelo Huerta (richieadler) on 2020-07-18 16:36:15 in reply to 3 [link] [source]

I am glad, one of my personal projects really benefits of the multi-remotes autosyncing all at once.

(8) By andygoth on 2020-08-17 00:30:25 in reply to 4 [link] [source]

The multi-remotes don't all autosync at once. Only the default remote syncs.

"The default remote is used by autosync."

I have wanted automatic sync'ing of multiple remotes, but this is not implemented. See my thread on this topic.

(5) By andygoth on 2020-07-30 00:13:08 in reply to 1 [source]

Turns out there's another problem now, introduced either by the original change f11c863d91c251d0 or by the correction 857777f117eb0d5a. I used a bisect to confirm this is when things went wrong.

Cloning from one filesystem file to another results in the following:

$ fossil clone a.fossil b.fossil
SQLITE_ERROR(1): no such table: global_config in "DELETE FROM global_config WHERE name  = 'repo:/home/andy/test/b.fossil';"
Database error: no such table: global_config: {DELETE FROM global_config WHERE name  = 'repo:/home/andy/test/b.fossil';}

For now, I brought back the temporary-fix to include everything but the multi-remote capability.

(6) By andygoth on 2020-08-16 15:15:13 in reply to 5 [link] [source]

To better reflect its purpose, I renamed the branch from temporary-fix to multi-remote-fix.

I compared the output of fossil -sqltrace between trunk and multi-remote-fix. This revealed the problem to be use of db_close_config() before later attempting to call db_record_repository_filename().

db_close_config() is called by db_close(), itself called by clone_cmd() due to the source repository being a local file.

db_record_repository_filename() is called by clone_cmd(), just two lines after it called db_close().

Gonna work on this some more.

(7) By andygoth on 2020-08-16 15:25:49 in reply to 6 [link] [source]

In multi-remote-fix, the first major difference I see is db_close() does not call db_close_config() because g.db is NULL. Thus, the configuration table is open and the global_config table still exists by the time db_record_repository_filename() tries to access it.

In trunk, g.db is non-NULL, leading to the errors I've been experiencing, namely the configuration database being closed before db_record_repository_filename() can get to it.

g.db is non-NULL because the multi-remote feature modified url_parse_local() to call db_get() in support of the "URL" actually being the alias for a previously-registered remote URL.

(9) By andygoth on 2020-08-17 08:07:09 in reply to 7 [link] [source]

Fixed, thanks again to drh. (Check-in)