The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: answer/para
Context English State
However, the best way to track down the cause of a panic is by capturing a crash dump, then using <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> to generate a stack trace on the crash dump.
In any case, the method is this:
Make sure that the following line is included in the kernel configuration file:
makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols
Change to the <filename>/usr/src</filename> directory:
<prompt>#</prompt> <userinput>cd /usr/src</userinput>
Compile the kernel:
<prompt>#</prompt> <userinput>make buildkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput>
Wait for <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> to finish compiling.
<prompt>#</prompt> <userinput>make installkernel KERNCONF=MYKERNEL</userinput>
If <varname>KERNCONF</varname> is not included, the <filename>GENERIC</filename> kernel will instead be built and installed.
The <citerefentry><refentrytitle>make</refentrytitle><manvolnum>1</manvolnum></citerefentry> process will have built two kernels. <filename>/usr/obj/usr/src/sys/MYKERNEL/kernel</filename> and <filename>/usr/obj/usr/src/sys/MYKERNEL/kernel.debug</filename>. <filename>kernel</filename> was installed as <filename>/boot/kernel/kernel</filename>, while <filename>kernel.debug</filename> can be used as the source of debugging symbols for <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
To capture a crash dump, edit <filename>/etc/rc.conf</filename> and set <literal>dumpdev</literal> to point to either the swap partition or <literal>AUTO</literal>. This will cause the <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry> scripts to use the <citerefentry><refentrytitle>dumpon</refentrytitle><manvolnum>8</manvolnum></citerefentry> command to enable crash dumps. This command can also be run manually. After a panic, the crash dump can be recovered using <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry>; if <literal>dumpdev</literal> is set in <filename>/etc/rc.conf</filename>, the <citerefentry><refentrytitle>rc</refentrytitle><manvolnum>8</manvolnum></citerefentry> scripts will run <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> automatically and put the crash dump in <filename>/var/crash</filename>.
FreeBSD crash dumps are usually the same size as physical RAM. Therefore, make sure there is enough space in <filename>/var/crash</filename> to hold the dump. Alternatively, run <citerefentry><refentrytitle>savecore</refentrytitle><manvolnum>8</manvolnum></citerefentry> manually and have it recover the crash dump to another directory with more room. It is possible to limit the size of the crash dump by using <literal>options MAXMEM=N</literal> where <replaceable>N</replaceable> is the size of kernel's memory usage in KBs. For example, for 1 GB of RAM, limit the kernel's memory usage to 128 MB, so that the crash dump size will be 128 MB instead of 1 GB.
Once the crash dump has been recovered , get a stack trace as follows:
<prompt>%</prompt> <userinput>kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0</userinput>
<prompt>(kgdb)</prompt> <userinput>backtrace</userinput>
Note that there may be several screens worth of information. Ideally, use <citerefentry><refentrytitle>script</refentrytitle><manvolnum>1</manvolnum></citerefentry> to capture all of them. Using the unstripped kernel image with all the debug symbols should show the exact line of kernel source code where the panic occurred. The stack trace is usually read from the bottom up to trace the exact sequence of events that lead to the crash. <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> can also be used to print out the contents of various variables or structures to examine the system state at the time of the crash.
If a second computer is available, <citerefentry><refentrytitle>kgdb</refentrytitle><manvolnum>1</manvolnum></citerefentry> can be configured to do remote debugging, including setting breakpoints and single-stepping through the kernel code.
If <literal>DDB</literal> is enabled and the kernel drops into the debugger, a panic and a crash dump can be forced by typing <literal>panic</literal> at the <literal>ddb</literal> prompt. It may stop in the debugger again during the panic phase. If it does, type <literal>continue</literal> and it will finish the crash dump.
Why has <function>dlsym()</function> stopped working for ELF executables?
The ELF toolchain does not, by default, make the symbols defined in an executable visible to the dynamic linker. Consequently <function>dlsym()</function> searches on handles obtained from calls to <function>dlopen(NULL, flags)</function> will fail to find such symbols.
To search, using <function>dlsym()</function>, for symbols present in the main executable of a process, link the executable using the <option>--export-dynamic</option> option to the ELF linker (<citerefentry><refentrytitle>ld</refentrytitle><manvolnum>1</manvolnum></citerefentry>).
How can I increase or reduce the kernel address space on i386?
By default, the kernel address space is 1 GB (2 GB for PAE) for i386. When running a network-intensive server or using ZFS, this will probably not be enough.
Add the following line to the kernel configuration file to increase available space and rebuild the kernel:
options KVA_PAGES=<replaceable>N</replaceable>
To find the correct value of <replaceable>N</replaceable>, divide the desired address space size (in megabytes) by four. (For example, it is <literal>512</literal> for 2 GB.)
This innocent little Frequently Asked Questions document has been written, rewritten, edited, folded, spindled, mutilated, eviscerated, contemplated, discombobulated, cogitated, regurgitated, rebuilt, castigated, and reinvigorated over the last decade, by a cast of hundreds if not thousands. Repeatedly.
We wish to thank every one of the people responsible, and we encourage you to <link xlink:href="@@URL_RELPREFIX@@/doc/en_US.ISO8859-1/articles/contributing/article.html">join them</link> in making this <acronym>FAQ</acronym> even better.


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: answer/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/faq.pot, string 1007