Delivered-To: listarch-cygwin AT sourceware DOT cygnus DOT com Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com From: Philippe Gerum MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 16 Feb 1999 20:21:41 +0000 (WET) To: cygwin AT sourceware DOT cygnus DOT com Subject: exit() / GDB problem in B20.1? X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14025.52532.397058.817057@santana> Hi, I'am currently having some troubles with an application which randomly hangs into exit() when traced by GDB. The winsup traces show correct epilog until ExitProcess() is called, then a 1-minute delay occurs. This problem only happens when GDB is involved. While the application is waiting, starting other cygwin-dependent tools make them hang too during initialization, then resume execution after the 1-minute timeout has elapsed. After some investigation, i've managed to change this behavior by patching the winsup sources in the do_exit() routine from winsup/dcrt0.cc. I've added an explicit "pinfo" mutex release by calling unlock_pinfo() after the process table is updated (record_death()). This patch seems to solve the problem. Is there any chance for a deadlock to occur with the process table mutex between the application and the debugger due to GDB's control over the debuggee? I'm not sure of my ground on this... Thanks for any help! Cheers