public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cyberflex at mail dot ru" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug java/33218] New: Process.waiFor() Process.destroy() misbehave for childs which are not reacting to Ctrl+C SIGQUIT Date: Tue, 28 Aug 2007 14:56:00 -0000 [thread overview] Message-ID: <bug-33218-14857@http.gcc.gnu.org/bugzilla/> (raw) 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 = <rfcomm ...> 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
next reply other threads:[~2007-08-28 14:56 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-08-28 14:56 cyberflex at mail dot ru [this message] 2007-08-28 15:59 ` [Bug java/33218] " daney at gcc dot gnu dot org 2007-08-28 16:43 ` cyberflex at mail dot ru 2007-08-28 16:56 ` daney at gcc dot gnu dot org 2007-08-29 6:19 ` daney at gcc dot gnu dot org 2007-08-29 6:19 ` daney at gcc dot gnu dot org 2007-08-29 10:17 ` cyberflex at mail dot ru 2007-08-30 9:34 ` cyberflex at mail dot ru 2007-08-30 9:35 ` cyberflex at mail dot ru 2007-08-30 9:36 ` cyberflex at mail dot ru 2007-08-30 9:37 ` cyberflex at mail dot ru 2007-08-30 9:41 ` cyberflex at mail dot ru 2007-08-30 17:44 ` daney at gcc dot gnu dot org 2007-08-31 9:43 ` cyberflex at mail dot ru 2009-01-02 12:21 ` laurent at guerby dot net
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-33218-14857@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).