Hi , all dear friends
My OpenBSD crashed and rebooted agian after panic: trap type 6, code=0,
I am trying to find where is the origination of this problem but I could not
I used from gdb and I run "file /var/crash/bsd.0" and " target kvm
then I run "where" but gdb told "No stack."
In addition I tried to help of dmsg and iostat but it seems there is no
information that help me.
output both of them were empty.
Here is the ouput of some commands that may help us
# ls -lh /var/crash/
-rw------- 1 root wheel 2B Nov 30 01:47 bounds
-rw------- 1 root wheel 8.5M Nov 30 01:53 bsd.0
-rw------- 1 root wheel 3.2G Nov 30 01:53 bsd.0.core
-rw-r--r-- 1 root wheel 5B Aug 16 19:16 minfree
## grep savecore /var/log/messages
Nov 27 18:35:40 BSD savecore: no core dump
Nov 30 01:47:00 BSD savecore: reboot after panic: trap type 6, code=0,
Nov 30 01:47:00 BSD savecore: /var/crash/bounds: No such file or directory
Nov 30 01:47:00 BSD savecore: writing core to /var/crash/bsd.0.core
Nov 30 01:53:04 BSD savecore: writing kernel to /var/crash/bsd.0
# sysctl hw.physmem
# swapctl -l -k
Device 1K-blocks Used Avail Capacity Priority
swap_device 4192968 0 4192968 0% 0
# sysctl vm.swapencrypt.enable
Also I am using of symon and rrdgraph that show usage of cpu , memory and
hard disk is very normal before crash.
can you help me why my core file seems empty?
How can get useful information from core file and find problem?
Gula_Gula =;=; BNF
Can't help with core files, but would suggest you reduce the problem to the
smallest set of "things" that trigger it.
Try different machine, different RAM, different NICs. If you've got a similar
machine, move the HD into that machine and see if you get the same behaviour.
Try starting with base install, and slowly moving up to the level you need -
perhaps on the way up you will find the trigger.
[You might already be achieving this with symon, etc.]
Write a script that logs to a file (might need to flush after the write) every
5 minutes or whatever; maybe write the output of ps (or whatever interests
you) to the file.
See what time(s) the crash happens and drill-in on that time with more
diagnostics. If the crash is always happening at 8.05 p.m., you can start to
investigate more what happens at that time of day.