From owner-freebsd-hackers Thu Mar 27 19:14:00 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id TAA15126 for hackers-outgoing; Thu, 27 Mar 1997 19:14:00 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA15120; Thu, 27 Mar 1997 19:13:50 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.8.5/8.8.5) with ESMTP id TAA28286; Thu, 27 Mar 1997 19:13:45 -0800 (PST) Message-Id: <199703280313.TAA28286@austin.polstra.com> To: smc@servtech.com Subject: Re: Anyone else seen this? Newsgroups: polstra.freebsd.hackers In-Reply-To: <333AA089.41C67EA6@servtech.com> References: <199703270427.XAA04344@dyson.iquest.net> <333AA089.41C67EA6@servtech.com> Organization: Polstra & Co., Seattle, WA Cc: dyson@freebsd.org, hackers@freebsd.org Date: Thu, 27 Mar 1997 19:13:45 -0800 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <333AA089.41C67EA6@servtech.com>, Shawn Carey wrote: > The problem is not GDB related, GDB just makes it clear when it > happens. When GDB has stopped the program (which is every time so far), > I have had no breakpoints or watchpoints set. Hmm, well I've just been messing around with it, and to me it does seem related to GDB. At least, I can make it happen reliably with GDB, but not without GDB. Mind you, I don't think it's a GDB bug. It's just that GDB writes into the text segments of the executables. On a -2.2 system (unknown vintage, sorry), I compiled hello.c with "cc -g": #include main(int argc, char *argv[]) { printf("Hello, world!\n"); return 0; } Then I started gdb on it, and set a breakpoint on "main". I ran it repeatedly (all from the same gdb invocation). Many, but not all, of the times, GDB gave me the message that the file had changed. I just tried it on a -current system from March 17th, and it exhibited the same behavior. In another window, I did repeated "ls -lT" commands on the executable. Its modtime did in fact change, though the appearance of each change lagged a bit behind the moment when GDB noticed the difference. I am pretty sure that lag was caused by the delays between "update" runs. (A "sync" reliably made the changes visible to "ls".) Hmmm ... Hey, this is pretty interesting. I set the breakpoint at main and alternamed "r" "c" "r" "c" ... over and over rapidly. (I.e.: run the program, continue past the breakpoint, program finishes, repeat.) It looked very much like I got the "has changed" message from GDB about every 30 seconds, which is the kern.update interval. Does this give you something to chew on, John Dyson? -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth