clearState doesn't take care of pending threads

Open
#32 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
cpp, react-native, sqlite
Domain
database, mobile

Research direction

Start with osp::clearState(), ThreadPool, and the pending async-query path reaching createSequelQueryExecutionResult in cpp/JSIHelper.cpp:135 and bindings.cpp:240. Reproduce the CodePush restart scenario and trace how clearState handles active work. Done means pending executions no longer access the old runtime after a restart.

Written by the indexing model from the issue text.

Description

triage:needs-reproduction

I've noticed that the sqlite lib crashes when codepush restarts the app, if there are a pending async queries.

The reason is that it tries to use a runtime that doesn't exist anymore, crashing here.

I had previously tried to mitigate this issue with https://github.com/margelo/react-native-quick-sqlite/pull/16. While correct, it still allows pending executions to complete, causing these crashes.

One way to fix this is to kill ThreadPool's threads from osp::clearState().

@ospfranco any thoughts?

Full stack trace

facebook::jsi::Object::Object (jsi.h:658)
createSequelQueryExecutionResult (JSIHelper.cpp:135)
const::lambda::operator() (bindings.cpp:240)
std::__1::__invoke<T> (type_traits:3918)
std::__1::__invoke_void_return_wrapper<T>::__call<T> (invoke.h:61)
std::__1::__function::__alloc_func<T>::operator() (function.h:178)
std::__1::__function::__func<T>::operator() (function.h:352)
std::__1::__function::__value_func<T>::operator() (function.h:505)
std::__1::function<T>::operator() (function.h:1182)
facebook::react::Instance::JSCallInvoker::scheduleAsync::lambda::operator() (Instance.cpp:295)
std::__1::__invoke<T> (type_traits:3918)
std::__1::__invoke_void_return_wrapper<T>::__call<T> (invoke.h:61)
std::__1::__function::__alloc_func<T>::operator() (function.h:178)
std::__1::__function::__func<T>::operator() (function.h:352)
std::__1::__function::__value_func<T>::operator() (function.h:505)
std::__1::function<T>::operator() (function.h:1182)
facebook::react::NativeToJsBridge::runOnExecutorQueue::lambda::operator() (NativeToJsBridge.cpp:310)
std::__1::__invoke<T> (type_traits:3918)
std::__1::__invoke_void_return_wrapper<T>::__call<T> (invoke.h:61)
std::__1::__function::__alloc_func<T>::operator() (function.h:178)
std::__1::__function::__func<T>::operator() (function.h:352)
std::__1::__function::__value_func<T>::operator() (function.h:505)
std::__1::function<T>::operator() (function.h:1182)
facebook::react::tryAndReturnError (RCTCxxUtils.mm:74)
facebook::react::RCTMessageThread::tryFunc (RCTMessageThread.mm:69)
std::__1::__function::__value_func<T>::operator() (function.h:505)
std::__1::function<T>::operator() (function.h:1182)
facebook::react::RCTMessageThread::runAsync (RCTMessageThread.mm:45)
CoreFoundation
+0x0355c4
<redacted>
CoreFoundation
+0x033ee8
<redacted>
CoreFoundation
+0x031de8
<redacted>
CoreFoundation
+0x031a04
CFRunLoopRunSpecific
+[RCTCxxBridge runRunLoop] (RCTCxxBridge.mm:337)
Foundation
+0x0a805c
<redacted>
libsystem_pthread
+0x00218c
_pthread_start
Dominant language
C
Stars
565
Forks
53
Avg merge
3d 13h
Merged PRs (30d)
28

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from margelo/react-native-nitro-sqlite

All issues in margelo/react-native-nitro-sqlite

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.