search

Tencent / wcdb

WCDB is a cross-platform database framework developed by WeChat.
Other
10.61k stars 1.39k forks source link

stuck at line 76 of lock.cpp #1076

Closed jokerxsun closed 3 months ago

jokerxsun commented 3 months ago

The language of WCDB

Objective-C

The version of WCDB

v2.0.1

The platform of WCDB

iOS

The installation of WCDB

Cocoapods

What's the issue?

After we upgraded from version 1.0.7 to 2.0.1, several instances of freezing occurred online, all of which were stuck at line 76 of lock.cpp. I'd like to inquire about how exactly to solve this issue.

0libsystem_kernel.dylib _psynch_cvwait (in libsystem_kernel.dylib) +8 1libsystem_pthread.dylibpthread_cond_wait (in libsystem_pthread.dylib) +1224 2libc++.1.dylibstd::1::condition_variable::wait(std::__1::unique_lock<std::1::mutex>&) (in libc++.1.dylib) +24 3XSFMSSWCDB::SharedLock::lockShared() (in XSFM) Lock.cpp:76 4XSFMSSWCDB::SharedLockGuard::SharedLockGuard(SSWCDB::SharedLock&) (in XSFM) [inlined] Lock.cpp:223 5XSFMSSWCDB::SharedLockGuard::SharedLockGuard(SSWCDB::SharedLock&) (in XSFM) Lock.cpp:222 6XSFMSSWCDB::InnerDatabase::initialize() (in XSFM) InnerDatabase.cpp:130 7XSFMSSWCDB::InnerDatabase::getHandle() (in XSFM) InnerDatabase.cpp:215 8XSFM-[SSWCTHandle getOrGenerateHandle] (in XSFM) SSWCTHandle.mm:72 9XSFM-[SSWCTHandle prepare:] (in XSFM) SSWCTHandle.mm:152 10XSFM-[SSWCTSelect firstObject] (in XSFM) SSWCTSelect.mm:84 11XSFM-[SSWCTTable(Convenient) getObjectWhere:] (in XSFM) SSWCTTable+Convenient.mm:48 12XSFM-[SSHistoryManager(Book) getLocalHistoryDataWithBookId:] (in XSFM) SSHistoryManager+Book.mm:83 13XSFM-[SSIndicatorViewManager generateIndicatorDataModelFromPlayer] (in XSFM) SSIndicatorViewManager.m:598

Qiuwen-chen commented 3 months ago

Please show us all WCDB related stacks.

jokerxsun commented 3 months ago

Please show us all WCDB related stacks.

this is main queue stacks:

0libsystem_kernel.dylib_psynch_cvwait (in libsystem_kernel.dylib) +8 2libc++.1.dylibstd::__1::condition_variable::wait(std::1::unique_lockstd::1::mutex&) (in libc++.1.dylib) +20 3XSFMSSWCDB::SharedLock::lockShared() (in XSFM) Lock.cpp:76 4XSFMSSWCDB::SharedLockGuard::SharedLockGuard(SSWCDB::SharedLock&) (in XSFM) [inlined] Lock.cpp:223 5XSFMSSWCDB::SharedLockGuard::SharedLockGuard(SSWCDB::SharedLock&) (in XSFM) Lock.cpp:222 6XSFMSSWCDB::InnerDatabase::initialize() (in XSFM) InnerDatabase.cpp:130 7XSFMSSWCDB::InnerDatabase::getHandle() (in XSFM) InnerDatabase.cpp:215 8XSFM-[SSWCTHandle getOrGenerateHandle] (in XSFM) SSWCTHandle.mm:72 9XSFM-[SSWCTHandle prepare:] (in XSFM) SSWCTHandle.mm:152 10XSFM-[SSWCTSelect firstObject] (in XSFM) SSWCTSelect.mm:84 11XSFM-[SSWCTTable(Convenient) getObjectWhere:] (in XSFM) SSWCTTable+Convenient.mm:48 12XSFM-[SSHistoryManager(Book) getLocalHistoryDataWithBookId:] (in XSFM) SSHistoryManager+Book.mm:83 13XSFM-[SSIndicatorViewManager generateIndicatorDataModelFromPlayer] (in XSFM) SSIndicatorViewManager.m:598 14XSFM-[SSIndicatorViewManager setupIndicatorView] (in XSFM) SSIndicatorViewManager.m:567 15XSFMsafe_call_message (in XSFM) HTSMessageCenter.mm:31 16XSFM-[SSAudioPlayManager(BDFQPlayManagerDelegate) bdfqWillSeekToIndex:isAutoSeek:] (in XSFM) SSAudioPlayManager+BDFQPlayManagerDelegate.m:83 17XSFM-[BDFQPlayManager configPlayList:firstPlayItemId:fromPlay:] (in XSFM) BDFQPlayManager.m:149 18XSFM69-[BDFQPlayManager asyncConfigPlayListWithParams:fromPlay:completion:]_block_invoke_2 (in XSFM) BDFQPlayManager.m:108 19XSFMbdfq_safe_dispatch_async (in XSFM) BDFQMacros.m:16 20XSFM69-[BDFQPlayManager asyncConfigPlayListWithParams:fromPlay:completion:]_block_invoke.73 (in XSFM) BDFQPlayManager.m:102 21XSFM98-[SSAudioPlayManager(BDFQPlayManagerDataSource) bdfqGetPlayListWithParams:isCancelled:completion:]_block_invoke (in XSFM) SSAudioPlayManager+BDFQPlayManagerDataSource.m:95 22XSFM119-[SSAudioDataManager requestPlayInfoWithRequestInfo:itemId:nearCount:requestAll:partDataCompletion:fullDataCompletion:]_block_invoke.314 (in XSFM) SSAudioDataManager.mm:370 23libdispatch.dylibdispatch_call_block_and_release (in libdispatch.dylib) +20 32UIKitCore_UIApplicationMain (in UIKitCore) +308 33XSFMmain (in XSFM) main.m:50 34dyldstart (in dyld) +1856

