Modbus - assert occurs when mbc_master_destroy is called while a transaction is still ongoing (IDFGH-3283)

[simon-thiebaut]

Environment

• Development Kit: Custom board
• Kit version: Custom board
• Module or chip used: ESP32-WROOM-32D
• IDF version (run git describe --tags to find it): v4.0-dev-2599-gcb9398aee (actually we've forked the repo to do modifications, but I have checked, the code chunk causing issue is up to date with the master repo)
• Build System: not relevant
• Compiler version (run xtensa-esp32-elf-gcc --version to find it): not relevant
• Operating System: not relevant
• (Windows only) environment type: not relevant
• Using an IDE?: not relevant
• Power Supply: Custom board

Problem Description

Our application needs to destroy the Modbus stack on the fly, while requests can still be pending.
What happens is that when it occurs, instruction "assert(0);" gets called in function eMBMasterWaitRequestFinish.

After investigations, here is what occurs:

• frames are sent independently by another task, so eMBMasterWaitRequestFinish is called repeatdly
• on an external and asynchronous event, mbc_master_destroy gets called (we need to use the same physical medium with another protocol, so we destroy Modbus to initialize the other protocol)
• EV_MASTER_NO_EVENT (value 0) gets received in function eMBMasterWaitRequestFinish, causing the assert.

The reason why event EV_MASTER_NO_EVENT gets called is that mbc_master_destroy calls vMBMasterPortEventClose which calls vEventGroupDelete(xEventGroupMasterHdl).
And the fact is that this FreeRTOS call will unblock any task waiting on the event group to be deleted by sending 0 before deleting the event group (see comment event_groups.c => /* Unblock the task, returning 0 as the event list is being deleted and cannot therefore have any bits set. */

For now, I have patched by replacing in eMBMasterWaitRequestFinish "assert(0);" by "eErrStatus = MB_MRE_TIMEDOUT;", so that current transaction finishes properly and sees unanswered frame as a timeout.

Expected Behavior

I was expecting to be able to destroy the Modbus stack safely whatever its state is.

Actual Behavior

Assert occurs when destroying the Modbus stack.

Steps to reproduce

1. In a dedicated thread, send Modbus request in loop
2. From another thread, triggers randomly the call of mbc_master_destroy

Debug Logs

...

[0;31mE (7780) MB_PORT_COMMON: eMBMasterWaitRequestFinish: Incorrect event or timeout xRecvedEvent = 0x0�[0m
assertion "0" failed: file "../esp-idf/components/freemodbus/port/portevent_m.c", line 284, function: eMBMasterWaitRequestFinish
abort() was calle�[0;31mE (d at PC 0x401ae2a7 on core 0

ELF file SHA256: 18944071bb28af0b60745f472cd4821d3f49699ada946576a7c2e1a9bfeb6bbf

Backtrace: 0x40091207:0x3ffdc9f0 0x40091660:0x3ffdca20 0x401ae2a7:0x3ffdca50 0x400e9b1a:0x3ffdca80 0x400eb82c:0x3ffdcac0 0x400e7c79:0x3ffdcaf0 0x400e7e9e:0x3ffdcb30 0x400e5c63:0x3ffdcba0 0x400d7f44:0x3ffdcbe0 0x400d76ec:0x3ffdcc30

Rebooting...
ets Jun 8 2016 00:22:57

...

Thank you for the feedback. Please let me know if you need further info or if stack is not expected to be used that why.

[Alvin1Zhang]

Thanks for reporting, we will look into.

[alisitsyn]

@simon-thiebaut,

Thank you for this issue and good description of it. I was able to reproduce the issue. Are you able to initialize and restart modbus communication after destroy?

[simon-thiebaut]

Thank you all for the feedback. So actually in our current use case:

• we destroy the Modbus stack
• initialize custom protocol stack over the same UART
• do tests
• reset board.

So for now unfortunately I cannot answer your question @alisitsyn ...
I'll give it a try as soon as I can and let you know.

[alisitsyn]

@simon-thiebaut,
The case with destroy was not tested and this change looks reasonable.
The issue is under review and will be merged as soon as possible.

[alisitsyn]

@simon-thiebaut,
The fix for this issue has been merged.

[simon-thiebaut]

@alisitsyn many thanks for the fix 👍 !