From owner-freebsd-current@FreeBSD.ORG Tue Sep 9 04:06:00 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CAAB106567A; Tue, 9 Sep 2008 04:06:00 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1C18FC25; Tue, 9 Sep 2008 04:06:00 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m8945v2p083544; Tue, 9 Sep 2008 04:05:58 GMT (envelope-from davidxu@freebsd.org) Message-ID: <48C5F68F.80101@freebsd.org> Date: Tue, 09 Sep 2008 12:07:43 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Jason Evans References: <48C15AEA.4070704@quis.cx> <48C2B6EB.5000608@FreeBSD.org> In-Reply-To: <48C2B6EB.5000608@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Jille Timmermans , FreeBSD Current Subject: Re: Segmentation fault in malloc_usable_size() (libc) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 09 Sep 2008 04:06:00 -0000 Jason Evans wrote: > Jille Timmermans wrote: >> I switched over to current a fews days ago. >> And I ran into a bug (file attached, log pasted): > > The stack trace you got is totally bogus, but the problem is real. This > crash is due to recent changes in malloc that use TLS for > thread-specific caching. The problem is that malloc is being used after > a thread has effectively exited. > > #0 0x00000008007c7b35 in arena_malloc (arena=0x500a98, size=80, > zero=true) at /usr/src/lib/libc/stdlib/malloc.c:3223 > #1 0x00000008007caf4b in calloc (num=1, size=80) at > /usr/src/lib/libc/stdlib/malloc.c:3395 > #2 0x0000000800649c94 in mutex_init (mutex=0x8009785c0, > mutex_attr=Variable "mutex_attr" is not available. > ) at /usr/src/lib/libthr/thread/thr_mutex.c:144 > #3 0x0000000800649f41 in init_static (thread=0x608e40, > mutex=0x8009785c0) at /usr/src/lib/libthr/thread/thr_mutex.c:188 > #4 0x000000080064ab31 in __pthread_mutex_lock (mutex=0x8009785c0) at > /usr/src/lib/libthr/thread/thr_mutex.c:445 > #5 0x000000080081c63c in __cxa_finalize (dso=0x0) at > /usr/src/lib/libc/stdlib/atexit.c:161 > #6 0x00000008007ccbe7 in exit (status=0) at > /usr/src/lib/libc/stdlib/exit.c:67 > #7 0x000000080064e5c6 in _pthread_exit (status=Variable "status" is not > available. > ) at /usr/src/lib/libthr/thread/thr_exit.c:109 > #8 0x0000000800646219 in thread_start (curthread=0x608e40) at > /usr/src/lib/libthr/thread/thr_create.c:288 > #9 0x0000000000000000 in ?? () > > The call to _malloc_thread_cleanup() in _pthread_exit() I added at > /usr/src/lib/libthr/thread/thr_exit.c:100 is too early in the case that > _thread_active_threads is decremented to 0 below. I don't know off the > top of my head what the best fix is (i.e. where the > _malloc_thread_cleanup() call is really safe); perhaps David Xu has a > suggestion. > > Thanks, > Jason > I propose following patch: Index: thread/thr_exit.c =================================================================== --- thread/thr_exit.c （版本 182882） +++ thread/thr_exit.c （工作副本） @@ -96,9 +96,6 @@ _thread_cleanupspecific(); } - /* Tell malloc that the thread is exiting. */ - _malloc_thread_cleanup(); - if (!_thr_isthreaded()) exit(0); @@ -109,6 +106,12 @@ exit(0); /* Never reach! */ } + THREAD_LIST_UNLOCK(curthread); + + /* Tell malloc that the thread is exiting. */ + _malloc_thread_cleanup(); + + THREAD_LIST_LOCK(curthread); THR_LOCK(curthread); curthread->state = PS_DEAD; if (curthread->flags & THR_FLAGS_NEED_SUSPEND) {