dblog_init_for_append panics after succesfull recover
I have the following code in my setup()
if (SD.exists(db_filename)) {
Serial.printf("recovering existing database at %s...", db_filename.c_str());
res = recover_db(db_context, (String("/sd") + db_filename).c_str());
if (!res) {
set_db_file(fopen(db_filename.c_str(), "a+b"));
res = dblog_init_for_append(&db_context);
}
Serial.println((res == 0) ? "successful" : "failed");
}
recover_db is basically the same as in the examples (click to expand)
int recover_db( dblog_write_context &ctx, const char* filename) {
dbFile = fopen(filename, "r+b");
if (!&dbFile) {
print_error(0);
return 1;
}
int32_t page_size = dblog_read_page_size(&ctx);
if (page_size < 512) {
Serial.print(F("Error reading page size\n"));
fclose(dbFile);
return 2;
}
if (dblog_recover(&ctx)) {
Serial.print(F("Error during recover\n"));
fclose(dbFile);
return 3;
}
fclose(dbFile);
return 0;
}
copying the file to my laptop and using sqlite_micro_logger_c to append works fine:
opening the file with sqlite3 afterwards works and shows the added data
the database file: https://megastore.rz.uni-augsburg.de/get/eqVggTp9KG/
I've got an external debugger in the mail, but for now that's all the information i have.
@Raupinger Hi, From the stacktrace you have given, it seems to refer to line 1836 in ulog_sqlite.c, but in this library, the whole file is less than 1600. Also the function calls don't seem to match the stack trace. If you are using a modified file, it may help posting it here.
@siara-cc thanks for the reply, I assume that line number is just inaccurate from stuff like macro expansion, my ulog_sqlite.c should be the same as in the platformio registry, plus some prints. Its 1477 lines. Uploaded it to a gist anyways: https://gist.github.com/Raupinger/1999b9626d9ec0f1fef00e34709b2319
oh @siara-cc that actually says line 1036 which makes a lot more sense. Its the first line of int dblog_init_for_append(struct dblog_write_context *wctx)
here's my sqlite.cpp, basically just the sd card example with some stuff removed https://gist.github.com/Raupinger/aa3e8ae8991f997256d1275fbd52b122
@Raupinger You are right it is 1036 not 1836, my bad. According to the stacktrace, it is trying to read 72 bytes from position 0, and it crashes for fseek to position 0 in the callback function, which is unusual.
You may want to try changing this line: set_db_file(fopen(db_filename.c_str(), "a+b")); I think the a+b may have something to do with it, although on desktop os this should not cause trouble. In any case, it is something to do with file operations and not crashing in the library code. You may also want to print the size of the file before it crashes.