[guardian-dev] debugging libsqlfs

Hans of Guardian hans at guardianproject.info
Tue Jan 8 09:44:49 EST 2013

On Jan 8, 2013, at 4:05 AM, Abel Luck wrote:

> 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.
> Yes! This was a conclusion I had several months ago when looking at
> Aaron's threading bug. There are definitely discrepancies between the
> way IOCipher runs and the we test things with libsqlfs and fuse.

Hey Abel,

I think that first thing's first: let's getting fully passing long fsx tests, then we can check whether we need to handle threads different in IOCipher.


More information about the Guardian-dev mailing list