paolucci@snll-arpagw.UUCP (Sam Paolucci) (06/13/88)
I have a suggestion. Lots of people worry about the Amiga crashing when they are using it in a multitasking mode. We all know that by and large improperly written software (including COMMERCIAL) is responsible for this. The effect of improperly written software is multiplied in a multitasking environment. The result has been in giving the Amiga a reputation of crashing easily, even though the operating system is not responsible in most case. I don't know if this is doable, since I haven't given it a lot of thought, but what we need is a utility that sits in the background and points a finger (via a requester) at the software that was responsible for the crash. I would bet that a lot of COMMERCIAL software would get cleaned up really fast due to customer pressure, and poor public domain software would not get used. The point here is that if we know which software is bad we won't use it. What do you all think? -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
egranthm@jackson.UUCP (Ewan Grantham) (06/14/88)
In article <180@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > operating system is not responsible in most case. I don't know if > this is doable, since I haven't given it a lot of thought, but what we > need is a utility that sits in the background and points a finger (via > a requester) at the software that was responsible for the crash. I Sam, Isn't this basically what the GOMF utility is supposed to do? Granted it is no longer a PD product, but it still seems that's what you're looking for. At least that's the reason I ordered it last week. Will be happy to send you a review after I've had it awhile, if you're interested. > -+= SAM =+- > Ewan Grantham -- Ewan Grantham (601) 354-6454 ext.358 {pyramid or bellcore or tness..}!swbatl!jackson!egranthm I'm not responsible for my bosses, and vice-versa
paolucci@snll-arpagw.UUCP (Sam Paolucci) (06/16/88)
In article <4022@cbmvax.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) writes: >In article <180@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >>I have a suggestion.... [] ... I don't know if >>this is doable, since I haven't given it a lot of thought, but what we >>need is a utility that sits in the background and points a finger (via >>a requester) at the software that was responsible for the crash. I >>would bet that a lot of COMMERCIAL software would get cleaned up >>really fast due to customer pressure, and poor public domain software >>would not get used. The point here is that if we know which software >>is bad we won't use it. > >This is not possible. A badly written program can trash some other >program's memory. So some other program's task ends up with an address >error, etc. because its code or data was trashed. No way to tell which >task DID the trashing. > True. But in many cases the program may not trash other tasks and in this case you know who the culprit is. Furthermore, I am not suggesting that just because this happens once, that the particular task pointed to should be immediately blamed. However this makes the task suspicious, and if this task keeps being pointed at with a different mix of jobs, that there is a very strong indication that IT is responsible. Don't you agree? >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Carolyn Scheppner -- CATS >>Commodore Amiga Technical Support<< > UUCP ...{allegra,ihnp4,rutgers}!cbmvax!carolyn > PHONE 215-431-9180 >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
phil@titan.rice.edu (William LeFebvre) (06/16/88)
In article <180@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >I have a suggestion. Lots of people worry about the Amiga crashing >when they are using it in a multitasking mode. We all know that by >and large improperly written software (including COMMERCIAL) is >responsible for this. The effect of improperly written software is >multiplied in a multitasking environment. The result has been in >giving the Amiga a reputation of crashing easily, even though the >operating system is not responsible in most case. I mildly disagree...(oh boy, let's start another OS debate).... I think one of the duties of an operating system is to protect processess from one another. That's resource allocation and control. You are right in that if every program was completely correct then the system would never crash (independent of hardware failures). But when is the last time you saw a completely correct program that actually did something useful? ("hello world" isn't very useful.) They aren't very common, especially when the programmer has to be responsible for deallocation in addition to allocation. William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
joe@dayton.UUCP (Joseph P. Larson) (06/17/88)
paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: >.....I don't know if >this is doable, since I haven't given it a lot of thought, but what we >need is a utility that sits in the background and points a finger (via >a requester) at the software that was responsible for the crash. One problem is the following scenario: program A is happily purring along. program B comes along with an invalid pointer and stomps on program A's data or even code. program A causes a crash. Who's at fault? How is your little background program going to know that it was program B who caused the crash when it was program A that was running when the crash occured? Good luck. -J -- UUCP: rutgers!dayton!joe Dayton Hudson Department Store Company ATT : (612) 375-3537 Joe Larson/MIS 1060 (standard disclaimer...) 700 on the Mall Mpls, Mn. 55402
daveh@cbmvax.UUCP (Dave Haynie) (06/17/88)
in article <6530@cup.portal.com>, Doug_B_Erdely@cup.portal.com says: > XPortal-User-Id: 1.1001.2946 > Gomf 2.2 does almost this! It will tell you when something not nice is done > to the system! I use this program, and it makes it very easy to figure out > what program did the no no. Sometimes. But imagine this. Program A starts up and runs very nicely. Program B starts up and happens to write something through an uninitialized pointer that just happens to point to something that program A is using. At some point, program A gets back to this corrupt instruction or data, and vomits. Gomf 2.2 (haven't used it myself) may be extremely clever, and catch the program in it's death throes. But while it's catching the program that barfed, that's not the program that caused the barf. I do suspect, though, that such error trapping progams like Gomf would be useful to the developer working in a solid evironment with only the program under development capable of thrashing the system. > - Doug - -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
ewiles@netxcom.UUCP (Edwin Wiles) (06/17/88)
In <183@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > In <4022@cbmvax.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner CATS) writes: > > In <180@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > > >...a utility that sits in the background and points a finger (via > > >a requester) at the software that was responsible for the crash... > > > >...A badly written program can trash some other program's memory... > >...No way to tell which task DID the trashing... > >...I am not suggesting that just because this happens once, that the >particular task pointed to should be immediately blamed... The problem is that many users will simply blame it right away, and won't bother to check it out under different configurations. It's not technically impossible, but it *is* socially impossible. Too many users *would* immediately blame the one pointed at, without thinking about the fact that someone else is at fault. -- ...!hadron\ "Who?... Me?... WHAT opinions?!?" | Edwin Wiles ...!sundc\ Schedule: (n.) An ever changing | NetExpress Comm., Inc. ...!pyrdc\ nightmare. | 1953 Gallows Rd. Suite 300 ...!uunet!netxcom!ewiles | Vienna, VA 22180
Doug_B_Erdely@cup.portal.com (06/18/88)
MMM... Sorry... I have to disagree with you on one thing Dave.. I myself.. can't speak for the rest of the folks... am not always running the same combination of programs... So if GOMF keeps pointing to the same program time after time... I am going to start to think something fishey is going on with that program! I have Gomf come "alive" in my startup-sequence.. seems pretty handy! - Doug - Doug_B_Erdely@Portal.Cup.Com