From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 4 09:06:18 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB4113BD for ; Wed, 4 Mar 2015 09:06:18 +0000 (UTC) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75A74FBA for ; Wed, 4 Mar 2015 09:06:18 +0000 (UTC) Received: by iecar1 with SMTP id ar1so65537207iec.11 for ; Wed, 04 Mar 2015 01:06:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/upjvPYSC3atkWHI/lrG6agRYXywakVjfsgLms+efdo=; b=WKFpIiSPgJF7z3/OR5+iVdCdYCX7Q3G44NW23Auk40x2YMHmcH+5rdzLS1B2akWWiS XxgR8qxJI5OnnhOYMsila1gezbVBmrJ6UJmaR2wkfcQNZORUAcEvX5Md4a2T496LnYWi GNQ7E+8Wegz8iNBI18dmvF8Kh/iZnnSWqvxwofPDN5d/RosKVfK07+/mdpv9xc6QRRI3 p1599xrnSvudLEZcQ+5aL3EXQjSMoMvwAYq4+VXm11R+4VCoQvzNbQz2Qah6fkYZ9jxj 6kN9wprCYPBi4Sd/HkzKqfNzjOHnwyTOqc8ZqAOJnQna7A+uCw2Jjf+c2xyvD//EK3h5 mh5A== MIME-Version: 1.0 X-Received: by 10.50.32.7 with SMTP id e7mr9138294igi.21.1425459977641; Wed, 04 Mar 2015 01:06:17 -0800 (PST) Received: by 10.107.28.193 with HTTP; Wed, 4 Mar 2015 01:06:17 -0800 (PST) Date: Wed, 4 Mar 2015 01:06:17 -0800 Message-ID: Subject: Glitch with textdump/ddb From: Shrikanth Kamath To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 09:06:18 -0000 I observed this with FreeBSD 10.1-RELEASE #0 running in VMware fusion, the boolean 'text dump' supplied to the function 'doadump' is some random value off the stack and not necessarily TRUE or FALSE. I am enabling a ddb script via the ddb utility, where my ddb script is ddb script kdb.enter.panic="textdump set; capture on; show pcpu; ps; call doadump" As per the man page to text dump, one is supposed to "call doadump" to trigger a text dump/minidump. So triggering panic via sysctl debug.kdb.panic=1, captures what is asked for in the above script. But if you observe the value of 'text dump' boolean in this snippet in kern_shutdown.c it is some random value and not the boolean TRUE or FALSE. int doadump(boolean_t textdump) { ... #ifdef DDB if (textdump && textdump_pending) { coredump = FALSE; textdump_dumpsys(&dumper); } #endif ... } But if I change the script to ddb script kdb.enter.panic="textdump set; capture on; show pcpu; ps; call doadump(1)" The value supplied to call doadump when the machine enters debugger on panic is now set to '1'. Should this be the right way to capture information when using text dumps? I guess the man page for textdump specifies just "call doadump". The problem may not manifest as long the random value picked off the stack is non zero. -- Shrikanth R K