-
Notifications
You must be signed in to change notification settings - Fork 35
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
sometimes goes into a 100% CPU loop when an fd is closed #73
sometimes goes into a 100% CPU loop when an fd is closed #73
Conversation
Looks a bit overkill as any exception on the callback of the poller will cause it to be removed. This should be only for some exceptions about the fd being invalid or similar. Si maybe a new exception of "invalid_fd" or similar. |
What about c5d6c29? There is something strange with this code from poller.cpp:
and rtpclient.cpp:
I don't understand why it is 18 in data_ready and 10 in the poller. |
I think you might be getting a fd problem called from an event of another fd. The invalid_fd exception should say which fd had the exception, and then remove that one from the poller. |
I think you might be getting a fd problem called from an event of another fd.
But how?
The invalid_fd exception should say which fd had the exception, and then remove that one from the poller.
I just realised that in case of a pair of sockets (control/data)
closing one would leave the other dangling.
|
The how, storing the fd at the exception and using it later. About dangling.. if one fails the other should fail too sooner or later, isnt it? If not then maybe we should add some callback to be called when a fd is removed... or is this getting too complicated? |
About the other FD: true.
"I think you might be getting a fd problem called from an event of another
fd."
My question was: how can this happen? It comes from the same thread.
Op vr 20 aug. 2021 20:08 schreef David Moreno Montero <
***@***.***>:
… The how, storing the fd at the exception and using it later.
About dangling.. if one fails the other should fail too sooner or later,
isnt it? If not then maybe we should add some callback to be called when a
fd is removed... or is this getting too complicated?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#73 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AUN5IW75U3HQWDJ3UBO7VJ3T52KYRANCNFSM5CQN4J4A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
I can only think that becaus eof whatever happenend on the first fd affected to do something on the second. For example an ALSA event may cause to send some network data. Do you know https://rr-project.org/ ? I did try it years ago, and dont know if it will help, but I think it can record the full history of one crash, and then we can inspect why it got there. Can you give it a try? |
I had never heard of rr. Thanks for pointing me at it!
I'll give it a try.
…On Sat, Aug 21, 2021 at 12:14 PM David Moreno Montero < ***@***.***> wrote:
I can only think that becaus eof whatever happenend on the first fd
affected to do something on the second. For example an ALSA event may cause
to send some network data.
Do you know https://rr-project.org/ ? I did try it years ago, and dont
know if it will help, but I think it can record the full history of one
crash, and then we can inspect why it got there.
Can you give it a try?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#73 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AUN5IW5F5QW6LNCLBIHSFGLT554BDANCNFSM5CQN4J4A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
Oh that won't work: rr-debugger/rr#2873
They're disabling alsa-access in rr.
On Sat, Aug 21, 2021 at 1:48 PM Folkert van Heusden ***@***.***>
wrote:
… I had never heard of rr. Thanks for pointing me at it!
I'll give it a try.
On Sat, Aug 21, 2021 at 12:14 PM David Moreno Montero <
***@***.***> wrote:
> I can only think that becaus eof whatever happenend on the first fd
> affected to do something on the second. For example an ALSA event may cause
> to send some network data.
>
> Do you know https://rr-project.org/ ? I did try it years ago, and dont
> know if it will help, but I think it can record the full history of one
> crash, and then we can inspect why it got there.
>
> Can you give it a try?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#73 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AUN5IW5F5QW6LNCLBIHSFGLT554BDANCNFSM5CQN4J4A>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
> .
>
|
Code would not apply on current master. Please open a issue or another pull request. Thanks a lot anyway for the effort for creating this pull request. |
No description provided.