Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!ux1.cso.uiuc.edu!uwm.edu!ogicse!netnews.nwnet.net!ns1.nodak.edu!plains.NoDak.edu!tinguely From: tinguely@plains.NoDak.edu (Mark Tinguely) Newsgroups: comp.os.386bsd.bugs Subject: Re: ioctls and core dumps Message-ID: <C91nEG.LnL@ns1.nodak.edu> Date: 22 Jun 93 22:20:40 GMT Article-I.D.: ns1.C91nEG.LnL References: <1993Jun22.173715.6498@fac.com> Sender: usenet@ns1.nodak.edu (Usenet login) Organization: North Dakota State University Lines: 26 Nntp-Posting-Host: plains.nodak.edu In article <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? I found this a while ago in a small program using kvm. I used a global variable "free". I could run the program once fine, but next time I run the program it would core. I could copy the file but each copy could successfully run once. I suspect that the program was not writing to the global variable "free", but to the function "free()". this change is being written back to the executable (look at the modification date on your executable to prove that). In my case there seems to be two error, first the compiler is using the wrong address of "free", and secondly these changes should not be made back to the executable, but in a backstore copy. I never had the time to fix these problems (I took the hack approach of changing the variable name to mfree). --mark.