| Ticket UUID: | 010d8f3885642212cf2c65036dd4ad444e9f769e | ||
| Title: | tclEpollNotfy PlatformEventsControl panics if websocket disconnected | ||
| Type: | Bug | Created on: | 2024-12-01 23:42:44 |
| Submitter: | stevel | Assigned to: | jan.nijtmans |
| Subsystem: | 25. Channel System | Severity: | Important |
| Priority: | 5 Medium | Last modified: | 2026-03-06 09:31:11 |
| Status: | Closed | Closed by: | jan.nijtmans |
| Resolution: | Fixed | Closed on: | 2026-03-06 09:31:11 |
| Version: | 8.7+ | ||
About ticket 010d8f3885642212cf2c65036dd4ad444e9f769e
Now in branch fix-010d8f3885-tclEpollNotfy-websocket-panic and ready for review before merging
| Description: | ||||
The tclEpollNotfy PlatformEventsControl function panics if the TclOSfstat call returns -1, which occurs when using a websocket to a browser and the browser page is refreshed. Jan suggested changing the Panic call to LIST_REMOVE(filePtr, readyNode) to remove the filePtr from the hash table as that is more appropriate during the deletion of the handle, but that changes the behavior from a panic to a SIGSEGV. Tested on Ubuntu 22.04.4 LTS. Doesn't affect 8.6 since that doesn't have ePoll support on Linux. | ||||
| User Comments: | ||||
dkf added on 2024-12-02 14:13:55:
At the moment, it seems that the fstat call isn't doing anything useful. In particular, the contents of the statbuf aren't examined afterwards on success; at best, it changes what message we panic with. stevel added on 2024-12-02 23:59:41:
I've confirmed that just returning from PlatformEventsControl rather than a panic does avoid the crash. So that's a workaround albeit at the cost of a memory leak. Is that sufficient or should we keep looking for a better solution? oehhar added on 2025-03-24 10:16:18:
Dear Steve, dear Donal, thanks for this great action. Is the current source code comment sufficiant? Would it feasable to mention this ticket in a source code comment? I am wondering, why this ticket is shown as "new wiki page" in fossil timeline. Is it me? Thanks for all, Harald stevel added on 2025-03-24 11:38:45:
Comments added, link fixed jan.nijtmans added on 2026-03-06 09:31:11:
Fixed [e3ffca215ef8cf8a|here]. No problems with it reported. If this change causes newly found problems (which is not expected), please re-open this ticket | ||||