What Goes In A Problem Report
A database is only as good as the data that goes into it. In general, common sense (assuming such an animal exists) dictates the kind of information that would be most helpful in tracking down and resolving problems in software.
- Include anything you would want to know if you were looking at the report from the other end. There's no need to include every minute detail about your environment, although anything that might be different from someone else's environment should be included (your path, for instance).
- Narratives are often useful, given a certain degree of restraint. If a person responsible for a bug can see that A was executed, and then B and then C, knowing that sequence of events might trigger the realization of an intermediate step that was missing, or an extra step that might have changed the environment enough to cause a visible problem. Again, restraint is always in order ("I set the build running, went to get a cup of coffee (Columbian, cream but no sugar), talked to Sheila on the phone, and then THIS happened...") but be sure to include anything relevant.
- Richard Stallman writes,
This holds true across all problem reporting systems, for computer software or social injustice or motorcycle maintenance. It is especially important in the software field due to the major differences seemingly insignificant changes can make (a changed variable, a missing semicolon, etc.).
The fundamental principle of reporting bugs usefully is this: report all the facts. If you are not sure whether to state a fact or leave it out, state it!
- Submit only one problem with each Problem Report. If you have multiple problems, use multiple PRs. This aids in tracking each problem and also in analyzing the problems associated with a given program.
- It never hurts to do a little research to find out if the bug you've found has already been reported. Most software releases contain lists of known bugs in the Release Notes which come with the software. In addition, it's a good idea to search the NetBSD GNATS problem report database to see if someone already reported the problem you're having (who knows? there might already be a fix or work-around in the database).
- The more closely a PR adheres to the standard format, the less interaction is required by a database administrator to route the information to the proper place. Keep in mind that anything that requires human interaction also requires time that might be better spent in actually fixing the problem. It is therefore in everyone's best interest that the information contained in a PR be as correct as possible (in both format and content) at the time of submission. See a description of the fields in a problem report for more details.
So, the kernel panic'd, and gave you a whole lot of hexadecimal numbers, and halted. It's important for you to report this event, since real operating systems should never crash or panic, unless the computer hardware fails egregiously (there's usually not much an OS can do about hardware failure). That leaves kernel bugs as the other cause of a panic, and we need to track down those bugs and squash them to make NetBSD even more stable and robust than it already is.
The trouble is that the stack dump that the kernel printed is specific to your kernel, and the numbers really have to be converted back into symbol table references so that someone else who doesn't have your system's kernel can get an accurate picture of where it decided to die.
At a minimum, copy down the "PC" numbers and convert them to symbolic references - that's the Program Counter for the computer; where it was executing. Ideally, if you can arrange to cut & paste the whole thing, that's even better.
So, when the kernel gives you this (usually several lines of this):
pc = 0xf80ff430 args = (0x0, 0x41001fe5, 0xf8139c00, 0xf8123d20, 0xf8101e38, 0xf8143800, 0xf8123c68) fp = 0xf8123c68 |
The PC number is specific to the kernel you were running, and is not likely to be the same as anyone else's kernel, so it must be converted to a symbol reference. To convert a hexadecimal PC value to symbolic reference, use gdb(1), in the following way:
gdb -k /netbsd x 0xf80ff430 0xf80ff430 <cpu_reboot+196>: 0x40000093 |
That "<cpureboot+196>" result from gdb(1) is what the people who will work on the problem report will need, so put it (preferably along with the rest of that "args" line) into your problem report.
See problem report #3765 for an example of an exhaustive PR on a kernel panic.
[Page top] [GNATS summary] [Query PR] [PR fields] [PR states]
![[NetBSD flag]](/images/NetBSD-flag.png)
Copyright © 1994-2006 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
NetBSD® is a registered trademark of The NetBSD Foundation, Inc.