[Fdo-trac] [fdo-trac] #895: SQLite unit test deadlock

FDO trac_fdo at osgeo.org
Sun Sep 28 11:18:59 PDT 2014


#895: SQLite unit test deadlock
-------------------------------+--------------------------------------------
   Reporter:  jng              |       Owner:  traianstanev
       Type:  defect           |      Status:  new         
   Priority:  critical         |   Milestone:              
  Component:  SQLite Provider  |     Version:              
   Severity:  1                |    Keywords:              
External_id:                   |  
-------------------------------+--------------------------------------------
 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?

-- 
Ticket URL: <http://trac.osgeo.org/fdo/ticket/895>
FDO <http://fdo.osgeo.org/>
Feature Data Objects


More information about the fdo-trac mailing list