why malloc-simple's free() uses "__libc_free_aligned" by default?

Jun Sun jsun at junsun.net
Tue Mar 3 22:00:36 UTC 2009




On Tue, Mar 03, 2009 at 04:48:03PM +0800, jabin yan wrote:
> Can I add "#Undef L_memalign" in free.c to make free() directly
> calling munmap()?
> Does anybody know the side effect, especially in multi-threads development?
> 
> 

I took a look. It appears this checking is necessary if valloc() is
used. So unless you remove valloc() as well, I suspect it won't
even link.

(Check libc/stdlib/valloc.c file)

> With the version 0.9.27, I encoutered the deadlock issue same to:
> http://lists.busybox.net/pipermail/uclibc/2006-July/036888.html
> Has anybody verified its resolution as
> http://sources.busybox.net/index.py?view=rev&revision=23660 ?
>

I notice only two routines share the static mutex, __malloc_lock.
And none of them loops or hangs forever. So I would suggest the
following for futher debugging:

* Check to see if any thread is inside those routines and thus
  holding the mutex (although it is hard to see why this thread
  would get stuck inside these routines)

* Otherwise I suspect there is a memory corruption to __malloc_lock 
  variable. You will need to check the context of __malloc_lock to see
  if it is still sane. You can even further add some dummy variables
  before and after this __malloc_lock, fill them with some magic words
  and then double-check to see if these guarding variables are courrupted
  too.

* If that also looks good, I would double-check mutex locking code. Perhaps
  there is a bug in the code (although this is also hard to believe).

Cheers.

Jun

 


More information about the uClibc mailing list