daveh@cbmvax.commodore.com (Dave Haynie) (02/01/91)
In article <1991Jan31.035105.14277@usenet.ins.cwru.edu> nnn@po.CWRU.Edu (Nik N. Nik Mahdi) writes: > You know, I have been wondering about my Amiga, which sometimes >gurus when I run certain softwares. I wonder what's wrong with >it. Is it the computer system, or is it the software that causes >it to Guru? Unless you have hardware problems, these crashes are caused by bugs in your application programs. >Why doesn't it happen to other computer systems, like IBM or Macintosh >(sometimes I got "System Error" on Mac, is it the same as the "Guru >Meditation" on Amiga?). Well, it does happen on other system. Only, many other systems aren't robust enough to realize that a program has done something wrong, so they either keep going, or simply freeze up. From my experience, the "System Error" on the Mac is more like the "System Error -- Task Held" response from the Amiga; the OS has found a program doing something wrong, but it wasn't a catastrophe. When a severe bug hits on the Mac, it usually just freezes up. On the Amiga, a severe bug usually causes a GURU (or SYSTEM ERROR in 2.0) type error message. >Thus, can someone explain this to me. Why the software developer >(if it is their fault!) didn't do anything to avoid this? Generally the software developer never found the problem. Occasionally, such bugs are dependent on aspects of different systems -- what kind of CPU, memory, etc. you're using. Of course, at other times, you find that some developers are simply too lazy or rush to market too fast to do proper testing. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "What works for me might work for you" -Jimmy Buffett
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (02/01/91)
daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1991Jan31.035105.14277@usenet.ins.cwru.edu> nnn@po.CWRU.Edu (Nik N. Nik Mahdi) writes: > >> You know, I have been wondering about my Amiga, which sometimes >>gurus when I run certain softwares. I wonder what's wrong with >>it. Is it the computer system, or is it the software that causes >>it to Guru? > >Unless you have hardware problems, these crashes are caused by bugs in your >application programs. It's funny that you mention hardware problems. One of my Amiga's (my first. the 500) has had a weird problem since i bought it. every so often the screen will get random grabage thrown into it. this will sometimes be re-coverable but often times not. it is almost as if the blitter is going haywire. throwing data every which way. this usually happens with jr-comm (i know.. but it never happens on my 2500) but i have had it happen without even running jr-comm. I also have a problem with the red raster draining ever time the disk accesses. by draining i mean the red color noticably dims. any suggestions? > >>Why doesn't it happen to other computer systems, like IBM or Macintosh >>(sometimes I got "System Error" on Mac, is it the same as the "Guru >>Meditation" on Amiga?). > >Well, it does happen on other system. Only, many other systems aren't robust >enough to realize that a program has done something wrong, so they either >keep going, or simply freeze up. From my experience, the "System Error" on >the Mac is more like the "System Error -- Task Held" response from the Amiga; >the OS has found a program doing something wrong, but it wasn't a catastrophe. >When a severe bug hits on the Mac, it usually just freezes up. On the Amiga, >a severe bug usually causes a GURU (or SYSTEM ERROR in 2.0) type error message. This reminds me. a friend tells me that the machine recovers much more often from crashes under 2.0. what did you guys do to make this happen? > >>Thus, can someone explain this to me. Why the software developer >>(if it is their fault!) didn't do anything to avoid this? > >Generally the software developer never found the problem. Occasionally, such >bugs are dependent on aspects of different systems -- what kind of CPU, memory, >etc. you're using. Of course, at other times, you find that some developers >are simply too lazy or rush to market too fast to do proper testing. All too true.... > > > >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "What works for me might work for you" -Jimmy Buffett UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
dave@cs.arizona.edu (Dave P. Schaumann) (02/02/91)
In article <3961@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >It's funny that you mention hardware problems. One of my Amiga's (my first. >the 500) has had a weird problem since i bought it. every so often the screen >will get random grabage thrown into it. this will sometimes be re-coverable >but often times not. it is almost as if the blitter is going haywire. >throwing data every which way. this usually happens with jr-comm (i know.. >but it never happens on my 2500) but i have had it happen without even running >jr-comm. I also have a problem with the red raster draining ever time the >disk accesses. by draining i mean the red color noticably dims. any >suggestions? Sounds a lot like a bad power supply. I had similar problems with my C64 a few years ago, and it turned out to be the power supply. If your still running with the original PS, I would say get a new one. Of course, that's probably sound advice for anyone running an A500 with any kind of peripherals at all, considering the grief I've seen attributed to flakey A500 PS's posted here. >UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks >ARPA: crash!orbit!pnet51!chucks@nosc.mil >INET: chucks@pnet51.orb.mn.org Dave Schaumann | And then -- what then? Then, future... dave@cs.arizona.edu | -Weather Report
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/05/91)
In article <3680.27ad65e7@miavx1.acs.muohio.edu> rlcollins@miavx1.acs.muohio.edu (Ryan 'Gozar' Collins) writes: In article <156@dogmelb.dog.oz.au>, david@dogmelb.dog.oz.au (David Le Blanc) writes: > It can be your fault for running a PD program in the background. > At a software house I worked at, PD programs were *BANNED* because > bugs introduced by them were considered harmful, and unneccesary. Are Programs so hard to write for the Amiga that every PD prg is bug ridden? I think it's just someone being overly paranoid. In my experience, PD software is no more likely to crash the system than commercial software. With commercial software, you have to convince them that their software is broken, and not something else in your environment. Then you have to get an udpate - which may or may not cost money. With PD software, there's a high probability that you've got the sources, and can try to fix it yourself. You pays your money (or not, in some cases) and takes your chances. Case in point - when I started running some of the 'protection' software now available, exactly one PD program I regularly used caused problems (lots of games did, but who cares - they're just games). Three commercial programs caused problems. One of the last three has as yet to be fixed, and will crash the system if I'm not carefull. Places have different bans on what software you can have locally for different reasons. Some places ban any commercial software except those purchased by the company, for legal reasons. Others ban any free-redistributable software, because such things are obtained through channels that are suspectable to virii and similar creations of the immature. The virus problem may be the problem referred to above. But commercial software isn't immune to this problem, especially when so many vendors have shrink-wrap machines, and no qualms about re-wrapping software that a user has returned. I take the same anti-virus precautions with both commercial and PD software. Never boot it; always try it on a system without anything vital mounted first; check the mounted file systems for changes afterwards. The only exception are disks that come from CBM direct. <mike -- That time we slept together Mike Meyer That's as far as it went mwm@pa.dec.com Yet though we're not quite lovers decwrl!mwm You're more than a friend
rick@tmiuv0.uucp (02/06/91)
In article <1991Feb4.204749.12882@mintaka.lcs.mit.edu>, rjc@geech.ai.mit.edu (Ray Cromwell) writes: [some stuff deleted] > VLT/Handshake/Jrcomm:All fine term prgs which IMHO beat commercial crap like > Online, Access, Diga, etc. ^^^^^^ Since when is Access! commercial, eh? It's shareware. And, IMHO, you shouldn't use generalized phrases like "commercial crap", since not all commercial software is crap. In fact, much of it is quite good. However, some programs have shortcomings. OnLine! is fine for what it does. VLT and JRComm both have problems, too. The dangerous thing about general statements is that they often cause one to eat one's own words. And that's enough said on that subject. (getting off soapbox now) .--------------------------------------------------------------------------. |[- O] Rick Stevens | | ? EMail: uunet!zardoz!tmiuv0!rick -or- uunet!zardoz!xyclone!sysop | | V CIS: 75006,1355 (75006.1355@compuserve.com from Internet) | | | | "Everybody has to deviate from the norm...." | | - Rush | | "I guess that makes me a deviant!" | | - Me! | '--------------------------------------------------------------------------`
nikolai@guru.pub.uu.oz.au (nikolai kingsley) (02/07/91)
> it to Guru? Why doesn't it happen to other computer systems, like > IBM or Macintosh (sometimes I got "System Error" on Mac, is it > the same as the "Guru Meditation" on Amiga?). > Thus, can someone explain this to me. Why the software developer > (if it is their fault!) didn't do anything to avoid this? > Thanks in advance. > > NIK well, when an IBM goes, the system is so dumb that it can't tell you. you are lucky if you can even tell that it has gone, it might just be slow! and yes, the AMiga Gurus are similar to the macintosh `bombs' and the Atari Chrrybombs... up to about 00000012, at least. it is not your fault. if some idiot tells the 68000 to access an instruction at an odd memory location ( a no-no, cos they are all supposed to be on word boundaries!) it go GURU GURU. if some moron say to it `here, divide this number by zero, it also Goes To India to see the Guru. you see, the 68000 is a nice chip, but it can't do the impossible... like figure out why people like Word Perfect. nikolai alekseivitch Kingsley patron saint of the caps lock key
ford@amix.commodore.com (Mike "Ford" Ditto) (02/08/91)
I hear that this comp.sys.amiga.tech newsgroup no longer exists. Let's take this to .programmer. bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes: > The reason that Unix almost never crashes is usually because of the memory > protection hardware [ ... ] This is true, but primarily in an indirect way, I think. (explained below) > In the Amiga a program can rampantly wade through > memory trashing areas. In Unix you'll get a segmentation violation and thus > avoid crashing any of the other processes and also make it easy to clean up > the dead process. If the only thing that kept Unix from crashing was the run-time memory protection, under Unix you'd see a "Segmentation violation - core dumped" many times more often than a typical Amiga crashes under similar usage. Yet, on most Unix systems, you'll hardly ever see a production program dump core. This is because the programs on Unix systems actually have fewer bugs. Now before you get upset and think I'm saying that Amiga programmers aren't as good as Unix programmers, let me explain. The "crashability" difference isn't due to the memory protection in the end-user execution environment as much as it's due to the programmer's testing environment. Unix is very good at detecting abnormal program behavior, even in ways that would be completely harmless if left alone. Consider a program which, at some point in its execution, writes a zero byte to a random address. Under Unix (on a 68030, say), you have a 4 gigabyte address space, with maybe 100K of it actually used by the program. This gives about a 1 in 40,000 chance of this bug going undecteded even if it is tested only once. But when running the same program under AmigaDOS on a similar system, there might be only a megabyte of memory that's actually in use by the system. Of this memory, only a small portion is going to be used in a way which will change the behavior of some program or the OS, and of that, only a portion will do so in a way that is either detected or causes a crash. Maybe only a 1 in 1,000 chance of the bug *being noticed* each time the program is run. Assuming that the developer tests the program one thousand times, the bug will only be seen about once, and will not show up again when specifically looked for. But when 2,000 users are using this program, there could easily be several bug reports a day. This example is a bit contrived (especially the bit about the bad address being "random"), but if a contrived example shows Unix being 40 million times more likely to detect a bug during development, you can bet that it's at least a few thousand times better. Therefore, I think that having a protected-memory environment during development and testing, even without full resource tracking and process separation, can recover much this reliability difference between AmigaDOS and Unix. But only to the extent that developers use it. > I have heard > of a program called Enforcer which uses the MMU on a 68020 or 68030 to provide > a more protected environment. Yes, I think Enforcer is probably the best way to get the benefit I describe above at this time. ... although I'm still hoping for future versions of AmigaDOS that take this even further. Personally, I'd build Enforcer into the OS just for starters. -=] Ford [=- "But everybody wants a rock (In Real Life: Mike Ditto) to wind a piece of string around." ford@amix.commodore.com - They Might be Giants, uunet!cbmvax!ditto "We want a rock" ford@kenobi.commodore.com
jesup@cbmvax.commodore.com (Randell Jesup) (02/09/91)
In article <1010@amix.commodore.com> ford@amix.commodore.com (Mike "Ford" Ditto) writes: >If the only thing that kept Unix from crashing was the run-time memory >protection, under Unix you'd see a "Segmentation violation - core >dumped" many times more often than a typical Amiga crashes under >similar usage. Yet, on most Unix systems, you'll hardly ever see a >production program dump core. This is because the programs on Unix >systems actually have fewer bugs. Well, I've seen a LOT of unix programs that make silly assumptions that happen to work ok on the system it was written on: for example the infamous NULL ptr access on BSD Vaxen - this happily returned 0's. On other Unix machines it causes segmentation faults. So Unix programmers aren't immune from these sorts of problems. Other problems that Unix programs are more likely to have are not checking memory allocations (they CAN fail under unix, there is a fixed amount of swap - even GCC doesn't check it's allocations), not testing error paths, making assumptions about the range of virtual addresses assigned to programs (GNU Emacs does this - it uses the high bits of pointers for tags), etc, etc. I'm not saying there aren't ways to avoid these problems, or that most unix programs have them, but far more have them than should (try compiling stuff from the sources groups and you'll hit all of these). >The "crashability" difference isn't due to the memory protection in >the end-user execution environment as much as it's due to the >programmer's testing environment. Unix is very good at detecting >abnormal program behavior, even in ways that would be completely >harmless if left alone. Absolutely. Getting this is one reason we wrote Enforcer for amigados. We also have something not yet released called angel that catches freelist reads/writes as well, though it REALLY drags your system down. AmigaDos is not likely to get process protection anytime soon; the basic design clashes with per-process protection, and it would be a compatibility nightmare. >Therefore, I think that having a protected-memory environment during >development and testing, even without full resource tracking and >process separation, can recover much this reliability difference >between AmigaDOS and Unix. But only to the extent that developers use >it. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)