grunau_b@husc4.harvard.edu (justin grunau) (12/07/86)
I would like to report a few bugs in GEM that I have never seen mentioned on the net, and see whether anybody else has come across similar behaviour, and whether anybody can make anything of this ... Basically, I suspect the bugs have something to do with memory getting used up and not released when various programs terminate. The problem is not, however, visible to any of the programs I currently have to check memory size. That is, even when these bugs are occuring, everything still tells me I have as much memory as I had when I started (about 800K -- I am using a 1040). The most common bug by far occurs when I come out of some program in my utils or games directory (usually either uniterm v1.6c or megaroids), and then click on the "close" gadget to move one directory up. Either nothing happens, or the close button inverts (turns black) AS THOUGH IT WERE AN ICON I JUST SELECTED. Clicking on the gadget again just re-inverts (turns white) the close gadget, just like an icon. Eventually, if I click on it enough times, the window closes, and everything is back to normal. While this weirdness is occuring, I can usually click on other icons/names in the window, and even launch programs, etc. The bug is impossible to reproduce -- it just comes and goes. An even WEIRDER bug is when GEM apparently gets totally confused and not only does the close gadget act like an icon, but in fact neither it nor any icon will register having been selected until AFTER the mouse has moved. That is, you move on top of a file, click on it; nothing happens. Move the mouse a tiny bit; all of a sudden, the file you clicked on turns black. Click on it again, and once again it takes a movement of the mouse to turn it white again. The WEIRDEST bug is when everything in a GEM directory window starts acting like one of the pop-down menu items: that is, everything you move over turns black while you are on top of it, and white once you are off it: it does not take a click to make something look selected. It takes only a few minutes of this behaviour to cause the system to freeze up completely. One last bug that I have started seeing with greater frequency lately. I will be happily doing stuff, and then suddenly anything I try to do makes the system tell me there is no memory to do it. Checking memory by the RAMCHK deskacc tells me I have 800K. Even some GEM operations give me this problem. For instance, if I try to look at the "Show Info" thing on one of my hard disk icons, it will work; but if I try to look at the info of my floppy disk icon, it says not enough memory for this application. Has anybody else ever seen these bugs? I used to have the TI desk accessory with the .RSC file, and since someone recently posted news that accessories with .RSC files cause problems, I have gotten rid of it in the hope that perhaps it was the cause; but it hasn't been long enough to tell. JJMG ...seismo!husc6!husc4!grunau (or grunau_b) or use ...decvax!ihnp4!husc6...
grunau_b@husc4.harvard.edu (justin grunau) (12/08/86)
Well, I can confirm that it was not the .RSC file of the TI desk accessory that was causing one of those bugs I mentioned in an earlier posting (the bug that causes a click on the "close" gadget of a GEM window to merely highlight the gadget as though it were selecting an icon instead of performing the close) -- I got it today, after only running one program (megaroids). Luckily, this particular bug doesn't cause the system to crash and tends to go away fairly quickly (after you have clicked on the darn gadget enough times) so I guess it's not particularly destructive, except I am getting the feeling that there are all sorts of potential memory problems floating around (probably unreleased mallocs and so on) which could cause serious problems ... it does give me a kind of feeling of impending doom whenever I use the system nowadays. JJMG
c160-bv@zooey.Berkeley.EDU (Warner Young) (12/08/86)
In article <839@husc6.UUCP> grunau_b@husc4.UUCP (justin grunau) writes: > >Well, I can confirm that it was not the .RSC file of the TI desk accessory > .... >highlight the gadget as though it were selecting an icon instead of performing >the close) -- I got it today, after only running one program (megaroids). I don't know about the TI accessory, since I haven't seen it, but I don't see why Megaroids would cause this problem. There does seem to be a bug with GEM that causes it to think that the left button is depressed, even after you let go. That might be your problem. It's happened to me before, and it usually only takes one click to remove the problem. >Luckily, this particular bug doesn't cause the system to crash and tends to >go away fairly quickly (after you have clicked on the darn gadget enough times) >so I guess it's not particularly destructive, except I am getting the feeling >that there are all sorts of potential memory problems floating around (probably >unreleased mallocs and so on) which could cause serious problems ... it does >give me a kind of feeling of impending doom whenever I use the system nowadays. I use my system fairly often, and I hardly ever have problems like these. Are you sure it isn't your computer itself? Warner Young - WHY "I am not affiliated with any money-making enterprise, though I wouldn't mind being so associated."
grunau_b@husc4.harvard.edu (justin grunau) (12/08/86)
Yes, well, I can't see why megaroids would cause the problems I have mentioned, either, which is why I made a point of saying that the only thing I had done before the error occured was to play megaroids -- indicating to me that the problem is something in GEM or the OS, and not in megaroids. BTW, if it is so that GEM sometimes has trouble detecting that the left button has been released, even so I really can't see why this would have any connection with the bug I have mentioned: the "close" gadget in a GEM window just hilights as though it was an icon being selected, and it does it immediately. Further- more, it unhilights immediately if you click on it a second time. And it does this immediately. None of these things seem to have anything to do with the left button being detected as being always down. The same thing goes with the other bug that makes everything in the GEM window act like one of the options of the pop-down menu (i.e. whenever you move the mouse over it -- without the button depressed, even), the icons/filenames become hilighted for as long as you are over them, just like the menu options. (the effect is just like running IBM's TopView, for those of you who might have seen that). If GEM thought my left button was depressed, then moving the mouse around would drag the first icon I moved over: not just hilight and dehilight them all to no other effect (except to crash the system after about a minute). Of course, the reason I reported these things is to find out whether anybody else has seen them, in the attempt to discover whether it could be a "problem with my computer" (though it is hard to see what it would be). JJMG .........seismo!husc6!husc4!grunau_b (or ..!grunau) or ...decvax!ihnp4!husc6! ...
rmaranta@watarts.UUCP (12/12/86)
In article <837@husc6.UUCP> grunau_b@husc4.UUCP (justin grunau) writes: > >Basically, I suspect the bugs have something to do with memory getting used >up and not released when various programs terminate.... It seems to me that the single most glaring bug in GEMDOS is with its memory allocation/deallocation. With all of the OS experience under DRI's collective belt, I don't see why this is. Just trying to use dynamically-allocated lists forces one to write a custom, array-based, pseudo-allocation scheme. Add to this the hard drive performance (or lack thereof), the file limits, the extraordinarily long pause after a program is loaded while GEMDOS does its relocating stuff, .... ARG! Please, Atari, don't leave us with a half-finished product! Please finish up what DRI started (and left half-done)! Jonathan Fischer