Hi , all dear friends
My OpenBSD crashed and rebooted agian after panic: trap type 6, code=0,
pc=d056c5dd.
I am trying to find where is the origination of this problem but I could not
find anything.
I used from gdb and I run "file /var/crash/bsd.0"  and " target kvm
/var/crash/bsd.0.core" commands.
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/
total 6816168
-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,
pc=d056c5dd
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
hw.physmem=3479662592
# swapctl -l -k
Device      1K-blocks     Used    Avail Capacity  Priority
swap_device   4192968        0  4192968     0%    0
# sysctl vm.swapencrypt.enable
vm.swapencrypt.enable=0


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

[ message continues ]

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.

AND/OR ...

[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.


[ message continues ]