[issue2113] Bad interaction between signal and subprocess

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: fixed in release25-maint r65475. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2113] Bad interaction between signal and subprocess

Gregory P. Smith <[EMAIL PROTECTED]> added the comment: Fixed as Amaury described in trunk r64756. still needs backporting to release25-maint. ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue2113] Bad interaction between signal and subprocess

Sean Reifschneider <[EMAIL PROTECTED]> added the comment: Daniele: Please provide an updated version of this patch based on the feedback below. -- assignee: -> gregory.p.smith keywords: +patch nosy: +gregory.p.smith, jafo priority: -> normal type: crash -> behavior ___

[issue2113] Bad interaction between signal and subprocess

Amaury Forgeot d'Arc added the comment: First, this patch has a possible bug: if select() fails on the first iteration, wlist is left undefined, and the next instruction "if self.stdin in wlist" will fail. Second, I think that is is not a good idea to simply exit the loop on the first signal. In

[issue2113] Bad interaction between signal and subprocess

Daniele Varrazzo added the comment: Just noticed that in the patch "except select.error:" suffices instead of "except:"... __ Tracker <[EMAIL PROTECTED]> __

[issue2113] Bad interaction between signal and subprocess

Changes by Daniele Varrazzo: -- components: +Library (Lib) __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue2113] Bad interaction between signal and subprocess

Changes by Daniele Varrazzo: Added file: http://bugs.python.org/file9432/subprocess_signal_bug.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-l

[issue2113] Bad interaction between signal and subprocess

New submission from Daniele Varrazzo: During Popen.communicate(), if a signal is caught during the select(), an unhandled exception is raised, and the output gathered is lost. This means that a long running or hanged process can't be killed after a timeout (as shown in the attached example, wher