Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Nov 2006 11:19:07 -0800
From:      Jason Evans <jasone@FreeBSD.org>
To:        Rene Ladan <r.c.ladan@gmail.com>
Cc:        current@freebsd.org
Subject:   Re: libc/stdlib/malloc.c: assertion failed
Message-ID:  <4560AE2B.8080705@FreeBSD.org>
In-Reply-To: <45609145.9020104@gmail.com>
References:  <45609145.9020104@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Rene Ladan wrote:
> when starting the xfce4-panel (version 4.2.3) on
> 
>> FreeBSD s000655.campus.tue.nl 7.0-CURRENT FreeBSD 7.0-CURRENT #2:
>> Fri Nov 17 16:05:48 CET 2006     
>> root@s000655.campus.tue.nl:/usr/obj/usr/src-current/sys/RENE  i386
> 
> malloc.c fails with:
> 
>> Assertion failed: ((((uintptr_t)ptr) & (size - 1)) == 0), function arena_dalloc,
>> file /usr/src-current/lib/libc/stdlib/malloc.c, line 2423.
> 
> sources are of 2006-11-17 11:10 UTC
> 
> This happens in the "medium allocation" case, i.e. when mapelm.large ==
> true.

This is most likely due to an attempt to free() an object that was 
already freed.  The chances are high that this is an application bug, 
rather than a malloc bug.

If you want to track down the source of the problem, I recommend first 
looking at the backtrace for the core dump, and if that proves 
unenlightening, using the utrace facilities built into malloc to figure 
out when/where the object in question is used.

Jason

P.S.  The mapelm info that is used to calculate the run size one line 
before the assertion failure is only maintained for the first page in 
each run, so mapelm's contents may be (and probably are) completely 
misleading, due to the invalidity of the pointer being passed to free(). 
  The failed assertion is merely a high level sanity check; it does not 
catch all possible errors.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4560AE2B.8080705>