From owner-freebsd-ports@FreeBSD.ORG Sun Feb 7 19:35:38 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30082106568B; Sun, 7 Feb 2010 19:35:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 924B38FC19; Sun, 7 Feb 2010 19:35:37 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 25so494805eya.3 for ; Sun, 07 Feb 2010 11:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=qahzooPO0c8SxURVWYQw0Bh11ul8ITBJCi30GDvJ4/w=; b=WJSievWB+LMpvofELWdtdHngQj3b6WNYNRiNAPFKRcSubmMMkLIj93EQL3xxsqgDDc ioy1zcuYVyxDItSRxZRbVB1LM/P8n8G+BDRQcCYz6eJvNR4YvcqxGP4VQewapi6BINi4 JAowyBjnskeyg5ASQ+aBuC5/HJg4gc/z72o3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=N0eaZS9HWfE+xro7Tps/kqNufedk/KFvow0pFD0tIJU47BJtFJWXhZ7EuQCLA5hQZ5 RL3HESkaAcdMw16U8ggpq93NbsoBVaijLYJa+SrR1lAsKPUdJdJ/yYH/4YxhIXtjqEXh xJHuIQm2NDYONWOB5WPfjbVV60OOpL0qEBgyM= MIME-Version: 1.0 Received: by 10.213.103.134 with SMTP id k6mr3086990ebo.2.1265569578257; Sun, 07 Feb 2010 11:06:18 -0800 (PST) Date: Sun, 7 Feb 2010 14:06:18 -0500 Message-ID: From: Ryan Stone To: freebsd-ports@freebsd.org Content-Type: multipart/mixed; boundary=00504502d3bc268f15047f07610a X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stas@FreeBSD.org Subject: TLS(and by extension all threading) completely broken in Valgrind on i386/amd64 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 19:35:38 -0000 --00504502d3bc268f15047f07610a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've been trying out valgrind on some threaded FreeBSD applications but they've been deadlocking at startup. =A0I've identified that the root cause is that FreeBSD's thread local storage is not being emulated properly by valgrind. =A0The problem on amd64 is obvious: valgrind gives an invalid opcode error when the program tries to execute any instruction that accesses the gs register. =A0On i386 the problem is much more subtle. I've attached two test applications that demonstrate the problem. =A0In pthread_self.c, I create one thread which periodically prints pthread_self(), and then 10 seconds later I create a second thread. After the second thread is created, the first thread believes that it is the second thread. =A0Here's an example invocation: =3D=3D883=3D=3D Memcheck, a memory error detector =3D=3D883=3D=3D Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et= al. =3D=3D883=3D=3D Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyrigh= t info =3D=3D883=3D=3D Command: ./pthread_self =3D=3D883=3D=3D 0x18c180 0x18c180 0x18c180 0x18c180 0x18c180 0x18c180 0x18c180 0x18c180 0x18c180 1st: 0x18c180 2nd: 0x18d390 0x18d390 0x18d390 0x18d390 0x18d390 0x18d390 0x18d390 0x18d390 0x18d390 0x18d390 0x18d390 Note that first thread correctly prints that its pthread_t is 0x18c180 before the second thread is created, but after the second thread is created both threads report that they are 0x18d390! As far as I can tell, all threads use the thread local storage of the last thread created. This completely breaks libthr's mutexes, as mutex.c demonstrates. In that test app, the main thread acquires a mutex and then creates a new thread, then it tries to unlock the mutex. The unlock fails with EPERM, which is returned by pthread_mutex_unlock when a thread tries to acquire a mutex that it does not own. This behaviour is likely the cause of all of the "false positives" from helgrind. Helgrind is correctly noting that the libthr internals are using the same memory in different threads, because the threads think that they are touching thread-local memory. I've found the point in the thr_new syscall wrapper where valgrind notes the TLS area, but I can't figure out how it uses the information, so I'm stuck in figuring out why valgrind is getting this wrong. Anyone have any ideas? I'm not subscribed to this list so please CC me on any replies. --00504502d3bc268f15047f07610a--