| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead. |
Sorry, something went wrong.
There was a problem hiding this comment.
Please add a blurb and a test.
Sorry, something went wrong.
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead. |
Sorry, something went wrong.
There was a problem hiding this comment.
I am just a past contributor, not a Python member.
I think the issue description and proposed change to _tkinter.c make sense. I have not reviewed the unit test.
However, I notice tfile being passed by address to Tcl_CreateFileHandler(); is there a particular reason for doing so? To avoid any potential stack-use-after-scope errors, such as if the while loop in EventHook() were to end because of errorInCmd rather than stdin_ready, I think it is better to pass tfile by value, even though that requires casting to avoid compiler warnings/errors (unless CPython already has some PTR2INT()/INT2PTR()-style macros I am unaware of).
Sorry, something went wrong.
| #ifndef MS_WINDOWS | ||
| tfile = fileno(stdin); | ||
| Tcl_CreateFileHandler(tfile, TCL_READABLE, MyFileProc, NULL); | ||
| Tcl_CreateFileHandler(tfile, TCL_READABLE, MyFileProc, &tfile); |
There was a problem hiding this comment.
| Tcl_CreateFileHandler(tfile, TCL_READABLE, MyFileProc, &tfile); | |
| Tcl_CreateFileHandler(tfile, TCL_READABLE, MyFileProc, (void *)(Py_intptr_t)tfile); |
Sorry, something went wrong.
| int *tfile = clientData; | ||
| stdin_ready = 1; | ||
| Tcl_DeleteFileHandler(*tfile); |
There was a problem hiding this comment.
| int *tfile = clientData; | |
| stdin_ready = 1; | |
| Tcl_DeleteFileHandler(*tfile); | |
| int tfile = (int)(Py_intptr_t)clientData; | |
| stdin_ready = 1; | |
| Tcl_DeleteFileHandler(tfile); |
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for looking into this. This is an important point.
The while-loop in EventHook can only be exited if either stdin_ready is 1 or errorInCmd is 1.
stdin_ready is set to 1 only in MyFileProc, which also calls Tcl_DeleteFileHandler. As the file handler is deleted, there won't be a dangling pointer.
But I was missing a call to Tcl_DeleteFileHandler for the case in which errorInCmd is 1, and MyFileProc was never called. Then then file handler will stay alive and will keep a dangling pointer to tfile after EventHook exits.
I fixed this by adding a call to Tcl_DeleteFileHandler to the if (errorInCmd) {... to ensure that the file handler is deleted before EventHook exits, and no pointer to tfile remains,
Sorry, something went wrong.
|
Let's keep this PR open for now. In particular, it would be better to get PR #140147 #148819 through first, as it would let us run the tests also on Windows. |
Sorry, something went wrong.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
|
I opened #152257, which builds on this — it keeps your MyFileProc fix, adds @chrstphrchvz's value-packing of the fd into clientData, deletes the handler on every loop-exit path (the result < 0 case), and also folds in the related gh-139816 hang since it's the same function. Credited you both as co-authors. Happy to go either way: land yours for gh-139145 and I'll rebase the rest on top, or take the combined PR. Thanks for digging into this. |
Sorry, something went wrong.
|
Thanks for looking into this.
I am fine either way too, so whatever is easiest for you is fine for me. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This pull request fixes the bug described in issue #139145 by moving the call to Tcl_DeleteFileHandler from EventHook to MyFileProc.
The reasoning behind this is: