From owner-freebsd-current@FreeBSD.ORG Thu Nov 2 18:19:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B32B816A40F; Thu, 2 Nov 2006 18:19:31 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from ms-smtp-01.southeast.rr.com (ms-smtp-01.southeast.rr.com [24.25.9.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id C95E343D75; Thu, 2 Nov 2006 18:19:21 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-01.southeast.rr.com (8.13.6/8.13.6) with ESMTP id kA2IJJ9f003386; Thu, 2 Nov 2006 13:19:19 -0500 (EST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.8/8.13.8) with ESMTP id kA2IImt4093302; Thu, 2 Nov 2006 13:18:48 -0500 (EST) (envelope-from morganw@chemikals.org) Date: Thu, 2 Nov 2006 13:18:48 -0500 (EST) From: Wesley Morgan To: Daniel Eischen In-Reply-To: Message-ID: <20061102130420.B90169@volatile.chemikals.org> References: <454936CA.6060308@FreeBSD.org> <20061101200949.2d21ace0@kan.dnsalias.net> <20061102080524.R80586@volatile.chemikals.org> <20061102081122.2c99552f@kan.dnsalias.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: current@freebsd.org Subject: Re: libpthread shared library version number X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2006 18:19:31 -0000 On Thu, 2 Nov 2006, Daniel Eischen wrote: > On Thu, 2 Nov 2006, Alexander Kabaev wrote: > >> On Thu, 2 Nov 2006 08:07:03 -0500 (EST) >> Wesley Morgan wrote: >> >> >>> I encountered (and reported) weird problems with threaded apps when >>> symbol versioning was enabled. The new csup would fail in areas it >>> shouldn't have failed and gdb made it look like some weird stuff was >>> happening concurrently. Turning off symbol versioning solved the >>> problem. >>> >>> >> Could you please report it again? Searching for your name in my inbox >> returns nothing. Your mail either never reached it or you sent the >> report elsewhere and it escaped my attention. > > If you are using libthr or libc_r with symbol versioning, then > I don't think it will work correctly without rebuilding world > and all ports. As an interim solution for testing symbol versioning > without require rebuilding everything under the sun, I added > compatability hacks for symbols in libc that also exist in > libpthread. See lines 62-95 in src/lib/libpthread/thr/thr_private.h. > This hack should be disabled and removed after bumping shared > libraries and enabling symbol versioning. My original report was here: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=353076+0+archive/2006/freebsd-current/20060806.freebsd-current I swapped a few e-mails with Maxime Henrion, but the gist of things was that after enabling symbol versioning, I immediately rebuilt everything -- world, ports, kernel. The random crashes I experienced were most apparent with two applications, csup and games/uqm from ports. Xorg would also crash every now and then... An example of what gdb showed me is: Updating collection ports-all/cvs Checkout ports/devel/ccrtp/Makefile Error set: No such file or directory Updater failed: Cannot create directories leading to "/usr/ports/devel/ccrtp/Makefile": Unknown error: 0 Breakpoint 1, mkdirhier (path=0x8c40180 "/usr/ports/devel/ccrtp", mask=18) at misc.c:293 293 errno = 0; (gdb) n 294 if (access(path, F_OK) == 0) { (gdb) 298 perror("Error set"); (gdb) Error set: No such file or directory 299 if (errno != ENOENT) { (gdb) 300 path[i] = '/'; (gdb) print errno $1 = 0 (gdb) It seems that errno is being changed somewhere else?? I'm getting all kinds of wild results checking errno during execution in gdb. Sometimes it claims to be 2 or 22, sometimes 0. I'll have to build a UP kernel and see if that fixes the problem. Trying to use libthr instead of libpthread dies strangely in thr_getscheduler(). Ugh. Switching to a UP kernel did not resolve the issue, but going back to non-versioned libraries did. That was a real PITA to do without rebooting, too! -- This .signature sanitized for your protection