SQLite Forum

C api sqlite3_db_readonly returns -1
Login

C api sqlite3_db_readonly returns -1

(1) By anonymous on 2021-08-04 16:11:39 [link]

I open a database 

rc = sqlite3_open_v2(...SQLITE_OPEN_READWRITE...);  // here is ok, the value returned is 0

Then I check if the database is writable 

rc = sqlite3_db_readonly(db, DBF); // here the value of rc is -1 

Then the program crashes with - segmentation fault (core dump)

I need to know which are the causes of the returnining value -1.
Thanks for any help.

Cristian Danciu

(2) By Stephan Beal (stephan) on 2021-08-04 16:30:34 in reply to 1 [link]

> I need to know which are the causes of the returnining value -1.

For anyone here to be able to speculate on that, you'll need to demonstrate the *exact* code which is failing for you, not a summary of it.

(3) By Larry Brasfield (larrybr) on 2021-08-04 16:54:52 in reply to 2 [link]

(Clarifying for the OP:) A very short repro sequence, with the exact code used to open the database followed by the exact code which returns -1, with symbolic constants of your own devise replaced by literals, will suffice.

Without speculating, because I have read the relevant code, I can say that a -1 return instead of a C boolean (1 or 0) return indicates an invalid call of one form or another.  As to how your call is invalid, I could only speculate before seeing your code.

(4) By anonymous on 2021-08-04 18:08:05 in reply to 2 [link]

Here is the code 

  #define DBF "path/to/dbfile"

  sqlite3* db;

  const char* values[4] = {"Ana","str","0720", "ana.oa"};

  

  char* sql;
  int rc;
  sqlite3_stmt* stmt;

  rc = sqlite3_open_v2(DBF, &db, SQLITE_OPEN_READWRITE, NULL );
  printf("٪d",rc);
  printf("٪d", sqlite3_db_readonly(db, DBF));
  sql = "insert into ids (name, adr, tel, email) values(?1, ?2, ?3, ?4);";
  sqlite3_prepare_v2(db, sql, -1, &stmt, NULL );
  sqlite3_bind_text(stmt, 1, values[1], -1, SQLITE_STATIC);
  sqlite3_bind_text(stmt, 2, values[2], -1, SQLITE_STATIC);
  sqlite3_bind_text(stmt, 3, values[3], -1, SQLITE_STATIC);
  sqlite3_bind_text(stmt, 4, values[4], -1, SQLITE_STATIC);
  sqlite3_step(stmt);
  sqlite3_finalize(stmt);
  sqlite3_close(db);

I am more interested for now in learning, than in solving a particular code, so if anyone can give me some clues about the causes of that returning value -1, IT would be very appreciated, because I didn't find anything on the internet.
Thanks in advance.

(5) By Stephan Beal (stephan) on 2021-08-04 18:13:51 in reply to 4 [link]

>  so if anyone can give me some clues about the causes of that returning value -1

Your array indexes for `values[...]` are wrong, so the final one is passing invalid memory to bind. Array index start at 0, not 1. Bind indexes, on the other hand, start at 1. Whether that is *the* problem, i don't know, but it's certainly *a* problem. (Apologies for the brevity, but am working from a tablet.)

(6.1) By Larry Brasfield (larrybr) on 2021-08-04 19:07:23 edited from 6.0 in reply to 4 [link]

Note differences in below code from your's:<code>
  #include \<stdio.h\>
  #include "sqlite3.h"
  #define DBF "/tmp/my_dbfile.sdb"
  #define MAIN_SCHEMA "main"
int main(int an, char \*ap\[\]){
  sqlite3\* db;
  const char* values\[4\] = {"Ana","str","0720", "ana.oa"};
  char\* sql;
  int rc;
  sqlite3_stmt\* stmt;
  rc = sqlite3_open_v2(DBF, &db, SQLITE_OPEN_READWRITE, NULL );
  printf("%d\\n",rc);
  printf("%d\\n", sqlite3_db_readonly(db, MAIN_SCHEMA)); /\* Arg 2 changed \*/
  sql = "insert into ids (name, adr, tel, email) values(?1, ?2, ?3, ?4);";
  sqlite3_prepare_v2(db, sql, -1, &stmt, NULL );
  /\* C indices used for next 4 statements. \*/
  sqlite3_bind_text(stmt, 1, values[0], -1, SQLITE_STATIC);
  sqlite3_bind_text(stmt, 2, values[1], -1, SQLITE_STATIC);
  sqlite3_bind_text(stmt, 3, values[2], -1, SQLITE_STATIC);
  sqlite3_bind_text(stmt, 4, values[3], -1, SQLITE_STATIC);
  sqlite3_step(stmt);
  sqlite3_finalize(stmt);
  sqlite3_close(db);
  return 0;
}
/* Compile with: gcc -I. -o dbro /tmp/dbro.c sqlite3.c -lpthread -ldl -lm
*/
</code>

