Open oShcherbininSuper opened 9 months ago
Steps to reproduce the behavior: Run
executeJob
native method when the mutex is destroyed
Obviously not a good idea, but does that happen naturally? Note that according to the backtrace there might be some other issue as this seems to be somehow caused in the segmentation fault handler (segv_handler()
) when it tries to determine the thread ID (probably because one of the pointers is invalid in executeJob()
, so that callback was called after the native parts of the app were already deinitialized. But since flush()
(which is called during deinitialization) calls Scheduler::Terminate()
it's weird that there would be further calls to executeJob()
afterwards (I suppose there could be a race condition between Terminate()
and onReceive()
but since scheduled jobs are relatively rare that would be quite unlucky).
System (please complete the following information):
Describe the bug From the Android platform when launched by alarm or work manager native function
executeJob
it can crash when mutex is destroyed:public native void executeJob(String id);
To Reproduce Steps to reproduce the behavior: Run
executeJob
native method when the mutex is destroyedpublic native void executeJob(String id);
Expected behavior We could ignore logic if mutex is destroyed
Logs/Backtraces
second version: