Date: Fri, 16 Mar 2001 01:53:19 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Christian Weisgerber <naddy@mips.inka.de> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: bin/25361: dump(8) command segfaults Message-ID: <Pine.BSF.4.21.0103160147240.75575-100000@beppo.feral.com> In-Reply-To: <Pine.BSF.4.21.0103110955030.13644-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I did some more looking into this today- also without much success. This seems to be all tied up in a tangle of how the dump slave chilren signal each other and longjmp out of signal handlers. It seems that the last slave gets a SIGSEGV at the end of all of the reads. Attempts to fool around with the signal handler to try and actually find out where it's getting a fault change the behavious such that *nothing* runs. Argh. Attempts to attack this from the kernel side make me feel like an idiot. I eliminated any floating point or unaligned handling SIGSEGVs, and when I enabled the page fault printing for the SIGSEGV case, it reports the kernel function CURSIG as the offending PC for the trap. I'm *really* rusty at this end of the kernel- but it strikes me that the only way this could happen is if there is trouble pushing signal stuff onto the user process stack- but I don't believe that the user process stack usage is all that heavy. (I'm sending these notes to latch up state in the PR should somebody else want to take this further) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0103160147240.75575-100000>