Re: clang Failed assertion after the clang 3.2 RELEASE import

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..
....
> <jemalloc>: /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)