Hi again, I installed gdb6 from ports, which works. It just confirms the addr2line result: (kgdb) l *0xc053932b 0xc053932b is in witness_checkorder (/usr/src/sys/kern/subr_witness.c:898). Brian Fundakowski Feldman wrote on Tue, Jun 29, 2004 at 02:49:46PM -0400: [..] > > (What hurts most, is, that in one occasion I had a ddb prompt > > and could call doadump() successfully. But after reboot, damn > > /var was full, so savecore could not write it to disk, argl!). > > You can make /var/crash a symlink to a directory with more space. Yes, I usually have enough space there. It was an ill coincidence. :-/ Don: Thanks for the hint to run savecore later on. I should have guessed as long as there is not much going on and swap did not need to used yet, I would have gotten a good core. Unfortunately it is to late for now. I'll keep it in mind, though. John: Ok, mutex/witness confusion is maybe going on. How would you suggest to proceed. I am a little reluctant to boot the machine to multi-user and wait for the next crash (which most of the time does not produce a dump or ddb prompt), since I would have to hit the reset button and right now, I'm at home now and have only remote access. How about the first stack trace (from ddb) that was included in the PR. Although the crashdump was wasted, the ddb trace could give some additional hints maybe? It also shows witness_checkorder(), but it also shows the other stack frames and as it seems the passed values. I can do some examination with these info on the system with gdb, but I could use a hint for what to look out for. Thanks, Daniel -- IRCnet: Mr-Spock - Eddie would go! - Daniel Lang * dl_at_leo.org * +49 89 289 18532 * http://www.leo.org/~dl/Received on Tue Jun 29 2004 - 17:31:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:59 UTC