| Dynamic type loader fails to deploy new FB Type [message #1849607] |
Wed, 26 January 2022 17:37  |
 nan zhou
Messages: 8
Registered: June 2018 |
Junior Member |
|
|
Hello,
I'm updating my old version of 4diac to the latest 2.0.1, but I meet a problem when I'm using the Lua-based dynamic type loader. I choose the "DynamicTypeLoad" profile, and I compile forte source code by enabling the LuaJIT option. All necessary steps are done by following the document: https://www.eclipse.org/4diac/en_help.php?helppage=html/4diacIDE/dynamicTypeLoader.html
However, 4diac is stuck and pops up an error message:
Everything is OK when I'm back to 4DIAC 1.13 and forte 1.13, with the same steps. My environment is Windows 11 x64, and the test 4diac project files are attached.
Last, I notice that each time a new FB type is created, a pointer to the instance of the CLuaBFBTypeEntry class will be created, but it seems that there is no call of its destructor function in forte, which leads to memory leaks when exiting forte. I've tested this problem in forte v1.13 using Visual Leak Detector on Windows.
|
|
|
|
|
|
|
| Re: Dynamic type loader fails to deploy new FB Type [message #1849703 is a reply to message #1849689] |
Sun, 30 January 2022 15:18  |
nan zhou
Messages: 8
Registered: June 2018 |
Junior Member |
|
|
Hi Alois,
I found that the infinite loop inside the handledConnectedDataRecv() function of the CIPComLayer module is caused by the improper handling of the "mInterruptResp" variable.
When receiving a huge data stream of which the size is larger than "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 last response code (such as "e_ProcessDataOk") now turns to a wrong value. Therefore, the received data will not be handled by the top layer any longer.
To solve this problem, I create a patch that introduces one more variable in CIPCommlayer named "mLastInterruptResp" to record the previous response code of the recvData() function. Now, we don't need to allocate a very large buffer size even when the "FORTE_DYNAMIC_TYPE_LOAD" option is enabled, since the fragmented TCP data can be properly handled.
I also upload the patches for solving the memory leaks problem when the "FORTE_DYNAMIC_TYPE_LOAD" option is enabled. I am sorry that I am not so familiar with creating patches, but I hope that these patches may be usable.
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05807 seconds
] 
Search
Help
Register
Login
Home
