From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15233 invoked by alias); 28 Aug 2007 14:56:29 -0000 Received: (qmail 15164 invoked by uid 48); 28 Aug 2007 14:56:28 -0000 Date: Tue, 28 Aug 2007 14:56:00 -0000 Subject: [Bug java/33218] New: Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "cyberflex at mail dot ru" Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org X-SW-Source: 2007-q3/txt/msg00125.txt.bz2 When creating process (Process p = ...) which do not respond to Ctrl+C then behavior of destroy or waitFor or both is incorrect. Process blocking/discarding signal sent by Ctrl+C is not killed by destroy(). (The Process.destroy() supposed (IMHO) to kill the child process forcibly.) After calling destroy() other method waitFor() returns immediately instead of waiting (survived after the signal) process completion forever. Such behavior looks to be such a discrepancy. Test case: I encounted the problem when used following command line rfcomm listen -i hci0 /dev/rfcomm0 6 rfcomm doesn't react to Ctrl+C till external connection is accepted. Program code: Process p = p.destroy(); p.waitFor() System.out.println("waitFor completed"); ps ax | grep rfcomm Workaround for application: kill such processes explicitly with "kill -9" or kill subchildren of shell scripts by themselves using shell "trap" command. Not sure that the issue exists in 4.2.x, I haven't one to test with architectures I use. -- Summary: Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cyberflex at mail dot ru GCC host triplet: arm_le, x86 - native compilation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218