[guardian-dev] debugging libsqlfs

[Hans-Christoph Steiner]

Hey Abel,

I'm now diving in deep into debugging using gdb for now.  I've been catching
crashed in sqlfs with gdb and can get backtraces.  For the record, here's how
I'm doing it:

* using a VM to avoid filesystem crashes and lock-ups :)

* to mount the file system, run this as root:
	gdb --args ./.libs/fuse_sqlfs -d -o allow_other /mnt/

* to test it, run this as a normal user:
	./libsqlfs/tests/fsx  -l 10485760 -o 1048576  /mnt/testfile8

Most of the backtraces look like this, i.e. occuring in sqlfs_proc_trunctate()
with sqlfs=sqlfs at entry=0x0:

#1  0xb7ede033 in get_value_block (sqlfs=sqlfs at entry=0x8072b10,
    key=0x808a7c8
"(\317\006\b\b\265\b\b\300\266\b\bx\270\b\b\230\250\b\b\260\267\b\b\b",
    key at entry=0x805a618 "/testfile8",
    data=0xb64d2008
"\024\177\024\305\024\303\024\241\024\231\024\372\024\006\024\334\024u\024\314\024\336\024\353\024\064\024\266\024x\024\277\024$\024\063\024\033\024\332\024\206\024\257\024\034\024y\024\a\024\340\024\061\024\202\024\a\024e\024\017\024\071\024?\024\221\024$\024\274\024\271\024U\024\336\024\030\024\254\024\302\024\065\024@\024\020\024\061\024\257\024\243\024\261\024\"\024\305\024\353\024T\024D\024@\024\357\024\214\024\064\024%\024\356\024A\024\062\024\272\024p\024y\024#\024\321\024\246\024\326\024K\024\250\024\022\024\372\024!\024:\024\264\024O\024\356\024\317\024\377\024Y\024}\024\246\024\306\024\343\024K\024\b\024\261\024m\024\314\024]\024\005\024\261\024\351\024\\\024@\024\210\024\267\024\331\024\243"...,
block_no=block_no at entry=63, size=size at entry=0x0) at sqlfs.c:1326
#2  0xb7edee28 in get_value (sqlfs=0x8072b10, key=key at entry=0x805a618
"/testfile8",
    value=value at entry=0xb7504fb4, begin=8257536, begin at entry=0, end=8321722,
end at entry=0)
    at sqlfs.c:1487
#3  0xb7ee36f9 in sqlfs_proc_truncate (sqlfs=sqlfs at entry=0x0,
path=path at entry=0x805a618 "/testfile8",
    size=0) at sqlfs.c:2545
#4  0xb7ee3fb3 in sqlfs_op_truncate (path=0x805a618 "/testfile8", size=0) at
sqlfs.c:3433
#5  0xb7ef980a in fuse_fs_truncate () from /lib/i386-linux-gnu/libfuse.so.2


It seems that sqlfs_t gets re-issued a lot, I added this to get_sqlfs() and
got it many many times:

    if (p)
        return p;
    else
        show_msg(stderr, "sqlfs was 0");

This lead me to examine the threading stuff, since it seems that when sqlfs ==
0, its getting a new sqlfs issued from:

    sqlfs = (sqlfs_t *) (pthread_getspecific(sql_key));

Since the libsqlfs code only has pthread code relating to the pthread_key_t
creation and use, my guess is that FUSE itself is handling the rest of the
threading.  So the good news is that libsqlfs was made with threading in mind,
the bad news is that a lot of it is normally handled in libfuse, so we'll have
to figure that part out and implement it in IOCipher in order to support threads.

Now, I'm going to see if I can get valgrind to run on fuse_sqlfs.

.hc