This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Broken malloc initialization?
- To: kaz at ashi dot footprints dot net
- Subject: Re: Broken malloc initialization?
- From: Wolfram Gloger <Wolfram dot Gloger at dent dot med dot uni-muenchen dot de>
- Date: Wed, 19 Jul 2000 19:22:12 +0200 (MDT)
- CC: libc-alpha at Sourceware dot Cygnus dot Com
- References: <Pine.LNX.4.10.10007190957410.22169-100000@ashi.FootPrints.net>
Hello,
> If you compile LinuxThreads so that compare-and-swap is defeated, so that the
> mutex lock resorts to relying on the spinlock field, a deadlock anomaly shows
> up in the malloc initialization code.
>
> Briefly, the initialization code commits the faux pas of calling
> pthread_mutex_unlock on an object that it has not previously locked, or, for
> that matter, initialized.
Hmm, strange. malloc.c:2715 can only be reached if line 2691 has been
passed, and the mutex is successfully locked. However,
pthread_mutex_trylock() is used there, not pthread_mutex_lock(), so
maybe you just forgot to change that function accordingly WRT the
spinlock field?
The mutex is initialized as part of ptmalloc_init(), which should have
been called before by malloc_hook_ini().
> (gdb) bt
> #0 0x8051741 in __libc_nanosleep ()
> #1 0x804bd1c in nanosleep (requested_time=0x7ffffb4c, remaining=0x0)
> at wrapsyscall.c:106
> #2 0x804bb96 in __pthread_acquire (spinlock=0x80a0d04) at spinlock.c:713
> #3 0x804b9f5 in __pthread_alt_unlock (lock=0x80a0d00) at spinlock.c:531
> #4 0x804cda0 in __pthread_mutex_unlock (mutex=0x80a0cf0) at mutex.c:179
> #5 0x804ebc5 in __libc_malloc (bytes=8) at malloc.c:2715
> #6 0x804e58c in malloc_hook_ini (sz=8, caller=0x8052ec9) at malloc.c:1756
> #7 0x804ea5d in __libc_malloc (bytes=8) at malloc.c:2681
> #8 0x8052ec9 in _dl_important_hwcaps (
> platform=0xfffffffc <Address 0xfffffffc out of bounds>, platform_len=0,
> sz=0x80a2674, max_capstrlen=0x80a2678) at dl-support.c:132
Regards,
Wolfram.