Date: Sun, 27 Jan 2002 00:37:09 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: Martin Blapp <mb@imp.ch> Cc: Greg Lehey <grog@FreeBSD.org>, freebsd-stable@FreeBSD.org Subject: Re: double fault with vinum and 4.5 RC3 Message-ID: <20020126233709.GA459@crow.dom2ip.de> In-Reply-To: <20020125111624.S47234-100000@levais.imp.ch> References: <20020125131225.E4778@wantadilla.lemis.com> <20020125111624.S47234-100000@levais.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2002/01/25 at 11:38:31 +0100, Martin Blapp wrote: > vinum create /root/configfile twice ! makes STABLE 4.5RC3 crashing with a double > fault. I guess we should fix that. I'm makeing now a debug kernel. I've had a quick look at Martin's crash dump; the double fault is caused by a longjmp() that restores an invalid %esp. By accessing the stack that is to be restored by longjmp before actually setting %esp, I was able to get a usable trace (showing the vinum-relevant parts only): longjmp(c034a120,0,0,c1c31af4,3) at longjmp+0x7 throw_rude_remark(0,c02dbfc0,c1c41406,c1c31b84,c1c31af4) at throw_rude_remark+0x11a config_drive(0,0,c1c5c900,cfb99d64,c018d3c1) at config_drive+0x1ef parse_config(c1c41400,c0310d54,0,0,cfb99d8c) at parse_config+0x72 parse_user_config(c1c41400,c0310d54,c02dd0a0,cd4398a0,cfb99d78) at parse_user_config+0x19 vinumioctl(c1c5c900,c4004640,c1c41400,3,cd4398a0) at vinumioctl+0x2fe Apparently, this process slept in disk I/O initiated by vinum_read_label(); meanwhile, the vinum process forked in start_daemon() was scheduled and performed an ioctl() to find out whether the daemon was running. In this case, it was, so it exited. After some time, the other process is woken up because the I/O finished. vinum_read_label() returned DL_WRONG_DRIVE, so eventually throw_rude_remark() was called, which tried to longjmp() back to vinumioctl(). However, because vinumioctl() was called by another process in between, command_fail had been overwritten (it is a global variable). The stack referenced in that jmpbuf was unmapped when that process exited, so the result was a double fault. Greg, Martin should the crash dump I'm talking about available if you would like to take a look (the kernel in question has longjmp debugging code and a few printf()s added). - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020126233709.GA459>