From owner-freebsd-threads@FreeBSD.ORG Fri May 16 06:37:13 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EF4837B401 for ; Fri, 16 May 2003 06:37:13 -0700 (PDT) Received: from out005.verizon.net (out005pub.verizon.net [206.46.170.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5195B43FCB for ; Fri, 16 May 2003 06:37:12 -0700 (PDT) (envelope-from mtm@identd.net) Received: from kokeb.ambesa.net ([138.88.4.52]) by out005.verizon.net (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP id <20030516133711.DPA25152.out005.verizon.net@kokeb.ambesa.net>; Fri, 16 May 2003 08:37:11 -0500 Date: Fri, 16 May 2003 09:37:07 -0400 From: Mike Makonnen To: Munehiro Matsuda In-Reply-To: <20030516.124418.74754576.haro@kgt.co.jp> References: <20030516.124418.74754576.haro@kgt.co.jp> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386-portbld-freebsd5.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out005.verizon.net from [138.88.4.52] at Fri, 16 May 2003 08:37:07 -0500 Message-Id: <20030516133711.DPA25152.out005.verizon.net@kokeb.ambesa.net> cc: freebsd-threads@freebsd.org Subject: Re: libthr dies with 'Illegal call from signal handler' X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 13:37:13 -0000 On Fri, 16 May 2003 12:44:18 +0900 (JST) Munehiro Matsuda wrote: > Hi all, > > I'm trying out the latest libthr.so and occasionally get following error > which kills application. > > Fatal error 'Illegal call from signal handler' at line 1352 in file > /usr/src/lib/libthr/thread/thr_mutex.c (errno = 0) This normally happens when a thread goes to queue on a mutex or cv (in your case it's a mutex) and finds out it's already on one of the queue's. Normally, a thread is suspended while on a queue, so the reasoning is that if it's hitting this assertion it must be in a signal handler, but since libthr is not fully locked yet this may not be the case. > > Now, what can I do to help debug this problem? > Well, it would be very helpful if you could recompile the application, libthr, and libc with debuging symbols and post a backtrace. Also, the following patch will print more information on the thread and which queue it's on. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 mtm@FreeBSD.Org| FreeBSD - The Power To Serve Index: lib/libthr/thread/thr_mutex.c =================================================================== RCS file: /home/ncvs/src/lib/libthr/thread/thr_mutex.c,v retrieving revision 1.6 diff -u -r1.6 thr_mutex.c --- lib/libthr/thread/thr_mutex.c 12 May 2003 10:48:02 -0000 1.6 +++ lib/libthr/thread/thr_mutex.c 16 May 2003 13:24:53 -0000 @@ -1347,8 +1347,16 @@ static inline void mutex_queue_enq(pthread_mutex_t mutex, pthread_t pthread) { + char *name; pthread_t tid = TAILQ_LAST(&mutex->m_queue, mutex_head); + name = pthread->name ? pthread->name : "(null)"; + if ((pthread->flags & PTHREAD_FLAGS_IN_CONDQ) != 0) + _thread_printf(2, "Thread (%s:%u) already on condq\n", + pthread->name, pthread->uniqueid); + if ((pthread->flags & PTHREAD_FLAGS_IN_MUTEXQ) != 0) + _thread_printf(2, "Thread (%s:%u) already on mutexq\n", + pthread->name, pthread->uniqueid); PTHREAD_ASSERT_NOT_IN_SYNCQ(pthread); /* * For the common case of all threads having equal priority,