Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!mcsun!sun4nl!eur.nl!pk From: pk@cs.few.eur.nl (Paul Kranenburg) Subject: Re: ioctls and core dumps Message-ID: <1993Jun23.111406.7736@cs.few.eur.nl> Sender: news@cs.few.eur.nl Reply-To: pk@cs.few.eur.nl Organization: Erasmus University Rotterdam References: <1993Jun22.173715.6498@fac.com> Date: Wed, 23 Jun 1993 11:14:06 GMT Lines: 32 In <1993Jun22.173715.6498@fac.com> mooreb@fac.com (Brian Moore) writes: >The $42 question is... Why did the program continue to dump core? >The only thing I could think of is that perhaps the ioctl processing >in the c library or the kernel mucks with the data area (mprotect, >clears it, or something else), which would really be the start of the >program because of the 0. As such, it might cause problems for future >runs of that program if it is kept in swap or cache or whatever. But >why would the program continue to core dump across reboots? Most likely your executable's text segment is being written to as a result of passing bogus pointers to the kernel. From an earlier article: > [...] > issuing a "read(fd, 0, 4)" which unfortunately did not lead to an immediate > SIGSEGV, because the hardware does not automatically detect a protection > violation while in kernel mode. However, it does mark the page (which is > mapped to the running executable's text segment) as modified. Upon process > termination the allocated VM object is entered in the object cache. When > the time comes to flush the modified page (say by the pageout daemon or > induced by a `rm a.out') the kernel wants to write the bogus page onto its > backing store. > [...] BTW. If you execute the program from an NFS filesystem your machine would probably have panic'ed (due to another bug in the swap_pager <-> vnode interface). Try out patch 00147 which is designed to catch this class of bugs. -pk