From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 10 19:01:17 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2D599C0 for ; Thu, 10 Jan 2013 19:01:17 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by mx1.freebsd.org (Postfix) with ESMTP id B19B5E6 for ; Thu, 10 Jan 2013 19:01:17 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id c14so1294991ieb.28 for ; Thu, 10 Jan 2013 11:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=oQvdjZ63bdrep+u04yHg1xS9QiuMA/P4C64ldC/1Bgo=; b=A6ETgRZqcIKm18IsLsKP1eYQObxAAH44RO0b/F3/5MZeR3w1s315I+wQzbU6l2D+8G 0c+AaDYrJ9dxTJOPgpHiRJKKjdNB6d5byDk6j1K7S95cSW+yTu5xJ3qDkbXVKN3Evf1V TN78wVulR8t3t/t5TpH5bsCa8UFBrFfpedg8g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer:x-gm-message-state; bh=oQvdjZ63bdrep+u04yHg1xS9QiuMA/P4C64ldC/1Bgo=; b=pYN7x7vu8MG8tav4NMZ3L6WrXZR1gff6DtJHQuZsMxG2IaaDXVy0/w9bayak4OXHmv +NRumxQbkkfdLSJ2zsXAj+AVbzlQOMWESWK4cMvsEvAdvi3TUe6aqwkwjv3yvK0iIjqs KJF9EDvs55B7+Pmh1Ho32egNrsWs4yVbvSi23Am6wobp+TG8+VQOkt8zbl2tY5BI31OI hdz+29Sv77QAtENrKwFcZIeq4vkeBVH0rHhAYu7ufHL10NEHQEz0dilDXBottQiiKLpo gpoithBNRa7O/Tne5X8DSNU7jLG2EQDyHybgCJB3sqWsA6XsupOgDYu36AmCwMZwtwGW EUJw== X-Received: by 10.50.196.130 with SMTP id im2mr6728918igc.17.1357844470824; Thu, 10 Jan 2013 11:01:10 -0800 (PST) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPS id v12sm2587622igv.3.2013.01.10.11.01.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Jan 2013 11:01:09 -0800 (PST) From: Kevin Day Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: __builtin_frame_address broken with self created stack? Message-Id: <4ADFB966-782C-4A4A-883C-0A9CFC0EC7A8@dragondata.com> Date: Thu, 10 Jan 2013 13:01:06 -0600 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnDvJCeGSyIk0RCcugLtVjCHnzgLhqyatEo2rwCE7BhhBqM0o/XymAiUPtDOlUCsUO3Zfih X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 19:01:17 -0000 I'm working on a project that uses State Threads (ports/devel/st). For = the unaware, it's a kinda neat library that implements totally userland = threads with setjmp/longjmp, manually creating stacks and moving the = stack pointer around. It works well, except for one problem, attempting to get a backtrace of = threads. Under linux, the state threads library uses execinfo to get a = backtrace. FreeBSD has libexecinfo in ports which basically is just a = wrapper around __builtin_frame_address and __builtin_return_address. This also mostly works. Except occasionally __builtin_frame_address will = segfault when executing in the context of a created stack. I'm kinda = lost how to debug this, because gdb seems entirely confused as to what = happened when the segfault is received, I'm guessing because this is a = builtin. It works 99% of the time, but under certain (somewhat = deterministic circumstances) __builtin_frame_address breaks. I realize this is breaking a whole lot of assumptions by mallocing some = memory, declaring it to be the new stack by using some assembly to move = the SP register. But, I'm having trouble figuring out what's actually = going wrong here. When it does work, libexecinfo's backtrace() function keeps stepping = back one frame at a time until it hits NULL. When it doesn't work, when = it reaches the frame that should have a NULL frame after it, it = segfaults. Breaking into gdb while using the stack that would kill = backtrace() and executing "bt" works okay - gdb is able to read that = frame anyway. Another datapoint is that this worked fine in FreeBSD 3.0, but that's a = pretty large set of changes to try to narrow down what's different now.=20= Anyone have any idea where to even start with this? I'm having trouble = finding anything that documents how frames work now, and what I'm = possibly not doing when creating a new stack by hand.