SQLite unit test deadlock

[jng]

Running the SQLite unit tests on Linux from trunk produces a deadlock.

In my tests thus far, the unit tests will consistently freeze at SelectTest.TestViewSelects. This happens on CentOS 6.5 and Ubuntu 12.04/14.04

Running the UnitTest executable under gdb and breaking at the point of deadlock reveals this stack trace (this is from Ubuntu 14.04 64-bit, but given the consistency the stack trace would probably be similar for the other Linux variants).

Program received signal SIGINT, Interrupt.
__lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
135	../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
(gdb) bt
#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007ffff6af9657 in _L_lock_909 () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007ffff6af9480 in __GI___pthread_mutex_lock (mutex=0x90d710)
    at ../nptl/pthread_mutex_lock.c:79
#3  0x00007ffff4f3a3b6 in CriticalSectionHolder::CriticalSectionHolder (this=0x7fffffffd970, 
    cs=0x90d710) at SltProvider.h:111
#4  0x00007ffff4f29dfa in SltConnection::GetMetadata (this=0x90d6c0, table=0x7d86b8 "MainTable")
    at SltProvider.cpp:1701
#5  0x00007ffff4f12ba3 in SltMetadata::ProcessViewProperties (this=0x8abd20, pTable=0x90d5a8, 
    pstmtView=0x7fffffffdc88) at SltMetadata.cpp:714
#6  0x00007ffff4f11f5d in SltMetadata::BuildMetadataInfo (conn=0x90d6c0, lst=0x0)
    at SltMetadata.cpp:617
#7  0x00007ffff4f24a78 in SltConnection::DescribeSchema (this=0x90d6c0, classNames=0x0, 
    makeACopy=true) at SltProvider.cpp:743
#8  0x00007ffff4f3b402 in SltDescribeSchema::Execute (this=0x819ad0) at SltCommands.h:127
#9  0x0000000000433097 in SelectTest::TestViewSelects (this=0x7c39a0) at SelectTest.cpp:952
#10 0x0000000000442c96 in CppUnit::TestCaller<SelectTest, CppUnit::NoExceptionExpected>::runTest (
    this=0x7c3530)
    at /home/vagrant/scripts/fdo_build_area/Thirdparty/linux/cppunit/include/cppunit/TestCaller.h:166

I suspect r7133 introduced this defect. Perhaps this method call chain causes the CriticalSectionHolder to acquire the m_csMd critical section more than once causing a perpetual wait on a lock that will never be released?