Skip to content
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

Open
balazsracz opened this issue Oct 7, 2020 · 0 comments
Open

Crash upon closing CC32xx socket #440

balazsracz opened this issue Oct 7, 2020 · 0 comments

Comments

@balazsracz
Copy link
Collaborator

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:

#0  0x20019036 in vPortExitCritical () at /home/bracz/FreeRTOS/FreeRTOSv10.0.0/FreeRTOS/Source/include/../../Source/portable/GCC/ARM_CM3/portmacro.h:230
#1  0x20019d68 in xQueueGenericSend (xQueue=0x20027600, pvItemToQueue=0x2002b5e0, pvItemToQueue@entry=0x0, xTicksToWait=<optimized out>, xTicksToWait@entry=0, xCopyPosition=64, 
    xCopyPosition@entry=0) at /FreeRTOS/FreeRTOSv10.0.0/FreeRTOS/Source/queue.c:841
#2  0x20016320 in sem_post (semaphore=semaphore@entry=0x20023d30 <g_SlInternalSpawnCB>)
    at /CC3220SDK/simplelink_cc32xx_sdk_3_40_00_05/source/ti/posix/freertos/semaphore.c:151
#3  0x200059d8 in _SlInternalSpawn (pEntry=pEntry@entry=0x20004fe5 <_SlDrvMsgReadSpawnCtx>, pValue=pValue@entry=0x0, flags=flags@entry=2)
    at /CC3220SDK/simplelink_cc32xx_sdk_3_40_00_05/source/ti/drivers/net/wifi/source/spawn.c:124
#4  0x20003f30 in _SlDrvMsgReadCmdCtx (IsLockRequired=<optimized out>, cmdOpcode=37890)
    at /CC3220SDK/simplelink_cc32xx_sdk_3_40_00_05/source/ti/drivers/net/wifi/source/driver.c:1819
#5  _SlDrvCmdOp (pCmdCtrl=pCmdCtrl@entry=0x2001ae54 <_SlSockCloseCmdCtrl>, pTxRxDescBuff=pTxRxDescBuff@entry=0x20025d30, pCmdExt=pCmdExt@entry=0x0)
    at /CC3220SDK/simplelink_cc32xx_sdk_3_40_00_05/source/ti/drivers/net/wifi/source/driver.c:866
#6  0x200167a6 in sl_Close (sd=<optimized out>)
    at /CC3220SDK/simplelink_cc32xx_sdk_3_40_00_05/source/ti/drivers/net/wifi/source/sl_socket.c:204
#7  sl_Close (sd=sd@entry=6) at CC3220SDK/simplelink_cc32xx_sdk_3_40_00_05/source/ti/drivers/net/wifi/source/sl_socket.c:176
#8  0x20009384 in CC32xxSocket::close (this=0x2002aad8, file=<optimized out>) at /openmrn/src/freertos_drivers/net_cc32xx/CC32xxSocket.cxx:759
#9  0x2000f11a in Device::close (reent=<optimized out>, fd=9) at /openmrn/src/freertos_drivers/common/Device.cxx:147

while another thread crashed in

#0  0x00fdad00 in ?? ()
#1  0x2000f43c in FileIO::read (reent=<optimized out>, fd=<optimized out>, buf=0x2002b5e0, count=64)
/openmrn/src/freertos_drivers/common/Fileio.cxx:122
#2  0x2000ae6c in FdHubPortBase::ReadThreadBase::entry (this=0x2002b14c) at /openmrn/src/utils/HubDevice.hxx:158

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.

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.
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant