From owner-freebsd-hackers Tue Apr 24 17: 1:14 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from green.bikeshed.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A675237B422; Tue, 24 Apr 2001 17:01:11 -0700 (PDT) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.2/8.11.1) with ESMTP id f3P019i64830; Tue, 24 Apr 2001 20:01:10 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200104250001.f3P019i64830@green.bikeshed.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: Anyone know of RFMEM vm/sysv_shm.c-related races? In-Reply-To: Message from Alfred Perlstein of "Tue, 24 Apr 2001 09:16:50 PDT." <20010424091650.L1790@fw.wintelcom.net> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Apr 2001 20:01:08 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Brian F. Feldman [010424 05:07] wrote: > > In some way, using Linux LinuxThreads programs that use shared memory, I've > > ended up with dozens of shared memory segments that reportedly still have 1 > > attachment (which I'm really darn certain is impossible since I've killed > > _everything_ in sight). I think something must have happened that for some > > reason shmexit() was not called on process exit, vm_shm refcnt was increased > > too many times, vm_shm refcnt was not decreased enough times... whatever the > > case, there may be an old vmspace just floating around stranded, or just a > > simple bug with vm_shm... > > > > Does anyone have any clues about races or weird issues in this area? It's > > pretty exasperating to not be able to figure this one out. I don't > > immediately see any obvious races after half an hour of searching (since it > > appears all calls that can modify vmspace directly require Giant being held). > > sysv_shm registers atexit and atfork handlers, perhaps you can stick > some debugging code in there? BTW, it's easy enough to determine by a simple "cat /proc/*/map | grep [addr]" on the %p address from shmsegs[].shm_internal->'s object reference whether the segment is truly abandoned or not. I have a ton of these, which are absolutely certainly abandoned: m 15335469 0 --rwarwarwa green operator green operator 1 391168 37123 7674121:47:32 21:48:33 21:47:32 m 8060974 0 --rwarwarwa green operator green operator 1 483840 53214 7674122:16:44 22:17:46 22:16:44 m 4390959 0 --rwarwarwa green operator green operator 1 483840 53214 7674122:16:44 22:17:46 22:16:44 m 1441840 0 --rwarwarwa green operator green operator 1 483840 53214 7674122:16:44 22:17:46 22:16:44 etc. Has anyone else at least experienced this? I'm happy it's not a memory leak, but something definitely isn't calling shmexit() when it should be or calling shmfork() when it shouldn't be. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message