Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470
Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: Tim Peters (tim_one) >Assigned to: Guido van Rossum (gvanrossum) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once <wink>: and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
