This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb/1744: sparc solaris Call hangs after attach to waiting process


The following reply was made to PR gdb/1744; it has been noted by GNATS.

From: Mark Kettenis <kettenis@chello.nl>
To: gdb-gnats@sources.redhat.com, woodylarue_1@earthlink.net, kettenis@gnu.org,
   larue@cadence.com
Cc:  
Subject: Re: gdb/1744: sparc solaris Call hangs after attach to waiting process
Date: Sat, 14 Aug 2004 13:04:35 +0200 (CEST)

 I can reproduce the problem with GDB 5.3, so this isn't caused by the
 sparc-tdep.c; but read on.  Also, the program doesn't actually hang
 *forever*; it just hangs for whatever remains of the 10000 seconds
 specified in the sleep.  That points out the problem.  On Solaris (and
 probably every host that uses SVR4-style procfs debugging), system
 calls aren't interrupted when GDB attaches.  So when we proceed after
 tweaking the registers as a response to the 'call dummy(5)' command,
 the sleep is resumed.
 
 Something did change between 5.3 and the current HEAD though.  With
 5.3, after the sleep finished, dummy() would correctly be called, and
 execution stops after we return from it.  With HEAD execution doesn't
 stop after dummy() returns; we just run until the program exits.
 
 So it seems that we have two issues here.  One's a genuine bug; we
 should stop after dummy() returns.  It's debatable whether the other
 issue is a bug though.  If we interrupt an interruptable system call
 when we attach, the program might not be able to deal with it.
 
 Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]