-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native crash in the libiperf v3.17.1.so #41
Comments
I made a few small changes and... for now, it's been pretty stable. We'll see if it'll survive the whole night. Biggest change was not enqueuing onto the WM in main thread, because the way I'm enforcing that thing to run on the main thread is also somewhat... dodgy. |
Lets let this one sit for a while, but I may have had it working fine during the whole night; if I don't see many more of these crashes I'll consider the issue resolved from my side and close the issue. |
If the issue is resolved on my side - this commit might have completely resolved it: Cloud-City-RS@e9b40b3 moving WorkManager enqueuing from main thread to whatever this other thing is. |
I will have a look, thank you! |
Nope, the issue is still there:
and it might have happened after my internet died. this happened after the crash that seemingly resolved (or significantly reduced) the number of these native crashes so - it's still present. |
Another one - apparently calling lock() or destroy() on destroyed mutex. First case:
Second case:
|
It just seems it's always calling
and by "always" i mean "whenever it crashes, that seems to always be the reason" |
Invalid thread passed to pthread_kill
|
And one more, looks like it tried doing a double-destroy.
|
A few more
|
Here is a different, more interesting one. Corrupted stack.
|
@RkShaRkz thanks for all the input. We will look into it ASAP |
Bug Report
Run iperf3 tests one after another long enough and it's bound to happen
Context
Description
How to Reproduce
Steps to reproduce the behavior:
Expected Behavior
It'd be great if the libraries could survive 1000+ 15second tests in a row
Actual Behavior
More often than not, they can't, and either suffer a native library crash or some other defect which crashes the app.
Screenshots
Additional Context
You can take a look at this branch and see what's there to see, if the repo is visible to you
Cloud-City-RS#25
Possible Fix
The text was updated successfully, but these errors were encountered: