Community
Participate
Working Groups
FORTE is started as a TCP/IP server. When receiving a huge data stream of which the size is larger than the size of the pre-defined socket buffer specified with "FORTE_IPLayerRecvBufferSize", the CFDSelectHandler will call the recvData() function of CIPCommlayer continuously and "mInterruptResp" will be set to "e_Nothing" during this procedure. Then, when the processInterrupt() of CIPCommlayer is called by another thread (event chain), the expected response code (such as "e_ProcessDataOk") has been set to a wrong value. Therefore, the received data will not be handled by the top layer any longer.
New Gerrit change created: https://git.eclipse.org/r/c/4diac/org.eclipse.4diac.forte/+/190188
To reproduce this BUG, one can easily enable the Lua module in forte (after the 1.13 version). In the 2.0 version, when enabling the "FORTE_DYNAMIC_TYPE_LOAD" option, the "FORTE_IPLayerRecvBufferSize" will not be changed from the default 1500 to a larger one (e.g., 20000). In this case, deploying dynamic-type FBs via 4DIAC will cause an error.
In the first thread, we know the function call procedure is: CFDSelectHandler->CIPCommlayer::recvData()-> mInterruptResp = e_Nothing; ...; mInterruptResp = e_ProcessDataOk; m_poFb->interruptCommFB(this); Then the ecet thread is wakened up and finally call CIPCommlayer::processInterrupt(), where mInterruptResp will be checked if(e_ProcessDataOk == mInterruptResp). Note, during wakening up of ecet thread, the CFDSelectHandler thread may call CIPCommlayer::recvData() again and again...(since there are data available). Then,mInterruptResp will be set to e_Nothing. Besides, mBufFillSize is set to cg_unIPLayerRecvBufferSize during the first call. Then CIPCommlayer::handledConnectedDataRecv() will not continue to receive data from socket. Now, mInterruptResp will not be updated any longer, and the ecet thread cannot receive interrupt as well. At this time, these two threads are "deadlocked".
