www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/02/16/19:29:28

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 <rpm AT axlog DOT fr>
MIME-Version: 1.0
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019