[Console] fix: console deinit always deadlocks - adds ability to unblock linenoise (try 2) (IDFGH-9188)

[chipweinberger]

Previous PR: #9983

I am re-opening this PR to get more traction on it.

This solves: #9974

Motivation:

• currently, console deinit causes a deadlock
• without deinit, we can't create consoles "as needed"
• for example, USB Serial JTAG console should be destroyed when entering USB host mode
• for example, "web" consoles should be destroyed when the browser window is closed

[chipweinberger]

If usb_serial_jtag.c starts using something other than a ringbuffer internally (e.g. a StreamBuffer), we would have to add similar API for unblocking there; and given that StreamBuffer is upstream FreeRTOS code we would most likely want to avoid that.

^ From Ivan.

Can you re-evaluate your position on this? vRingbufferUnblockRx seems like the ideal solution.

If we ever switched to StreamBuffer we could come up with alternative solutions. For example:

• A) a counting semaphore + StreamBuffer. 'give' the semaphore on new data + then call StreamBuffer with a 0 timeout. We'll then check if there enough data. During deinit, we'd "give" the semaphore another time in order to unblock the read, then return read() with error.
• B) Use a long timeout with StreamBuffer, perhaps 10 seconds, and poll an exit condition
• C) Make a Pull Request on FreeRTOS to add the necessary unblock feature to StreamBuffer

[chipweinberger]

Alternatively, ^^ solution (A), could be used to mitigate the need for vRingbufferUnblockRx in this PR as well.

I think the solution would look like this:

• normal exclusive mutex. Not entirely necessary. usb_serial_jtag_read_bytes will grab this mutex first. This makes sure the counting semaphore only has a single thread using it at a time. i.e. so the first thread to call read() will always be satisfied first.
• counting semaphore. usb_serial_jtag_isr_handler_default increments this counting semaphore once each time it appends to the ringbuffer, usb_serial_jtag_read_bytes will 'take' from the semaphore waiting until new bytes are ready (We could also use event_groups instead).
• ring buffer, usb_serial_jtag_read_bytes calls the ringbuffer with a zero timeout, and will wait on the counting semaphore again until there is enough data.

Of course, I would consider the vRingbufferUnblockRx solution already used in this PR better.

[SoucheSouche]

Hi @chipweinberger, I started looking into your PR. Can I ask you to rebase and fix the build issues and conflict with upstream?

[chipweinberger]

sure, one moment.

[chipweinberger]

@SoucheSouche updated.

[SoucheSouche]

rbGET_RX_SEM_HANDLE doesn't seem to be declared anywhere.

[chipweinberger]

This code must have changed. @SoucheSouche, I'm pretty behind and stressed about my own work at the moment. If you are able to update it that would be a great help.

edit: I updated the code to remove the semaphore. Threading needs more thought.

[SoucheSouche]

sure no problem!

[chipweinberger]

I wonder if we should move this from the flags, and into its own variable. That way we are less likely to hit threading problems from multiple flags sharing the same memory location.

[chipweinberger]

^ I'm not familiar enough with ringbuf to make this judgement call.

[CLAassistant]

All committers have signed the CLA.

[chipweinberger]

@SoucheSouche how are things going?

[SoucheSouche]

@chipweinberger, there has been some changes in the ring buffer so I am now looking at your PR again since the semaphores for rx and tx were removed.

But tomorrow is my last working day before my extended leaves so I will most likely not finish up before. Someone from my team will take over the console related PRs.

[chipweinberger]

since the semaphores for rx and tx were removed.

I updated the PR and removed the semaphores.

But as I was saying before I think we should move this bit: #define rbBUFFER_UNBLOCK_RX_FLAG ( ( UBaseType_t ) 32 ) to its own variable, to simplify race condition worries.

[SoucheSouche]

The other issue is that this comment is still valid and your current solution won't be accepted.

I am implementing an alternative to your changes using xTaskAbortDelay proposed solution.

[chipweinberger]

@SoucheSouche , did you understand Ivans comment? "Thinking about this again, select on a pair of file descriptors (stdin and eventfd) is probably the cleanest solution." I'm not sure what that solution would look like.

If you use xTaskAbortDelay, make sure the thread is not blocked in user code. 1. suspend the linenoise thread. 2. check its location.

[chipweinberger]

@SoucheSouche another idea - we could send a "enter" key event to vfs buffers to force the thread to exit line noise.

something like:

1. esp_linenoise_quit //prevent any further linenoise stdin reads or command lines being returned
2. usb_serial_jtag_write('\n')

[github-actions]

	Warnings
⚠️	Some issues found for the commit messages in this PR: the commit message "[Console] fix console deinit: add ability to unblock linenoise, to fix deadlock": summary looks empty type/action looks empty Please fix these commit messages - here are some basic tips: follow Conventional Commits style correct format of commit message should be: <type/action>(<scope/component>): <summary>, for example fix(esp32): Fixed startup timeout issue allowed types are: change,ci,docs,feat,fix,refactor,remove,revert sufficiently descriptive message summary should be between 20 to 72 characters and start with upper case letter avoid Jira references in commit messages (unavailable/irrelevant for our customers) TIP: Install pre-commit hooks and run this check when committing (uses the Conventional Precommit Linter).
⚠️	The source branch "user/chip/console-unblock-try2" incorrect format: contains more than one slash (/). This can cause troubles with git sync. Please rename your branch.

👋 Hello chipweinberger, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- Resolve all warnings (⚠️ ) before requesting a review from human reviewers - they will appreciate it.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by 🚫 dangerJS against f85938e

[SoucheSouche]

Hi @chipweinberger,
Sorry that I left this PR not updated for so long. I will get back at it this week. It's been a while so it might take a bit of time to get back into it but I will update you as I go through it.
Hopefully we will finally be able to merge it this time.

[SoucheSouche]

Hi @chipweinberger, a little update on the PR.
Since it was fairly old, I first had to rebase it on the latest master and realized that your solution was no longer working.
The concept of adding 2 states to the console repl is great and works just fine but the solution that you were using to force linenoise to return didn't seem to work.

I experimented with select as @igrr suggested and ended up finding a solution.
The very drafty logic implemented in linenoiseDumb() and linenoiseRaw() is the following:

[...]
        if (select(in_fd + 1, &read_fds, NULL, &except_fds, NULL) < 0) {
            // select returned with -1, handle the error
        }

        // std_in is either ready to read or an exceptional condition occurred
        if(FD_ISSET(in_fd, &except_fds)) {
            // exceptional condition occurred, return from linenoise back into the while loop
            // of `esp_console_repl_task` where the repl state will be reevaluated
            break;
        }
        else if(FD_ISSET(in_fd, &read_fds)) {
            // do the reading since std_in is ready for reading
        }
        else {
            continue;
        }

I kept uart_unblock_reads and usb_serial_jtag_unblock_reads and I make them fire an "exceptional condition" event that will make the select return and if(FD_ISSET(in_fd, &except_fds)) evaluated to true.

[chipweinberger]

seems like a reasonable solution!

impressive :) fun :)

[SoucheSouche]

I had to implement the select for the usb serial jtag driver so I will have to first merge this added feature before proceeding with the actual deadlock fix.
I will keep you posted.

[chipweinberger]

related: #9964 ([USB Serial JTAG] calling select() & poll() crashes)

[SoucheSouche]

Hi @chipweinberger,
a little update on the fix.
I am still waiting to merge the select() feature for the usb cdc and usb serial jtag drivers before I can merge the fix for the deadlock.
I will let you know when the select() features have been merged but it might take a little while.