Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Settings changed) made by gvanrossum 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: Just van Rossum (jvr) 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: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- 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
