home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / programm / 16079 < prev    next >
Encoding:
Text File  |  1992-11-19  |  4.4 KB  |  135 lines
  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: sparky!uunet!mcsun!sun4nl!oce.nl!mool
  3. From: mool@oce.nl (Bram Moolenaar)
  4. Subject: Amiga locks up; bug in DOS 2.0 filesystem?
  5. Message-ID: <1992Nov19.133453.26971@oce.nl>
  6. Summary: The Amiga locks up if a certain sequence of file I/O commands is used.
  7. Originator: mool@oce-rd2
  8. Keywords: bug, filesystem, lockup
  9. Sender: news@oce.nl (USENET News System)
  10. Organization: OCE Nederland B.V.
  11. Date: Thu, 19 Nov 92 13:34:53 GMT
  12. Lines: 121
  13.  
  14.  
  15. Short description of the problem: The Amiga locks up if a certain sequence of 
  16. file I/O commands is used.
  17.  
  18. Several people experienced the problem with my text editor "Vim" (Vi 
  19. IMitation). In Vim a script file is used to remember the typed commands. If 
  20. the edited file has been written to disk, the script file is deleted and a 
  21. new one is opened for any new commands. A few bytes are written into the new 
  22. file. The sequence "close, delete, open, write" seems to cause the lockup. I 
  23. wrote a small program that can reproduce the bug. It is at the end of this 
  24. message. As you can see it uses only "normal" file I/O functions.
  25.  
  26. The problem is that the machine locks up: It seems to be so busy with 
  27. something that it does not react to commands anymore. The mouse pointer may 
  28. move, but slowly.
  29.  
  30. Does anybody know what causes this problem? Is this a bug in the DOS
  31. filesystem? And more important: How can I avoid it? I discovered that
  32. timing is important. Inserting some kind of delay makes the bug appear
  33. less often. How can I make sure it is 100% safe (on all Amigas under all
  34. circumstances)?
  35.  
  36. Any help is welcomed!
  37.  
  38.  
  39. /*
  40.  * test for lockup bug
  41.  *
  42.  * WARNING: this program locks up the Amiga, use at your own risk!
  43.  *
  44.  * The lockup does not happen always. Until now I discovered:
  45.  * - It depends on how full the partition is (easy to lockup on an empty partition).
  46.  * - Adding printf's changes the chance for a lockup (timing seems to be important).
  47.  *   The more characters are printed, the smaller the lockup chance. Outputting
  48.  *   a newline seems to remove the lockup on my machine.
  49.  * - Sometimes you may have to run this program several times.
  50.  * - Using 32- or 16-bit ints does not change the problem.
  51.  * - It does not happen in RAM:.
  52.  * - It probably only happens under DOS 2.04 or higher.
  53.  * - Lockup happens with both Manx 5.2 and with SAS 6.0.
  54.  * - Lockup happens with different brands of harddisk controllers, but so far
  55.  *   only with DMA types (timing).
  56.  * - Using fopen/fwrite/fclose or open/write/close gives the same problem.
  57.  * - Removing the line "if (Write(fd, "this is a test", 14L) != 14)"
  58.  *   seems to make the bug disappear. This is no solution, I need to write
  59.  *   to that file.
  60.  */
  61.  
  62. #include <stdio.h>
  63. #include <stdlib.h>
  64. #include <fcntl.h>
  65. #include <string.h>
  66. #include <clib/dos_protos.h>
  67.  
  68. /*
  69.  * In some cases the lockup only happens without the debug messages.
  70.  */
  71. #if 1
  72. # define debug(x)        fprintf(stderr, (x)); fflush(stderr);
  73. #else
  74. # define debug(x)
  75. #endif
  76.  
  77. main(argc, argv)
  78.     int argc;
  79.     char **argv;
  80. {
  81.     BPTR    fd;
  82.     int    i;
  83.     char    vimname[100];
  84.     char    bakname[100];
  85.  
  86.     if (argc != 2)
  87.     {
  88.         fprintf(stderr, "Usage: test filename\n");
  89.         exit(10);
  90.     }
  91.     if (strlen(argv[1]) > 90)
  92.     {
  93.         fprintf(stderr, "argument too long\n");
  94.         exit(10);
  95.     }
  96.     strcpy(vimname, argv[1]);
  97.     strcat(vimname, ".vim");
  98.     strcpy(bakname, argv[1]);
  99.     strcat(bakname, ".bak");
  100.  
  101.     for (i = 0; i < 100; ++i)
  102.     {
  103.         fprintf(stderr, "%d ", i);
  104.         fflush(stderr);
  105.  
  106.         fd = Open((UBYTE *)vimname, (long)MODE_NEWFILE);
  107.         debug("A ");
  108.         if (fd < 0)
  109.         {
  110.             fprintf(stderr, "Cannot open for writing: %s\n", vimname);
  111.             exit(10);
  112.         }
  113.         debug("B ");
  114.     /* the lockup sometimes happens HERE (B is printed, C is not) */
  115.         if (Write(fd, "this is a test", 14L) != 14)
  116.             fprintf(stderr, "Cannot write to %s\n", vimname);
  117.         debug("C ");
  118.  
  119.     /* the lockup sometimes happens HERE (C is printed, D is not) */
  120.         Close(fd);
  121.         debug("D ");
  122.         if (DeleteFile((UBYTE *)vimname) == 0)
  123.             fprintf(stderr, "DeleteFile(%s) failed\n", vimname);
  124.         debug("; ");
  125.     }
  126.     return 0;
  127. }
  128.  
  129. ===============================================================================
  130. Bram Moolenaar                             | DISCLAIMER:  This  note  does  not
  131. Oce Nederland B.V., Research & Development | necessarily represent the position
  132. p.o. box 101, 5900 MA  Venlo               | of  Oce-Nederland  B.V.  Therefore
  133. The Netherlands        phone +31 77 594077 | no liability or responsibility for
  134. UUCP: mool@oce.nl        fax +31 77 595450 | whatever will be accepted.
  135.