-
Notifications
You must be signed in to change notification settings - Fork 29
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
Crash upon closing CC32xx socket #440
Comments
balazsracz
added a commit
that referenced
this issue
Oct 7, 2020
Adds a new bit to mark an fd being in shutdown. This is a state during close that marks the fd as being bad, with all kernel calls (from other threads) returning EBADF if they refer to this fd. At the same time the fd is not marked as free for reuse by another open. This fixes the race condition in #440
balazsracz
added a commit
that referenced
this issue
Oct 7, 2020
This change ensures that threads higher priority than the closing call have a chance to exit their kernel processing before the socket object gets deleted. This makes #440 slightly better.
This was referenced Oct 7, 2020
balazsracz
added a commit
that referenced
this issue
Oct 8, 2020
This change ensures that threads higher priority than the closing call have a chance to exit their kernel processing before the socket object gets deleted. This makes #440 slightly better.
balazsracz
added a commit
that referenced
this issue
Oct 8, 2020
* Adds an intermediate stage in closing an fd. Adds a new bit to mark an fd being in shutdown. This is a state during close that marks the fd as being bad, with all kernel calls (from other threads) returning EBADF if they refer to this fd. At the same time the fd is not marked as free for reuse by another open. This fixes the race condition in #440 * Fix bug when dev->close returns an error.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a crash if using CC32xxWiFi sockets via HubDevice<> and then call ::close(fd) in the main thread.
The speciality of this case is that there are two threads that are pending (blocked) on performing read/write operations on the fd, while a third thread calls close on it.
Backtraces:
while another thread crashed in
The cause of the problem is that CC32xxSocket::close has line
delete this;
. After this call the sl_Close is invoked, which wakes up other threads. These other threads might be calling kernel functions with that fd, but the fd is in an inbetween state where it is not rejected by EBADF (inUse == true) but also not usable because files[fd]->dev points to deallocated memory.The text was updated successfully, but these errors were encountered: