mhovan@gmuvax2.gmu.edu (Mike Hovan) (05/08/91)
Well I recieved 5.01 yesterday, installed today, and almost
threw it out the window tonight.
Anybody know what the following error means:
(0) Unrecoverable error 668 : Eval Stack Fault
run-time error R6001
- null pointer assignment
Doesn't look good, I know a MSC error when I see one. You know
this is the 3rd revision of the Clipper product I have worked with
(S87, 5.0, 5.01) in the last 3 years, and as far as I am concerned this
thing is still in alpha test mode.
The error happens before getting into any of my code (the first line
of code is a DISPOUT("MADE IT") and that never gets executed). The
particular project is about 7000 lines of code (re)written from scratch
when 5.0 came out. The program has no warnings under the 5.0 compiler.
Mike
--
|X|X| "Women, Michael Andrew Hovan III |X|X|
|X| Can't live with them, mhovan@gmuvax2.gmu.edu |X|
|X| Can't fry them in a WOK!" George Mason University |X|
|X|X| -- MTV Half-Hour Comedy Hour Fairfax, Virginia, USA |X|X|tleylan@pegasus.com (Tom Leylan) (05/09/91)
In article <1991May7.235644.28744@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > > Well I recieved 5.01 yesterday, installed today, and almost >threw it out the window tonight. > > (0) Unrecoverable error 668 : Eval Stack Fault > run-time error R6001 > - null pointer assignment > > Doesn't look good, I know a MSC error when I see one. You know >this is the 3rd revision of the Clipper product I have worked with >(S87, 5.0, 5.01) in the last 3 years, and as far as I am concerned this >thing is still in alpha test mode. > > The error happens before getting into any of my code (the first line >of code is a DISPOUT("MADE IT") and that never gets executed). The >particular project is about 7000 lines of code (re)written from scratch >when 5.0 came out. The program has no warnings under the 5.0 compiler. > Mike, I don't know if you can accept my comments in the helpful way that they are intended but try. First, you have a problem with the code. Nothing unusual there, I'd be happy to send you some of my C code that blows up yet I do not scream that Microsoft doesn't know what they are doing. Second, you are mistaken about the "alpha mode" comment. If we legitimize our knowledge by the number of versions that we've used then it's important that you know I started with Winter '85 and that I have used 5.0 since it was created and wrote the 5.0 demo that appeared at the 1989 Comdex Fall. There were problems with the original 5.0 release and nobody denies it and everybody regrets it but 5.01 is as solid as anything I've seen. To get the heart of your problem, are you using any third-party libraries, some of them have not been updated to work properly with 5.01 ? Have you tried isolating parts of the code ? I can guarantee that your first line of code would execute, the stack overflow appears to be happening in the startup code. Have you inadvertantly used S'87 code (perhaps in your own personal .LIB file) ? Which linker are you using ? If not the .RTLink supplied then you could have an old version of Blinker or Warplink. In short, I'd be happy to help you with problems but if you are going to throw your arms up in the air and badmouth what I think is a superior product to others of the same vein then it isn't that I don't want to help but that you don't want it. tom (ex-Senior Systems Analyst / Nantucket Corporation)
mpd@anomaly.sbs.com (Michael P. Deignan) (05/09/91)
mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > Anybody know what the following error means: > (0) Unrecoverable error 668 : Eval Stack Fault > run-time error R6001 > - null pointer assignment Out of memory error. I get the same thing when I attempt to load an application with less than 425k. >425k it will run without a hitch. I don't know if that's what it really means, but that's the symptom and the cure for the same application I'm working on here. Here is a better one for you... Sometimes, completely random, after I linkedit my application and start it, I will get halfway thru one screen: "Unrecoverable error 415: Cannot load overlay file '*'" (the '*' is actually a little smiley face in a circle.) A call to Nantucket's brilliant technical support yielded Nantucket: "Oh, it must be a bug in your program" I asked: 1. "How? Since I don't have an overlay file, just one .EXE" 2. "If I make a small change to an unrelated module, and re-linkedit the application, this error goes away." Nantucket: "Well, nobody else has reported this error, it must be your application." > Doesn't look good, I know a MSC error when I see one. You know >this is the 3rd revision of the Clipper product I have worked with >(S87, 5.0, 5.01) in the last 3 years, and as far as I am concerned this >thing is still in alpha test mode. No shit. I'm really pissed off at these assholes. I've got a product which is supposed to be released to end users at the end of June, and these dipshits can't even get the link editor to work correct. Then, when I call with a problem, I get shit like "oh, nobody else has reported that problem" and "it must be your program." Bullshit. The same code, linkedited a second time, with the same exact keystrokes, with run without a hitch. If they always used that "nobody else has reported this problem" logic, their goddamn software would never have a bug in it! MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
mpd@anomaly.sbs.com (Michael P. Deignan) (05/10/91)
tleylan@pegasus.com (Tom Leylan) writes: >Which linker are you using ? If not the .RTLink >supplied then you could have an old version of Blinker or Warplink. BZZZT. Wrong answer. I cannot speak for Warplink, but can state with complete confidence that Blinker will *not even link* Clipper 5.01a applications. Blinkinc is scheduled to release an update in a few weeks. [remainder of post deleted for brevity[] Tom, If what you say is true, then why can I take a binary, execute it on a machine with 450k free, then load a TSR which takes, say, 60k, leaving 390k free, and then attempting TO RUN THE SAME EXACT BINARY get the "Eval stack " error message? Sorry, the "something is wrong with your code" crap doesn't cut it. MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
tleylan@pegasus.com (Tom Leylan) (05/11/91)
In article <1991May09.090352.17859@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: > >Here is a better one for you... > >Sometimes, completely random, after I linkedit my application and start >it, I will get halfway thru one screen: > >"Unrecoverable error 415: Cannot load overlay file '*'" > etc. >No shit. I'm really pissed off at these assholes. I've got a product which >is supposed to be released to end users at the end of June, and these >dipshits can't even get the link editor to work correct. > <more nonsense removed> Michael, I can't understand why nobody wants to talk to you I usually enjoy being called an asshole and a dipshit... I assume you greet your customers with a smile when they rant and rave. I don't know what "linkedit" is nor have I heard of a "link editor" so forgive me my stupidity. Are you using the .RTLink that was supplied with the product ?Many people use Blinker, version 1.4 is not entirely compatible, same thing with Warplink though new version of both are due shortly. Quite possibly you could speed up the process by calling both companies and calling them assholes. The error you mention sounds like you may have renamed the overlay or possibly you copied the app but left an external overlay in another subdirectory. If you aren't using external overlays perhaps you renamed the .EXE file, can't swear to it but the original name of the .EXE is probably contained in the file for reference when the overlayed portion of the file needs to be read in. In any case you hardly make a case for your problem with the way you phrase your messages, I personally don't care what your problem is any more and if it were in my power I would refund your money if you agreed to go purchase FoxPro. You don't need the grief and frankly neither does anyone else. tom
mpd@anomaly.sbs.com (Michael P. Deignan) (05/12/91)
tleylan@pegasus.com (Tom Leylan) writes: >I can't understand why nobody wants to talk to you I usually enjoy being >called an asshole and a dipshit... I assume you greet your customers with a >smile when they rant and rave. I don't consider the expectation of a nearly bug-free software product to be too big an expectation, do you? After all, they've over six months get do it. I think the folks at Nantucket need some of Phillip Crosby's "Do It Right The First Time" Quality programs. >I don't know what "linkedit" is nor have I heard of a "link editor" so forgive >me my stupidity. Its a leftover term from my IBM mainframe systems programming days. You "link edit" your object decks to create a "load module" or a "phase", depending on which OS you're running. >Are you using the .RTLink that was supplied with the product? I have to, as Blinker won't even linkedit the simplist 5.01a 1-line-of-code application. "Invalid COMDEF value" (or similar) error message is yielded by Blinker. This is a known problem and a phone call to Blinkinc tech support will yield a pre-recorded message explaining that a it will be fixed by version 1.5. This, however, is not my problem. >Quite possibly you >could speed up the process by calling both companies and calling them assholes. Not at all. They didn't promise me a bug-free 5.01a version of their product, did they? >The error you mention sounds like you may have renamed the overlay or possibly >you copied the app but left an external overlay in another subdirectory. If >you aren't using external overlays perhaps you renamed the .EXE file, can't >swear to it but the original name of the .EXE is probably contained in the >file for reference when the overlayed portion of the file needs to be read >in. I'll explain this once more: 1. I compile my .PRG's 2. I linkedit an .EXE file 3. I run it. It will get to a certain point in the program and either "hang" (requiring a hard-reset) or I will get the "Unrecoverable error 415" message (which even Nantucket says isn't in their "secret manual" from Pocketsoft.) Note that there is NO intermediate step where the .EXE is renamed, copied, etc. There is NO .OVL file (Thus making me wonder why the program is looking for an "overlay file" in the first place.) 4. Since I now say "Okay, its a program bug", I now re-compile ALL PRG's with the "/b" switch (making NO code changes) and re- linkedit the .EXE file. This will allow me to run the debugger and see what is happening. 5. I re-run the .EXE via CLD, and, mimicing the EXACT keystrokes, the program will run with NO hangup/error. 6. I re-run the .EXE from the dos program, and, mimicing the EXACT keystrokes, the program will run with NO hangup/error. 7. I re-re-compile all .PRG's without the "/b" switch, to get rid of all the extra debugging stuff, and re-re-linkedit the .EXE 8. I re-re-run the .EXE which should be, in theory, identical to the .EXE created in step #2, and it will run with NO hangup/error. A call to Nantucket yielded "Oh, its a problem with your program." ARRRRRGH! Now you see why I'm SO PISSED. NO IT'S NOT a problem with my program! Its a problem with either the Clipper compiler, or the .RTlink linker! I'm sorry, the little smiley face in the "Cannot load overlay file '*'" should be a clear indication to EVERYONE that something, somewhere, is not getting linked properly, and thus there is an un-initialized pointer or some other such nonesense. >In any case you hardly make a case for your problem with the way you phrase >your messages, I personally don't care what your problem is any more and if >it were in my power I would refund your money if you agreed to go purchase >FoxPro. I'm sorry if you get offended, but I get really offended when someone at Nantucket throws me the "its a problem with your program" line of crap. At this point, I'm sorry I even got involved with Clipper 5.0 at all. I should have stayed with S'87. 15,000 lines of code later, however, I have no choice, it has to be 5.0. >You don't need the grief and frankly neither does anyone else. Nobody deserves the grief Nantucket is spewing. I guess they wanted to release a bug-free version of their product, and the easiest way to insure that is to make sure any technical problems were "problems with <customers'> programs" and not their product. Sorry, it don't wash. MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
mhovan@gmuvax2.gmu.edu (Mike Hovan) (05/14/91)
Well I have been dueling with Tom in E-Mail, but to show
my support for Mr. Deignan I am going to move further comments here.
Anyway, I started this thread a while back with a question about an
error message I recieved from clipper 5.01. I have NOT tracked down
the problem although I am slowly digging up a little bit of Info
about the new clipper release. A release which is STILL buggy, no
matter what propaganda Mr. Leyland insists on spewing.
Nantucket may have fixed the virtual memory problems from
version 5.0 but they have added/revealed static memory problems with the
latest release. (Not to mention the Overlay problems MR. Deignan reports)
Here is a list of the Undocumented errors I have encountered:
668: Eval Stack Fault
Possibly stack underflow ??? (Mr Leyland ?)
This error is random, and has not been
reproduced.
667: Eval Stack Fault
Looks like it might have something to do
with stack overflow.
650: Processor Stack Fault
Again, it looks like something to do with stack
overflow.
332: ???????
This error said something like Out of
String/Array space. This error has not
been reproduced.
667 & 650 are more limitations of DOS than clipper. (Although I think
that a more elegant program termination would be nice. AND DOCUMENTATION
SOMEWHERE TELLING ME WHY I SEE THESE ERRORS!) 668 and 332 are the
ones that worry me, as they show up randomly. I can run a program 10 times
on 4 different machines with identical key sequences, and it will crash
3 of 40 times; Recompile and it runs without problems.
Has anyone been over on compuserve to see if anything interesting
is showing up from those folks?
Has anyone figured out how to get a recursive function to run in a
"SEQUENCE" block?
MIke
ps. I think I just figured it all out. This is Nantucket's way of getting
you to buy their support contract. (I know the first month is free.)
pps. For anyone thinking about upgrading, 5.01 is faster at both compile
time and run-time. It also really does have virtual memory. I actually
dynamically allocated 160,000 elements in dozens of arrays. I
wish I could have done it in one, but the 4096 limit got me.
--
|X|X| "Women, Michael Andrew Hovan III |X|X|
|X| Can't live with them, mhovan@gmuvax2.gmu.edu |X|
|X| Can't fry them in a WOK!" George Mason University |X|
|X|X| -- MTV Half-Hour Comedy Hour Fairfax, Virginia, USA |X|X|tmkk@uiuc.edu (K. Khan) (05/15/91)
In article <1991May13.223912.1975@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > > > 650: Processor Stack Fault > Again, it looks like something to do with stack > overflow. Correct. This is, however, not a limitation of DOS as you speculate a little later in your message. Rather, it is the stack for the Clipper program itself. To test this idea, just write a short program which calls the following function: function recurse() recurse() return After a moment, you'll get the Processor Stack Fault message since you're making bunches of calls with no corresponding returns, filling up your stack segment. >ps. I think I just figured it all out. This is Nantucket's way of getting > you to buy their support contract. (I know the first month is free.) If so, I think their little plan is about to backfire BIG TIME.
mpd@anomaly.sbs.com (Michael P. Deignan) (05/15/91)
mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > Nantucket may have fixed the virtual memory problems from >version 5.0 but they have added/revealed static memory problems with the >latest release. Yes! Very much so! Remember those "5553: Internal Error" messages? I'm hitting those now too, at completely random points. >668 and 332 are the >ones that worry me, as they show up randomly. I can run a program 10 times >on 4 different machines with identical key sequences, and it will crash >3 of 40 times; Recompile and it runs without problems. This is the same exact thing that happens here, and is the main reason why I get extremely pissed off when Nantucket technical support says "oh, its your program". Looks like they are attempting to insure a "bug free" release by not admitting to any bugs. MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
tomr@dbase.a-t.com (Tom Rombouts) (05/15/91)
In article <1991May11.031607.25343@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: [ anti-Clipper 5.01 diatribe with profanity deleted ] >I don't know what "linkedit" is nor have I heard of a "link editor" so forgive >me my stupidity. The precise term is "linkage editor." "Linker" is a modern abbreviation. (Look at your old IBM 360 documentation if you don't believe me!) All is forgiven.... :-) Tom Rombouts Torrance 'Tater tomr@ashtate.A-T.com
mhovan@gmuvax2.gmu.edu (Mike Hovan) (05/15/91)
Somebody somewhere wrote: >In article <1991May13.223912.1975@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: >> >> >> 650: Processor Stack Fault >> Again, it looks like something to do with stack >> overflow. > >Correct. This is, however, not a limitation of DOS as you speculate a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >little later in your message. Rather, it is the stack for the Clipper >program itself. To test this idea, just write a short program which >calls the following function: > >function recurse() > > recurse() > return > >After a moment, you'll get the Processor Stack Fault message since >you're making bunches of calls with no corresponding returns, filling up >your stack segment. > I understand that it is the Clipper stack overflowing. But I still hold that it is an operating system problem (DOS SUCKS), a "Real" operating system would allow an (semi-) infinite stack. Maybe the nantucket guys should look into making their stack part of the virtual memory system. :-) But if you really think about it, that would be a pain. Another thing to try if you like seeing error messages (and we must, we own clipper) is to increase your stack size at link time. (on an endless recursive function) Something like this: rtlink fi recursor /stack:32768 This produces the 667 error I mentioned in one of my last posts. >>ps. I think I just figured it all out. This is Nantucket's way of getting >> you to buy their support contract. (I know the first month is free.) > >If so, I think their little plan is about to backfire BIG TIME. YUP. Mike -- |X|X| "Women, Michael Andrew Hovan III |X|X| |X| Can't live with them, mhovan@gmuvax2.gmu.edu |X| |X| Can't fry them in a WOK!" George Mason University |X| |X|X| -- MTV Half-Hour Comedy Hour Fairfax, Virginia, USA |X|X|
tleylan@pegasus.com (Tom Leylan) (05/16/91)
In article <1991May10.112405.7053@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: > >BZZZT. Wrong answer. I cannot speak for Warplink, but can state with >complete confidence that Blinker will *not even link* Clipper 5.01a >applications. Blinkinc is scheduled to release an update in a few >weeks. > >If what you say is true, then why can I take a binary, execute it on a >machine with 450k free, then load a TSR which takes, say, 60k, leaving >390k free, and then attempting TO RUN THE SAME EXACT BINARY get the >"Eval stack " error message? > Michael, If there is anything that you could tell me about Blinker I would be surprised as I have every version they ever made, have the current beta and know the author. You are leaping to conclusions about the way Clipper's VMM system operates and the interpretation of the value returned by MEMORY(0). The reason that taking 60K out of the system via a TSR is that a minimum amount of RAM is required to operate VMM at all. Surely you are aware that some TSRs even require additional memory at startup leaving a core in RAM. You can allocate a 5 MB array (even though you don't have 5 MB of RAM) and I'll bet that MEMORY(0) returns approximately the same value. You seem to know a lot about how the world ought to operate and I think we could all benefit from your expertise in compiler design... contact Nantucket development and explain how you want things to work, they could use a laugh. Seriously if you use nothing else but logic, how do you explain the 1000s of other Clipper developers who are using 5.01 successfully ? You can't think that I'm doing it wrong since I don't crash. tom
tmkk@uiuc.edu (K. Khan) (05/16/91)
In article <1991May15.163013.27831@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > > >Somebody somewhere wrote: > >>In article <1991May13.223912.1975@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: >>> >>> >>> 650: Processor Stack Fault >>> Again, it looks like something to do with stack >>> overflow. >> >>Correct. This is, however, not a limitation of DOS as you speculate a > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>little later in your message. Rather, it is the stack for the Clipper >>program itself. > > I understand that it is the Clipper stack overflowing. But I >still hold that it is an operating system problem (DOS SUCKS), a "Real" >operating system would allow an (semi-) infinite stack. The stack segment(s) used by your program have nothing to do with DOS. The stack segment is defined by the processor's SS register, which points to the start of a stack segment 64K bytes in size. the SP register is used as an offset into the stack segment for the top of the stack. Since the stack segment starting address is kept in a register, it's possible to have multiple stack segments simply by loading a new value into SS at run time. Thus, the only limit on the effective stack size is the size of memory (as well as the skill of the programmer attempting to code these sorts of stack manipulations ;-) Thus, stacks can be manipulated independent of DOS. Since it is possible to write programs with multiple stack segments which run under DOS, this is clearly a limitation of the COMPILER, not of DOS itself (i.e. Clipper doesn't bother with all the hairy calculation necessary to use multiple stack segments). I do, however, agree with you that DOS is not a "real" operating system. ;-) > Another thing to try if you like seeing error messages (and we >must, we own clipper) ;-)
tleylan@pegasus.com (Tom Leylan) (05/16/91)
In article <1991May09.090352.17859@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: > >"Unrecoverable error 415: Cannot load overlay file '*'" >A call to Nantucket's brilliant technical support yielded >Nantucket: "Oh, it must be a bug in your program" > >I asked: > >1. "How? Since I don't have an overlay file, just one .EXE" > >Nantucket: "Well, nobody else has reported this error, it must be your > application." > >No shit. I'm really pissed off at these assholes. I've got a product which >is supposed to be released to end users at the end of June, and these >dipshits can't even get the link editor to work correct. > >Then, when I call with a problem, I get shit like "oh, nobody else has >reported that problem" and "it must be your program." Bullshit. The same >code, linkedited a second time, with the same exact keystrokes, with run >without a hitch. > Michael, .RTLink automatically creates dynamic overlays of Clipper code the overlay is contained in the .EXE file. I believe that you are expecting too much from "tech support" they are not part of the development staff. I think that they could do much better but they aren't paid what you are paid and if they were obviously the cost for tech support would go up. How do you handle it in your company ? If a user of one of your systems doesn't understand something do you personally take the calls or do you have a staff to handle it so that you can do more productive things with your time ? Would that member of your staff know every intricasy of the product like you do ? tom
tleylan@pegasus.com (Tom Leylan) (05/16/91)
In article <1991May13.223912.1975@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > > Well I have been dueling with Tom in E-Mail, but to show >my support for Mr. Deignan I am going to move further comments here. >Anyway, I started this thread a while back with a question about an >error message I recieved from clipper 5.01. I have NOT tracked down >the problem although I am slowly digging up a little bit of Info >about the new clipper release. A release which is STILL buggy, no >matter what propaganda Mr. Leyland insists on spewing. > > 668: Eval Stack Fault > Possibly stack underflow ??? (Mr Leyland ?) > This error is random, and has not been > reproduced. > > Has anyone figured out how to get a recursive function to run in a >"SEQUENCE" block? > Mike, You term our conversation "dueling", you continue to mispell my name and whatever I say is "spewing propaganda". I also never said that Error 668 was a stack underflow, I used it as a hypothetical example since you insist that you could fix it if you knew what it was. My suggestion then as it remains is that you can't fix it if there is an error in Clipper.Lib and that there is no one-to-one correspondence with a line of Clipper code and an internal error. Overflowing the stack can be fixed by increasing the stack size. Obviously that grabs more memory from the free pool, I'm doubtful that the stack is being swapped via VMM but I don't know for certain. You seem to be low of memory, that can affect any program, one you wrote or Lotus 1-2-3 or your favorite accounting program. Any system that you develop in Clipper has a smaller RAM footprint than the equivalent system written in either dBASE IV or FoxPro and approaches that of an equivalent system written in C. You will likely doubt that but you need only post your C code that permits the evaluation of a macro entered from the keyboard to prove me wrong. Spewing propaganda is in the eye of the beholder and frankly I haven't seen you answer one Clipper question positively from anyone. If it is truly that lousy simply discontinue it's use and the problem is solved. Besides spewing propaganda I have developed system in Clipper since it's original release and have not been happier since the release of 5.01. There are hundreds of other companies with other compilers who could benefit from your contructive criticisms. tom
rdb@ktibv.uucp (Rob den Braasem) (05/16/91)
tmkk@uiuc.edu (K. Khan) writes: >In article <1991May13.223912.1975@gmuvax2.gmu.edu> mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: >> >> >> 650: Processor Stack Fault >> Again, it looks like something to do with stack >> overflow. >function recurse() > recurse() > return >After a moment, you'll get the Processor Stack Fault message since >you're making bunches of calls with no corresponding returns, filling up >your stack segment. <FLAME ON > I have to reply to this. I'm NOT an AMATEUR in working with clipper and other programming languages. And a stupide thing like this is the first thing I would look for. However I also did get a stack failure when I tried to work with a recursive procedure in Clipper 5.0. It did crash the first time I did call the routine again. < FLAME OFF> Clipper 5.0 has some nice features like AADD, but I prefer to stay with S'87. PABRAS
tmkk@uiuc.edu (K. Khan) (05/16/91)
In article <1991May15.204817.23093@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: >In article <1991May09.090352.17859@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: >> >>"Unrecoverable error 415: Cannot load overlay file '*'" >>A call to Nantucket's brilliant technical support yielded >>Nantucket: "Oh, it must be a bug in your program" >> >>I asked: >> >>1. "How? Since I don't have an overlay file, just one .EXE" >> >>Nantucket: "Well, nobody else has reported this error, it must be your >> application." >> >>No shit. I'm really pissed off at these assholes. I've got a product which >>is supposed to be released to end users at the end of June, and these >>dipshits can't even get the link editor to work correct. >> >>Then, when I call with a problem, I get shit like "oh, nobody else has >>reported that problem" and "it must be your program." Bullshit. >> >Michael, > >..RTLink automatically creates dynamic overlays of Clipper code the overlay >is contained in the .EXE file. True. But notice how Nantucket's own tech support was unable to tell Michael this fact - it took a fellow netter. I submit that when the general user population knows more about the product than the official representatives of the company which makes that product, there is something wrong! >I believe that you are expecting too much from "tech support" they are not >part of the development staff. They should have at least been able to explain the overlay stuff! >I think that they could do much better but >they aren't paid what you are paid and if they were obviously the cost for >tech support would go up. Of course, if Clipper were free of bugs to begin with, they wouldn't need so many tech support reps and could afford to pay a higher salary to the few who remain. ;-)
mpd@anomaly.sbs.com (Michael P. Deignan) (05/17/91)
tleylan@pegasus.com (Tom Leylan) writes: >Seriously if you use nothing else but logic, how do you explain the 1000s of >other Clipper developers who are using 5.01 successfully ? You can't think >that I'm doing it wrong since I don't crash. Easy. Nantucket wants to insure a "bug free" release, and the best way to insure that is to implement the policy of stating every tech support call is a "problem with your program". If I have a problem in my code, then why can: 1. I take a binary, run it with set keystrokes, and have it: a. "hang" entirely forcing a hard-reset b. return some totally bogus "Unrecoverable error 415: Unable to open overlay file '[happy-face]' 2. Then re-compile the modules with the '/b' switch, making no code changes whatsoever, and have the new binary wrun fine with the same exact keystrokes. Or: 1. Run a binary requiring 319k to start (according to .RTlink) run okay with 420k, 2. The same binary in 390k yields an "eval stack fault", scaring the shit out of the user. No simple "insuffienct memory" error, no, lets get fancy here. Of course, based upon the statements by other Clipper 5.01 users on this newsgroup, I'm not the only person having this problem. And I daresay that others out there are having problems too. Many users still haven't gotten their upgrades. The 5.01 that I am using was received two weeks ago, and a client with a copy still hasn't received their upgrade. So, exactly how many people ARE running 5.01? I tend to believe that the problem is in the link editor, not in the Clipper-produced code itself. However, there ARE still problems, and Nantucket better address them soon, or they will end up looking like the Ashton Tate of 1991. MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
tleylan@pegasus.com (Tom Leylan) (05/18/91)
In article <1991May16.135400.4616@ux1.cso.uiuc.edu> tmkk@uiuc.edu (K. Khan) writes: > >Of course, if Clipper were free of bugs to begin with, they wouldn't >need so many tech support reps and could afford to pay a higher salary >to the few who remain. ;-) K., I imagine that you are speaking from a base of experience, the service company that you ran ? Your years as a support technician ? When I worked at Nantucket (I was not in tech support) I listened to the quality of the questions as well as the quality of the answers. Many times people call (and I'm certain your clients have also) describing a problem with the words "I was doing something, and something happened and a there was message on the screen". Fifteen minutes later they have managed to give an accurate report of the problem. In other cases the problem has nothing to do with Clipper, possibly they were using Clipper at the time but the guy doesn't have access writes to some Novell subdirectory or they used "Johnny Jones Super Shareware product" to directly modify Clipper indexes and they are all screwed up. Well Johnny said it is Clipper compatible so what's wrong with you guys ? On the other hand I've heard less than helpful answers, incomplete answers and some downright wrong answers. This is unfortunate and I think much work needs to be done but it isn't unique to Nantucket or the computer industry. I had to argue with a travel agent the other day to sell me a ticket for a flight that I knew was not full but she insisted it was (she would check the computer of course (oops would NOT check the computer)). I run into incompetence every day from the people at Burger King to the people who run the U.S. government, it's frustrating but one learns to deal with it. tom
tleylan@pegasus.com (Tom Leylan) (05/18/91)
In article <1991May15.110418.5031@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: >mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > >> Nantucket may have fixed the virtual memory problems from >>version 5.0 but they have added/revealed static memory problems with the >>latest release. > >Yes! Very much so! > >Remember those "5553: Internal Error" messages? I'm hitting those now too, >at completely random points. > That application that you sold me is blowing up with random "variable not found" errors... Notice how easy it is to lie ? There is only one question I really need answered and if you can possibly do it seriously I would appreciate it. Why don't I get the same errors ? Why don't thousands of others get the same errors ? There could be many reasons for you getting these errors (including the possibility of bugs in 5.01) but there are plenty of others. You could be using an older copy of Blinker or Warplink that doesn't support 5.01. You could be linking in routines from Funcky or 3PX or any of two dozen other function libraries (Netlib perhaps ?) that hasn't been updated to 5.01 yet. You could be referencing your own C or assembler routine and could be messing with registers, you could have old S'87 code in a library along the path that is getting linked in. So the question remains why is it that so few people I know are having problems and the majority that do find that they in fact misunderstood the way that STATIC variables or codeblocks operate and report success as soon as they make the adjustment ? If I were to post the names of 100 satisfied Clipper developers would that change your mind ? 200 names ? At what point will you accept the likelihood that you are mistaken ? I'll tell you when Nantucket will... the moment that you isolate the problem into a reasonable amount of code and submit it to them as a bug. I realize that you feel the business world in general and Nantucket in particular has nothing better to do than foul up your life but some people think Elvis is alive too... tom
kms@well.sf.ca.us (Kelly Stanonik) (05/18/91)
mpd@anomaly.sbs.com (Michael P. Deignan) writes: > 1. I compile my .PRG's > 2. I linkedit an .EXE file Do you think it would be possible to send up a copy of your .LNK file, and the result file of compiling your prgs with the /W switch? I'm not suggesting that you're not having a problem, but maybe we can all get to the bottom of it (Clipper's fault or not) if you supply some more info. -- * "My God, it's full of stars" -- overheard in a hamburger hamlet in west la. * kms@well.sf.ca.us, or bix: kms, or prodigy (yuck!) cgpd47a * 2zip/arip cis: 74730,77 * free software snail: 4469 ventura cyn #e107, sherman oaks, ca 91423
kms@well.sf.ca.us (Kelly Stanonik) (05/18/91)
mhovan@gmuvax2.gmu.edu (Mike Hovan) writes: > Has anyone been over on compuserve to see if anything interesting >is showing up from those folks? Both "Mr. Leylan" and myself are on CompuServe, and the initial response from 5.01 has been decisively positive. Some folks are having problems, and I'm actually one of them, but I suspect my problems are the result of third party libraries. All in all my experience with this new release has been VERY positive. -- * "My God, it's full of stars" -- overheard in a hamburger hamlet in west la. * kms@well.sf.ca.us, or bix: kms, or prodigy (yuck!) cgpd47a * 2zip/arip cis: 74730,77 * free software snail: 4469 ventura cyn #e107, sherman oaks, ca 91423
kms@well.sf.ca.us (Kelly Stanonik) (05/18/91)
To be perfectly fair, Blinker 1.4 _won't_ work with 5.01 at all. I agree that 1000's of developers are using Clipper 5.01 right now and getting positive results, but to be fair, nobody's had the release version for all that long! -- * "My God, it's full of stars" -- overheard in a hamburger hamlet in west la. * kms@well.sf.ca.us, or bix: kms, or prodigy (yuck!) cgpd47a * 2zip/arip cis: 74730,77 * free software snail: 4469 ventura cyn #e107, sherman oaks, ca 91423
mpd@anomaly.sbs.com (Michael P. Deignan) (05/19/91)
tleylan@pegasus.com (Tom Leylan) writes: >That application that you sold me is blowing up with random "variable not >found" errors... >Notice how easy it is to lie ? Is this an indictment that I, and others in this newsgroup, are lying about the problems we've encountered with 5.01a? >Why don't I get the same errors ? Why >don't thousands of others get the same errors ? Quite possibly because your code doesn't involve the level of sophistication that ours does? Perhaps we're writing something other than "hello world" programs with Clipper? >There could be many reasons for you getting these errors (including the >possibility of bugs in 5.01) but there are plenty of others. You could be >using an older copy of Blinker or Warplink that doesn't support 5.01. Since you're such a good friend with the author of Blinker, you should know this is an impossibility since Blinker yields invalid "COMDEF" errors when used with 5.01a. In case your friend forgot to mention it, you can call Blinkinc tech support and get a recording indicating such. >You >could be linking in routines from Funcky or 3PX or any of two dozen other >function libraries (Netlib perhaps ?) that hasn't been updated to 5.01 yet. Sorry, 100% Clipper code. No external libraries... >You could be referencing your own C or assembler routine and could be messing >with registers, you could have old S'87 code in a library along the path that >is getting linked in. ...or C/Assembler code... >So the question remains why is it that so few people I know are having problems >and the majority that do find that they in fact misunderstood the way that >STATIC variables or codeblocks operate and report success as soon as they >make the adjustment ? I don't consider the message "Unrecoverable Error 415: Unable to open overlay file '<happy face>'" to be a simple "misunderstanding" of how code blocks function. >At what point will you accept the likelihood >that you are mistaken ? I won't, since the problem is intermittent, and gets resolved by re-linking the application. So, when I can re-link an application and get rid of the problem WITHOUT MAKING A SINGLE CODE CHANGE, *that* tells me there is something wrong with the development software. >I'll tell you when Nantucket will... the moment that >you isolate the problem into a reasonable amount of code and submit it to >them as a bug. Or, when hundreds of other people begin to experience the same problem. When the database community decides to send Nantucket the route of Ashton Tate. MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
mpd@anomaly.sbs.com (Michael P. Deignan) (05/19/91)
kms@well.sf.ca.us (Kelly Stanonik) writes: >Do you think it would be possible to send up a copy of your .LNK file, >and the result file of compiling your prgs with the /W switch? I'm >not suggesting that you're not having a problem, but maybe we can all >get to the bottom of it (Clipper's fault or not) if you supply some more >info. Unfortunately, I have had to switch back to v5.0. Although v5.0 had some problems, I could work around them. The totally intermittent, random actions of "hanging" and getting an "unrecoverable error 415" virtually brought development to a standstill. As time allows, I will go back to v5.01a and see if I can get the problems replicated. MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
tleylan@pegasus.com (Tom Leylan) (05/19/91)
In article <1991May17.013633.8848@anomaly.sbs.com> mpd@anomaly.sbs.com (Michael P. Deignan) writes: >tleylan@pegasus.com (Tom Leylan) writes: > >>Seriously if you use nothing else but logic, how do you explain the 1000s of >>other Clipper developers who are using 5.01 successfully ? You can't think >>that I'm doing it wrong since I don't crash. > >Easy. Nantucket wants to insure a "bug free" release, and the best way to >insure that is to implement the policy of stating every tech support call >is a "problem with your program". > Michael... I think we're going to have to end the discussion since anyone can plainly see that it makes no sense any more. Even if Nantucket had a recording that simply stated that it was the programmers' fault it would not explain why I haven't received the errors you mention and that I personally know about 100 people (very well) that are using 5.01. You remain irrational with your explanations and continue to think that the product must behave as you believe it does and not how it truely operates. No, I'm not talking about the first error, I'm talking about your insistence that the load size displayed by the linker is some sort of absolute number which it plainly is not. It is an estimate based upon what the linker knows and the linker doesn't know what Clipper's startup code is going to do. I can't possibly help you, I feel quite certain that Nantucket development couldn't help you, you just don't want it to work. So fine, my software isn't operating, all the other people that I know who pay $12.50 an hour on Compuserve are just calling in and lying, there programs all hang the computer but they spend money every day to sucker others into purchasing the product. Elvis is alive and a statue of him was found on the moon. Thank you for what has been an interesting exercise. tom
tmkk@uiuc.edu (K. Khan) (05/21/91)
In article <1991May17.210556.18104@pegasus.com> tleylan@pegasus.com (Tom Leylan) writes: > >I run into >incompetence every day from the people at Burger King to the people who run >the U.S. government, it's frustrating but one learns to deal with it. Ah, so you're saying that I should just "learn to deal with" Nantucket's incompetence? ;-) Perhaps jumping into a bitch fest on Usenet *IS* one way in which I deal with it (if nothing else, it helps to work off the frustrations). It's also useful to know that other people are having similar problems with Clipper 5.01 (i.e. "I'm not the only one.") To MPD and others suffering from Clipper bugs: It happened again. After I installed the workaround for the first routine which suffered from the problem, a similar routine in another part of the program ran into the exact same problem. Our copy of FoxPro is on its way... :-(
kms@well.sf.ca.us (Kelly Stanonik) (05/21/91)
mpd@anomaly.sbs.com (Michael P. Deignan) writes: >Quite possibly because your code doesn't involve the level of sophistication >that ours does? Perhaps we're writing something other than "hello world" >programs with Clipper? I'm not going to blow my own horn, but I won't hesitate to blow Mr. Leylan's. Your implication that TL's code isn't sophisticated is pure hogwash. He's proved himself to be a *very* competent Clipper programmer over the years on Nanforum and among other things wrote the original 5.0 demo program. His programs exceed the "hello world" level of sophistication by several orders of magnitude. HE is very likely to find bugs in 5.01 if there are bugs to be found. If you HAVE found some bugs, then GOOD, let's get down to the nitty and the gritty and DEFINE them and Nantucket will get them FIXED. >Or, when hundreds of other people begin to experience the same problem. When >the database community decides to send Nantucket the route of Ashton Tate. When a lot of folks find the same problem it will turn up. Nantucket's made some mistakes in the past, and I think folks can tell you that I've been as hard or harder than anyone else on them. Frankly, though, I don't think 5.01 is one of them. -- * "My God, it's full of stars" -- overheard in a hamburger hamlet in west la. * kms@well.sf.ca.us, or bix: kms, or prodigy (yuck!) cgpd47a * 2zip/arip cis: 74730,77 * free software snail: 4469 ventura cyn #e107, sherman oaks, ca 91423