this is other queue: 0libsystem_kernel.dylib_pread (in libsystem_kernel.dylib) +8 1XSFMseekAndRead (in XSFM) os_unix.c:3397 2XSFMunixRead (in XSFM) os_unix.c:3473 3XSFMreadDbPage (in XSFM) pager.c:3047 4XSFMgetPageNormal (in XSFM) pager.c:5536 5XSFMgetAndInitPage (in XSFM) btree.c:2125 6XSFMmoveToLeftmost (in XSFM) btree.c:5174 7XSFMsqlite3VdbeExec (in XSFM) vdbe.c:5267 8XSFMsqlite3Step (in XSFM) [inlined] vdbeapi.c:630 9XSFMsqlite3_step (in XSFM) vdbeapi.c:696 10XSFMSSWCDB::HandleStatement::step() (in XSFM) HandleStatement.cpp:366 11XSFM-[SSWCTHandle allObjectsOnResultColumns:] (in XSFM) SSWCTHandle.mm:600 12XSFM-[SSWCTSelect allObjects] (in XSFM) SSWCTSelect.mm:76 13XSFM-[SSWCTTable(Convenient) getObjectsWhere:limit:] (in XSFM) SSWCTTable+Convenient.mm:121 14XSFM59-[SSHistoryManager syncLocalDeleteHistoryRecordsWithTable:]_block_invoke (in XSFM) SSHistoryManager.mm:2104 15XSFM-[SSHistoryManager syncLocalDeleteHistoryRecordsWithTable:] (in XSFM) SSHistoryManager.mm:2087 16XSFM-[SSHistoryManager syncHistoryRecordsWithTable:isLogin:] (in XSFM) SSHistoryManager.mm:2081 17XSFM38-[SSHistoryManager syncHistoryRecords]_block_invoke (in XSFM) SSHistoryManager.mm:2074 18libdispatch.dylib__dispatch_call_block_and_release (in libdispatch.dylib) +20 24libsystem_pthread.dylib_start_wqthread (in libsystem_pthread.dylib) +4

The sub-thread has read the database and at the same time the main thread has read the database, what I'm curious about after reading the source code is that the current lock that the main thread is waiting for is the lock that was added when the sub-thread read it? thank you

Qiuwen-chen commented 3 months ago

The main thread is not waiting for the sub-thread you gave. You can try the latest version to see if the problem still exists.

Qiuwen-chen commented 3 months ago

The lock that the main thread is waiting for is only used when opening the SQLite handle, and the child thread has released the lock.

jokerxsun commented 3 months ago

The lock that the main thread is waiting for is only used when opening the SQLite handle, and the child thread has released the lock.

So looking at the current stack, who created the lock that the main thread is waiting for? Because from the subthread stack it also looks like no SQLite handle was created. thank you

Qiuwen-chen commented 3 months ago

The lock that the main thread is waiting for is only used when opening the SQLite handle, and the child thread has released the lock.

So looking at the current stack, who created the lock that the main thread is waiting for? Because from the subthread stack it also looks like no SQLite handle was created. thank you

It must be caused by sub-thread, but your lag monitor does not catch its stack. You can find more cases to check it.