From owner-freebsd-current@FreeBSD.ORG Tue Dec 25 23:59:13 2012 Return-Path: Delivered-To: Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7EF46625; Tue, 25 Dec 2012 23:59:13 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id F3AFB8FC13; Tue, 25 Dec 2012 23:59:12 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:cde0:313a:4474:ffe5] (unknown [IPv6:2001:7b8:3a7:0:cde0:313a:4474:ffe5]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 99E8A5C5A; Wed, 26 Dec 2012 00:59:04 +0100 (CET) Message-ID: <50DA3DC6.3030806@FreeBSD.org> Date: Wed, 26 Dec 2012 00:59:02 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20121128 Thunderbird/18.0 MIME-Version: 1.0 To: "Sam Fourman Jr." Subject: Re: clang Failed assertion after the clang 3.2 RELEASE import References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Baptiste Daroussin , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 25 Dec 2012 23:59:13 -0000 On 2012-12-26 00:13, Sam Fourman Jr. wrote: > for whatever reason, I get a Failed assertion error if I add a user to > the wheel group... but if I do not add to the wheel group all is > fine.. .... > : /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:698: > Failed assertion: "((uintptr_t)ptr - ((uintptr_t)run + > (uintptr_t)bin_info->reg0_offset)) % bin_info->reg_interval == 0" This is a bug in pw(8), introduced in r242349. It tries to reallocf(3) a pointer which is in the middle of a block malloc'd in getgrent, somewhere. How this can have ever worked properly is beyond me. :-) In any case, for now, it is probably easiest to downgrade usr.sbin/pw to r242348, and rebuild pw. Valgrind says the following: ==22014== Memcheck, a memory error detector ==22014== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==22014== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==22014== Command: /usr/obj/usr/src/usr.sbin/pw/pw useradd tester666 -G wheel -s /bin/tcsh -m -d /home/tester666 ==22014== ==22014== Invalid free() / delete / delete[] / realloc() ==22014== at 0x35367: realloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==22014== by 0x17BD26: reallocf (reallocf.c:37) ==22014== by 0x804DD22: pw_user (pw_user.c:761) ==22014== by 0x804A91A: main (pw.c:230) ==22014== Address 0x800534 is 20 bytes inside a block of size 1,024 alloc'd ==22014== at 0x346BB: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==22014== by 0x141C3C: ??? (getgrent.c:689) ==22014== by 0x141C01: getgrnam (getgrent.c:745) ==22014== by 0x804C268: pw_user (pw_user.c:251) ==22014== by 0x804A91A: main (pw.c:230) ==22014== ==22014== Invalid free() / delete / delete[] / realloc() ==22014== at 0x34DA7: free (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==22014== by 0x17BD40: reallocf (reallocf.c:46) ==22014== by 0x804DD22: pw_user (pw_user.c:761) ==22014== by 0x804A91A: main (pw.c:230) ==22014== Address 0x800534 is 20 bytes inside a block of size 1,024 alloc'd ==22014== at 0x346BB: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-x86-freebsd.so) ==22014== by 0x141C3C: ??? (getgrent.c:689) ==22014== by 0x141C01: getgrnam (getgrent.c:745) ==22014== by 0x804C268: pw_user (pw_user.c:251) ==22014== by 0x804A91A: main (pw.c:230) ==22014== ==22014== Invalid write of size 4 ==22014== at 0x804DD2C: pw_user (pw_user.c:764) ==22014== by 0x804A91A: main (pw.c:230) ==22014== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==22014== ==22014== ==22014== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==22014== Access not within mapped region at address 0x8 ==22014== at 0x804DD2C: pw_user (pw_user.c:764) ==22014== by 0x804A91A: main (pw.c:230) ==22014== If you believe this happened as a result of a stack ==22014== overflow in your program's main thread (unlikely but ==22014== possible), you can try to increase the size of the ==22014== main thread stack using the --main-stacksize= flag. ==22014== The main thread stack size used in this run was 16777216. ==22014== ==22014== HEAP SUMMARY: ==22014== in use at exit: 41,052 bytes in 57 blocks ==22014== total heap usage: 351 allocs, 295 frees, 526,854 bytes allocated ==22014== ==22014== LEAK SUMMARY: ==22014== definitely lost: 23 bytes in 2 blocks ==22014== indirectly lost: 16 bytes in 1 blocks ==22014== possibly lost: 0 bytes in 0 blocks ==22014== still reachable: 41,013 bytes in 54 blocks ==22014== suppressed: 0 bytes in 0 blocks ==22014== Rerun with --leak-check=full to see details of leaked memory ==22014== ==22014== For counts of detected and suppressed errors, rerun with: -v ==22014== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 2 from 1)