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.
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
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).
I think that I recently fixed the issue without being aware of this bug report. See base r353726 and base r354353.
(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