0

I am attempting to profile a program that requires data loaded from a sqlite database. Running the program normally works as expected, but when I use callgrind the opened database is empty (no tables; a user_version that is set in the database comes back as 0). The database file is found at the correct path, and appears to be correctly opened, but there is nothing in it.

Test program (sqlite_test.cpp):

#include <sqlite3.h>
#include <iostream>
#include <sys/stat.h>

bool dbExists() {
    struct stat s;
    if (stat("testDB", &s) != 0) {
        return false;
    }
    else {
        return true;
    }
}

int main()
{

    if (dbExists())
        std::cout << "db exists\n";

    sqlite3 *db;

    int open = sqlite3_open_v2("testDB", &db, SQLITE_OPEN_READWRITE, NULL);
    if (open == SQLITE_OK) {
        std::cout << "db opened\n";
    }
    else {
        std::cout << "Failed to open DB; code: " << open << "\n";
    }

    sqlite3_stmt *stmt;
    sqlite3_prepare_v2(db, "PRAGMA user_version;", -1, &stmt, NULL);

    int dbVersion = 0;
    int res = sqlite3_step(stmt);
    if (res == SQLITE_ROW) {
        dbVersion = sqlite3_column_int(stmt, 0);
    }
    else {
        std::cout << "DB version not set: " << res << " " << sqlite3_errstr(res) << "\n";

    }

    std::cout << "Database version: " << dbVersion << std::endl;


    sqlite3_close(db);
}

I created a database ("testDB") that has "pragma user_version = 5;", and is located in the same folder as the executable. The executable is built using

g++ sqlite_test.cpp -lsqlite3 -o sqlite_test

Output:

# ./sqlite_test 
db exists
db opened
Database version: 5

# valgrind --tool=callgrind ./sqlite_test
==1184== Callgrind, a call-graph generating cache profiler
==1184== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==1184== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==1184== Command: ./sqlite_test
==1184== 
==1184== For interactive control, run 'callgrind_control -h'.
db exists
db opened
Database version: 0
==1184== 
==1184== Events    : Ir
==1184== Collected : 2787290
==1184== 
==1184== I   refs:      2,787,290

One other thing I have noticed is that it seems to work fine when running with valgrind (memcheck). It is only with callgrind that the problem shows up. This is true for both valgrind 3.12 and 3.14.

Update: Obviously I should have mentioned what I am running this on, because it appears to be the source of the problem. My problem is on a system running Yocto 2.2.2 (Morty) on a single core ARM processor. There is no problem if I run the same thing on a different system (which is a virtual machine) running Ubuntu 18.04. I am not sure which difference between those systems is causing the problem.

ioums
  • 1,367
  • 14
  • 20
  • "and is located in the same folder as the executable" - that is not necessarily where your program looks for files - you need to understand the concept of a "current working directory". –  Jan 03 '19 at 18:03
  • @NeilButterworth Please feel free to enlighten me and explain why I am able to find the file with `stat`, and why it also works the exact same when I specify the full path to the database file – ioums Jan 03 '19 at 18:11
  • Please read up on "current working directory". –  Jan 03 '19 at 18:23
  • @NeilButterworth I am aware of what a "current working directory" is. I can add a call to chdir to the path where my database file is, but it does not change anything and my program still does not work when running with callgrind. – ioums Jan 03 '19 at 18:33
  • Does it work when you use the full path to the database file? – CL. Jan 03 '19 at 19:02
  • @CL. No, the results are the same when specifying the full path to the file. – ioums Jan 03 '19 at 19:11
  • Any difference if you create a table and insert some rows? – Shawn Jan 03 '19 at 20:57
  • @Shawn Nope, no difference. – ioums Jan 03 '19 at 21:32

0 Answers0