From owner-freebsd-current Thu Jun 27 7:45:41 2002 Delivered-To: freebsd-current@freebsd.org Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by hub.freebsd.org (Postfix) with ESMTP id 4437237B401; Thu, 27 Jun 2002 07:45:17 -0700 (PDT) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.12.4/8.12.4) with ESMTP id g5REjC25015496; Thu, 27 Jun 2002 07:45:12 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.12.4/8.12.4/Submit) id g5REjCY1015495; Thu, 27 Jun 2002 07:45:12 -0700 (PDT) Date: Thu, 27 Jun 2002 07:45:12 -0700 (PDT) From: David Wolfskill Message-Id: <200206271445.g5REjCY1015495@bunrab.catwhisker.org> To: des@FreeBSD.ORG, sheldonh@starjuice.net Subject: Re: i386 tinderbox failure Cc: current@FreeBSD.ORG In-Reply-To: <20020627143336.GG18764@starjuice.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >Date: Thu, 27 Jun 2002 16:33:36 +0200 >From: Sheldon Hearn >> Wed Jun 26 19:00:10 PDT 2002 >> /usr/libexec/ld-elf.so.1: /usr/bin/cvs: Shared object has no run-time symbol table >I got this testing the RMEM_LIMIT patches, but it only crops up after >about an hour of heavy ports building. You'll get this for just any >binary that uses mmap(). I managed to get it while building today's -CURRENT (running -CURRENT form yesterday). Backing down to the previous day's kernel allowed me to get through the build process. (It had died during "stage 4: populating /usr/obj/usr/src/i386/usr/include," and I'm well byond that for the present build -- I'm in the install phase.) >Unfortunately, I haven't had time to produce any useful debugging >information, so I can't be sure it's really the RMEM_LIMIT patches. Well, the following is a list of each file under /usr/src/sys that changed between the two kernels: U sys/conf/NOTES U sys/conf/files U sys/conf/options U sys/ddb/db_examine.c U sys/ddb/db_expr.c U sys/i386/i386/pmap.c U sys/kern/kern_exec.c U sys/kern/kern_jail.c U sys/kern/kern_module.c U sys/kern/kern_subr.c U sys/kern/uipc_cow.c U sys/kern/uipc_jumbo.c U sys/kern/uipc_socket.c U sys/kern/uipc_syscalls.c U sys/modules/ti/Makefile U sys/net/if_media.c U sys/netinet/ip_output.c U sys/pci/if_ti.c U sys/pci/if_tireg.h U sys/pci/ti_fw.h U sys/pci/ti_fw2.h U sys/sparc64/include/pmap.h U sys/sparc64/sparc64/bus_machdep.c U sys/sparc64/sparc64/pmap.c U sys/sys/jumbo.h U sys/sys/mbuf.h U sys/sys/resource.h U sys/sys/socketvar.h U sys/sys/tiio.h U sys/sys/uio.h U sys/ufs/ufs/ufs_readwrite.c U sys/vm/device_pager.c U sys/vm/uma_core.c U sys/vm/vm_fault.c U sys/vm/vm_map.c U sys/vm/vm_map.h U sys/vm/vm_mmap.c U sys/vm/vm_object.c U sys/vm/vm_object.h U sys/vm/vm_page.c U sys/vm/vm_page.h U sys/vm/vm_unix.c so I have a fair degree of confidence that changes to some subset of the above files was responsible. And this is on a PIII, so the sparc64 files are unlikely to have been to blame.... :-} Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill david@catwhisker.org Trying to support or use Microsoft products makes about as much sense as painting the outside of a house with watercolors. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message