home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9821 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  3.1 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!rutgers!micro-heart-of-gold.mit.edu!uw-beaver!cornell!batcomputer!munnari.oz.au!cs.mu.OZ.AU!danielce
  2. From: danielce@mullian.ee.mu.OZ.AU (Daniel AMP Carosone)
  3. Newsgroups: comp.os.linux
  4. Subject: install/strip corrupts filesystem ?
  5. Message-ID: <danielce.715575697@munagin>
  6. Date: 4 Sep 92 03:01:37 GMT
  7. Sender: news@cs.mu.OZ.AU
  8. Organization: Computer Science, University of Melbourne, Australia
  9. Lines: 61
  10.  
  11. I would have put this down to random wierdness, but after discussions
  12. on #linux (IRC) it seems I'm not the only one experiencing this.
  13.  
  14.  
  15. A couple of days ago, I recompiled gdb 4.6 from scratch. When it was
  16. done, make install used /usr/bin/install (which I assume came from the
  17. binutils package from gcc 2.2.2d) to copy the executable to
  18. /usr/local/bin/gdb. I mv'ed it to /usr/bin, and stripped it.
  19.  
  20. Gdb seemed to work fine, at least for the minimal use I gave it over
  21. the last day or so.
  22.  
  23. The filesystem saw some more use, a few more files written, deleted, etc.
  24.  
  25. Next reboot, fsck -a /dev/hda2 (the /usr partition) spewed out
  26. hundreds of lines like:
  27.  
  28.   Block has been used before. Now in file `/bin/gdb'
  29.  
  30. followed by a largish number of similar lines for other files in the
  31. filesystem.
  32.  
  33. Repeated applications of `fsck -a /dev/hda2' reported `File system has
  34. been changed' but didn't seem to clear up the problem.
  35.  
  36. It looked to me like two files seemed to be claiming to own the same
  37. block. A very quick check showed that gdb still loaded and read the
  38. symbols from a file (ie, wasn't obviously corrupted, but with a 770k
  39. static demand-paged executable, you might not see corruption for a
  40. while) Picking some of the other files in the list at random, they
  41. seemed okay also.
  42.  
  43. This is a fairly new minix filesystem, made only a couple of weeks ago
  44. when I reinstalled on a new machine.
  45.  
  46.  
  47. Anyway, I flicked over to #linux and asked if anyone else had seen
  48. this sort of behaviour from the filesystem/fsck before. Sure enough,
  49. someone had (Thanks, Matt) and usually after having run `install'
  50. (possibly with the -s flag to invoke strip). After some discussion, I
  51. deleted /usr/bin/gdb, and was greeted with a bunch of kernel messages:
  52.  
  53.   free block (0302:nnnnn): bit already cleared
  54.  
  55. Another fsck -a complained about blocks owned by all the other files
  56. in the list being marked free, fixed that, and now the filesystem
  57. *seems* to be sane and consistent, again with fairly cursory checks.
  58.  
  59.  
  60. So: how does `strip' do it's stuff? I assume it's not directly
  61. manipulating the filesystem (ugh, only DOS would do that) but could
  62. something in the way it removes symbol information from a file
  63. exercise a bug in the filesystem code? Perhaps leaving the `holes'
  64. marked free (to be claimed by other files), yet owned by gdb? Some of
  65. the files in the list were *older* than the gdb binary, so this isn't
  66. a particularly satisfactory hypothesis. Any better ideas?
  67.  
  68. _______________________________________________________________________________
  69. Daniel AMP Carosone.      email: danielce@ee.mu.oz.au     snail: 37 Wandin Road
  70. Computer/Software Eng,      IRC: Waftam                         Camberwell 3124
  71. University of Melbourne.    Vox: +61 3 882 8910                       Australia
  72.