| Ticket UUID: | 010d8f3885642212cf2c65036dd4ad444e9f769e | |||
| Title: | tclEpollNotfy PlatformEventsControl panics if websocket disconnected | |||
| Type: | Bug | Version: | 8.7+ | |
| Submitter: | stevel | Created on: | 2024-12-01 23:42:44 | |
| Subsystem: | 25. Channel System | Assigned To: | jan.nijtmans | |
| Priority: | 5 Medium | Severity: | Important | |
| Status: | Open | Last Modified: | 2025-03-24 11:38:45 | |
| Resolution: | None | Closed By: | nobody | |
| Closed on: | ||||
| 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: |
stevel added on 2025-03-24 11:38:45:
Comments added, link fixed 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 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? 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. | |||
Attachments:
- tcl.patch [download] added by stevel on 2025-02-25 08:55:27. [details]