[guardian-dev] debugging libsqlfs

Abel Luck abel at guardianproject.info
Tue Jan 8 04:05:16 EST 2013


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.

> Now, I'm going to see if I can get valgrind to run on fuse_sqlfs.
> 
> .hc
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/abel%40guardianproject.info
> 
> You are subscribed as: abel at guardianproject.info
> 



More information about the Guardian-dev mailing list