(7) By anonymous on 2021-08-04 18:32:12 in reply to 5 [link]

Actually, the number of elements of array is 5, and actually in my code I tried a VLA with some looping and printf, scanf, which worked fine, but that part of the code I didn't include.

(8) By Larry Brasfield (larrybr) on 2021-08-04 18:37:09 in reply to 7 [link]

You severely handicap those who might be willing and able to help you when you present "problematic" code which differs from the code for which you hope to resolve problems.  This is why I use phrasing such as "exact code" and Stephan clearly disfavors "a summary of it".

(9) By anonymous on 2021-08-04 18:51:56 in reply to 6.0 [link]

Thanks,
I didn't mention that my database file is on external HDD.I need to put it on the tmp folder? 
I also noticed that dbro thing in compilation options, but i don't know what it represents.

(10) By anonymous on 2021-08-04 18:58:53 in reply to 8 [link]

Thanks a lot, but i need to send messages from the tablet and I find very difficult to type very long code (my laptop has a wifi adaptor issue).

(11) By Larry Brasfield (larrybr) on 2021-08-04 18:59:54 in reply to 9 [link]

No, the DB file can be wherever a writable file might reside. Also, you provided a code fragment, one which I made into a file that could be compiled and which needed a name so that the compiler could actually compile it. Those differences are not relevant to your problem, which I demarked with code comments.

(12) By Larry Brasfield (larrybr) on 2021-08-04 19:16:18 in reply to 10 [link]

When you wrote: "Here is the code", followed by some code which was **NOT** the code (as revealed in post #7), you caused Stephan, (who was also working from a mobile device), to waste his time pointing out a problem which, apparently<sup>a</sup>, you were not having. Summaries and false characterization of a problem are highly likely to impede problem resolution.

----

a. The segmentation fault could easily have been produced by the very indexed access error exhibited in "the code" later disavowed, so the misrepresentation goes beyond mere distraction; it is positively misleading.

(13) By Keith Medcalf (kmedcalf) on 2021-08-04 19:59:25 in reply to 4 [link]

The sqlite3_db_readonly call takes two arguments.  

The sqlite3 connection handle and the database schema name ('main', 'temp', etc).

Passing the connection handle and the database file name is an error, hence you get an error returned.

<https://sqlite.org/c3ref/db_readonly.html>

(14) By anonymous on 2021-08-04 21:08:31 in reply to 13 [link]

Yes, i modified the second argument with the macro MAIN_SCHEMA as specified by Larry, and IT works for that line, the returned value is now 0 . I actually introduced that line of code to check if the database file is not writable, as a possible cause of segmentation fault crash. But this is not the case, the problem is somewhere else,  so i'll check 'non-sqlite' portion of the code .
Thanks a lot guys, i appreciate very much your answers.

(15) By anonymous on 2021-08-04 21:24:27 in reply to 11 [link]

I studied a little bit the compilation with the sqlite3.c and I saw that the amalgamation is the recommended method. I use arch linux as os and I checked the available sqlite3 files but i didn't noticed that file. I used to compile with gcc file.c -l sqlite3 -o a.out. is IT possible that this was the cause of the segmentation fault core dump ?

(16) By Larry Brasfield (larrybr) on 2021-08-04 21:35:19 in reply to 15

If that compile/link invocation ran without errors, I see no likelihood that your seg-fault was due to use of whatever pre-built sqlite3.o got linked that way. So, remotely possible, but not worth any investigation IMO.

FWIW, the code I posted (compiles and) runs without any seg-fault and yields expected results.

Given your platform and perhaps recently begun use of C, I recommend learning to use gdb. You can tell it to start with a core dump and then see what went wrong, at least in its latter stages. The SQLite debug build, used with a debug build of your own code, will make the debugging experience much more useful.

(17) By anonymous on 2021-08-04 21:51:35 in reply to 16 [link]

OK, thank you very much.