From owner-freebsd-current@FreeBSD.ORG Wed Jun 25 13:17:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0169CCDB; Wed, 25 Jun 2014 13:17:18 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8671E2697; Wed, 25 Jun 2014 13:17:17 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1Wzn4X-001ZNC-KQ>; Wed, 25 Jun 2014 15:17:09 +0200 Received: from g225011204.adsl.alicedsl.de ([92.225.11.204] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1Wzn4X-0035yd-Fh>; Wed, 25 Jun 2014 15:17:09 +0200 Date: Wed, 25 Jun 2014 15:17:04 +0200 From: "O. Hartmann" To: Dimitry Andric Subject: Re: [CURRENT]: weird memory/linker problem? Message-ID: <20140625151704.7a89e58c.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140622165639.17a1ba1e.ohartman@zedat.fu-berlin.de> <20140623163115.03bdd675.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/swp/xr4CKvrO0JYyfGdywK3"; protocol="application/pgp-signature" X-Originating-IP: 92.225.11.204 X-ZEDAT-Hint: A Cc: Adrian Chadd , FreeBSD CURRENT , Ian Lepore X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 25 Jun 2014 13:17:18 -0000 --Sig_/swp/xr4CKvrO0JYyfGdywK3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 23 Jun 2014 17:22:25 +0200 Dimitry Andric schrieb: > On 23 Jun 2014, at 16:31, O. Hartmann wrote: > > Am Sun, 22 Jun 2014 10:10:04 -0700 > > Adrian Chadd schrieb: > >> When they segfault, where do they segfault? > ... > > GIMP, LaTeX work, nothing special, but a bit memory consuming regrading= GIMP) I tried > > updating the ports tree and surprisingly the tree is left over in a unc= lean condition > > while /usr/bin/svn segfault (on console: pid 18013 (svn), uid 0: exited= on signal 11 > > (core dumped)). > >=20 > > Using /usr/local/bin/svn, which is from the devel/subversion port, perf= orms well, > > while FreeBSD 11's svn contribution dies as described. It did not hours= ago! >=20 > I think what Adrian meant was: can you run svn (or another crashing > program) in gdb, and post a backtrace? Or maybe run ktrace, and see > where it dies? >=20 > Alternatively, put a core dump and the executable (with debug info) in a > tarball, and upload it somewhere, so somebody else can analyze it. >=20 > -Dimitry >=20 Here I am again. So far, a report what I did. Regarding to the svn issue, I tried to recompile " make -C usr.bin/svn clean depend obj all install" with setting = "-O0 -g -DDEBUG" in /etc/make.conf and /etc/src.conf (disabling all the -O flags I = use usually). gdb complained about missing symbols. After the recompilation the= onboard "svn" didn't crash anymore and the strange story seems to continue. Firefox, so far, also crashed yesterday - out of the blue - with a bus erro= r (SIG 10). Rebooting solved the problem. I didn't recompile the system or any client w= ith DEBUG flags set on so far. So, sorry, this issue is still open, but it is not eve= n less weird. Next, today, I tried recompiling world. The build process fails on the box = in question with "my well known friend" relocation truncated to fit: R_X86_64_PC32 against symbol error. See below. I'm about to reboot the box and restart building world without having prior= to the build started any memory consuming applications. Since the problems seem to be "randomly" I ask myself whether this is someh= ow related to the ASLR stuff mentioned earlier in the list. I also will disable -O3 again= with the next build to ensure that CLANG isn't miscompilating something. As mentioned in the list before, I tried to find some CPU-burning and memor= y eating applications/tests, but since math/mprime is i386 only and sysutils/cpuburn= only covers "ancient" CPUs, I feel a bit lost in that task and leftover with memtest86 = (which indicated earlier no memory problems with the box). And by the way, I face several serious issues with the I/O performance on C= URRENT these days: it takes a long time until portmaster has stepped through the ports w= hich are about to be updated when CLANG compiler is compiling world/kernel in the ba= ckground. This phenomenon has grown worse since earlier this year (~ February).=20 Source at revision 267867. FreeBSD 11.0-CURRENT #0 r267816: Tue Jun 24 14:0= 2:22 CEST 2014 amd64. [...] c++ -O2 -pipe -O3 -O3 -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm= /include -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/utils/TableGen -I. -I/usr/src/usr.bin/clang/tblgen/../../../contrib/llvm/../../lib/clang/inclu= de -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MA= CROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebs= d11.0\" -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=3Dc++11 -= fno-exceptions -fno-rtti -Wno-c++11-extensions -static -L/usr/obj/usr/src/tmp/legacy/usr/= lib -o tblgen AsmMatcherEmitter.o AsmWriterEmitter.o AsmWriterInst.o CTagsEmitter.o CallingConvEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenInstructi= on.o CodeGenMapTable.o CodeGenRegisters.o CodeGenSchedule.o CodeGenTarget.o DAGI= SelEmitter.o DAGISelMatcher.o DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcher= Opt.o DFAPacketizerEmitter.o DisassemblerEmitter.o FastISelEmitter.o FixedLenDeco= derEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o OptParserEmitter.o PseudoLoweringEmit= ter.o RegisterInfoEmitter.o SetTheory.o SubtargetEmitter.o TGValueTypes.o TableGe= n.o X86DisassemblerTables.o X86ModRMFilters.o X86RecognizableInstr.o /usr/obj/usr/src/tmp/usr/src/usr.bin/clang/tblgen/..= /../../lib/clang/libllvmtablegen/libllvmtablegen.a /usr/obj/usr/src/tmp/usr= /src/usr.bin/clang/tblgen/../../../lib/clang/libllvmsupport/libllvmsupport.a -lncurses -legacy /usr/lib/libc.a(jemalloc_jemalloc.o): In function `imemal= ign': jemalloc_jemalloc.c:(.text+0x2605): relocation truncated to fit: R_X86_64_P= C32 against symbol `__je_arena_malloc_large' defined in .text section in /usr/lib/libc.a(jemalloc_arena.o) c++: error: linker command failed with= exit code 1 (use -v to see invocation) *** [tblgen] Error code 1 make[3]: stopped in /usr/src/usr.bin/clang/tblgen --Sig_/swp/xr4CKvrO0JYyfGdywK3 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJTqsvUAAoJEOgBcD7A/5N8MZ8H/0Ch250rZm0IFEr9x9YAoLqS Tv2mOVaeXNVR/F7cIqYRVWivv0Z378G0kwHk3nmVXeptOfNzl7Z51GpT1xEGF9Um W9m6peo67QdxgXOiuV5Q3Vj0wJ2plVZ6vddxUNzFYKHmJednJ6+/yJn6a+eDuYL0 q8SKxG6tOFYVQ8R2zldTpYr1Q3nyssmGtqLru6Y2Kp51n32GW0kymaxYi1q7CR3E m1P+ds3swBhQgt3OFp6ERKsINQBCC9TokOxiqq3iRk08Vg4DHbM2yUTc/r1a2LJQ c5e1O/ErA4ydie5YYGGObqinT+ubPYlOlrF8gjxRbkdYrKseU5BmyC2fzR1PHtU= =dlPP -----END PGP SIGNATURE----- --Sig_/swp/xr4CKvrO0JYyfGdywK3--