-
Notifications
You must be signed in to change notification settings - Fork 10
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
InstrFetchProhibited: AsyncClient::_close() -> _removeAllCallbacks #4
Comments
I've just increased the scope and added an extra validation that _socket is still -1 and got the following error after some minutes with 2 PCs updating values every 300ms.
Changes:
Exception:
|
I see you are using the ESPAsyncWebServer library. Which fork and branch are you using? I do all my tests with https://github.com/yubox-node-org/ESPAsyncWebServer/tree/yuboxfixes-0xFEEDC0DE64-cleanup because the base ESPAsyncWebServer had many locking issues that were analyzed and fixed by @0xFEEDC0DE64 , and which might be confused with issues in AsyncTCPSock. |
I'm using that fork and for the filesystem I'm using LittleFS |
Do you have a minimal reproducing case, and a clear set of instructions to reproduce this issue? As in, a sketch that sets up just enough to trigger the bug, and the instructions, such as "repeatedly fetch URL such and such until failure"? |
BTW, as of commit fea600a installed callbacks are never removed under any condition other than straight-up destruction of the object. You should test whether this fixes your bug. |
Hi
I've started using this lib due to the locking problems with the original asyncTCP.
Last week while doing some tests I got this error on 2 different projects. It seems that the pointer to _removeAllCallbacks was cleared. The only way I see this happening is by the destructor being called, although it seems very strange. I was trying to replicate the problem but it doesn't seem to be easy to force it to happen. Regarding heap I know that I'm ok. Just before it happened it was like this: Heap: Free:157588, Min:117616, Size:340244, Alloc:73304.
I believe we can increase the scope of the _asyncsock_mutex until the end of the close method. Other thing that might be happening is that the program counter is pointing to the next instruction after the problem. In this case it could be while doing this (if (_discard_cb) _discard_cb(_discard_cb_arg, this);). If the _error method is called right after checking if the pointer is null it will clear this pointer and generate the error. Either way increasing the scope of the _asyncsock_mutex should solve the problem.
This happened immediately after a simple post with less than 150bytes.
The text was updated successfully, but these errors were encountered: