Bug 183024 - textdump(4) mentions call doadump, should be textdump dump
Summary: textdump(4) mentions call doadump, should be textdump dump
Status: In Progress
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-16 13:50 UTC by Anton Shterenlikht
Modified: 2019-11-11 09:22 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Shterenlikht 2013-10-16 13:50:00 UTC
This example in textdump(4) is confusing:

           script kdb.enter.panic=textdump set; capture on; show allpcpu; bt;
             ps; alltrace; show alllocks; call doadump; reset

because it includes "call doadump" with will
create a traditional vmcore* dump.

This command should be replaced with "textdump dump":

           script kdb.enter.panic=textdump set; capture on; show allpcpu; bt;
             ps; alltrace; show alllocks; textdump dump; reset

Also, when using "call doadump", then "textdump set"
is ignored, and so is TEXTDUMP_PREFERRED kernel option.
This is not clear from the man page.

Fix: 

I can make a patch if there is agreement
that my understanding is correct.
Comment 1 Sevan Janiyan 2014-05-30 19:56:47 UTC
Hi, the configuration section states:

"By default, kernel dumps generated on panic or	via explicit requests 
for a dump will be regular memory dumps; how-ever, by using the	textdump 
set command in	ddb(4),	or by setting the debug.ddb.textdump.pending 
sysctl to 1 using sysctl(8), it is possible to request that the next 
dump be a textdump."

when you call doadump, the textdump is created, it's not possible to set 
the type after requesting a dump because the dump happens there & then 
on call.

On 10.0-RELEASE TEXTDUMP_PREFERRED is honored.
Entering the debugger & running call doadump outputs
textdump: creating 'ddb.txt'.
textdump: creating 'config.txt'.
textdump: creating 'msgbuf.txt'.
textdump: creating 'msgbuf.txt'.
textdump: creating 'version.txt'.
Textdump complete.
= 0
Comment 2 sigsys 2019-11-11 00:25:54 UTC
There's another problem with the textdump(4) example configuration.  At some point doadump() was modified to take a boolean argument that indicates if textdumps should be attempted at all (if it is 0, it won't do a textdump even if textdump_pending is set).

I had a computer that used to do textdumps correctly that one day did not when it paniced.  IIUC ddb(4)'s "call" ends up passing stack garbage when arguments are not initialized.  And it must usually have had a non-zero value for the first argument but this time it ended up being zero.

Both share/man/man4/textdump.4 and sbin/ddb/ddb.conf should be modified with "call doadump(1)" or "textdump dump" (in the later case, "textdump set" would be superfluous).
Comment 3 Andriy Gapon freebsd_committer 2019-11-11 08:01:38 UTC
I think that I recently fixed the issue without being aware of this bug report.
See base r353726 and base r354353.
Comment 4 sigsys 2019-11-11 09:22:02 UTC
(In reply to Andriy Gapon from comment #3)
Sure seems like you did!  Thanks.  I forgot to check if it had already been fixed after finding this PR.

For reference, I just checked if making sure that debug.ddb.textdump.pending is set or that having "textdump set" in the DDB script is necessary, and it is not.  "textdump dump" tries to do a textdump no matter what.

I wish the manpage gave some pointer to "debug.debugger_on_panic" though (I had the KDB_UNATTENDED option when trying to set this up and ddb wasn't being invoked at all).

Index: share/man/man4/textdump.4
===================================================================
--- share/man/man4/textdump.4   (revision 354599)
+++ share/man/man4/textdump.4   (working copy)
@@ -158,13 +158,21 @@
 .Dv kdb.enter.panic
 will run when the kernel debugger is entered as a result of a panic, enable
 output capture, dump several useful pieces of debugging information, and then
-invoke panic in order to force a kernel dump to be written out followed by a
-reboot:
+do a textdump followed by a reboot:
 .Bd -literal -offset indent
 script kdb.enter.panic=textdump set; capture on; show allpcpu; bt;
   ps; alltrace; show alllocks; textdump dump; reset
 .Ed
 .Pp
+Note that
+.Xr ddb 4
+must be set to be invoked on panic for this to work.
+The
+.Dv debug.debugger_on_panic
+sysctl indicates if this is the case
+(it will default to off if the kernel was compiled with
+.Cd options KDB_UNATTENDED ) .
+.Pp
 In the following example, the script
 .Dv kdb.enter.witness
 will run when the kernel debugger is entered as a result of a witness