rcbaem@eutrc3.urc.tue.nl (Ernst Mulder) (08/28/89)
printf("Hello, World\n");
After adding a couple of variables to my program source, LSP suddenly
crashes. It started with runtime crashes, and of course I thought it was
entirely my own fault. But as far as I can tell my code doesn't contain
anything wrong.
The runtime error was either an address error or an illegal instruction,
something or someone was apparently corrupting my code while it was
running. Checking with LightsBug it seemed to be that the addresses of
certain global variables were wrong. An array would be positioned somewhere
in the middle of the program's code. Not on the stack. so a[i]:=0 would
place a 0 somewhere in my code...
Okay, the problem went further. At this time LSP crashes when either when
compiling my project, or when linking it. Even when this is the first thing
I do with a freshly booted LSP after opening my project.
Even when I completely rebuild my entire project.
I rather doubt it, but could it be something in my source code that
causes this behaviour? The only weird thing in my source is a 2000 line
procedure. (gives apr. 28K of code) But this procedure compiles just
fine, and at times that compiling DOES work, the procedure is OK
too.
The weird thing is, when LSP doesn't crash when compiling or when
Linking, the GO command crashes it (ID=02 or ID=03), but when I first
build an application, and run the application, everything is fine! (????)
Checking the debug option or not sometimes helps, sometimes doesn't.
Another weird thing: Everything went just fine, until I added an array
to the global variables of the program. According to LightsBug (putting
Stops at strategic places) the runtime error occurs even before ANY
value is given to ANY variable!
Could it be:
1) The resource manager can't handle the project anymore? Since LSP
stores all info in separate resources this could be a possibility.
2) My LSP is infected with a virus? (never had one ever, but who knows?
nVIR was found on one of our University's HDs...)
((Hope this doesn't sound as 'my program stops when I turn my Mac off,
could this be a Virus???'))
3) LSP can't handle very large procedures? (The code is still <32K
though, and the source file hasn't reached the upper module
size limit either)
4) I have too many variables to fit on the program's stack. (doubt
it, I have had programs with many more variables)
5) LSP runs out of memory while compiling or linking? Doubt it because
I have 2M of it..
Remains in doubts,... Ernst 'pooh' Mulder.
>
--------------------------------------
(How can I ever show you my emulated PC-2
when I can't even compile it anymore?
Last time I compiled it it worked quite
nice already...)
--------------------------------------siegel@endor.harvard.edu (Rich Siegel) (08/29/89)
In article <878@eutrc3.urc.tue.nl> rcbaem@eutrc3.uucp writes: > > Could it be: >1) The resource manager can't handle the project anymore? Since LSP > stores all info in separate resources this could be a possibility. Your project document may have gotten munged. Are you using MacroMaker? According to our Tech Support guys, MacroMaker has a known track record of smashing projects. >2) My LSP is infected with a virus? (never had one ever, but who knows? > nVIR was found on one of our University's HDs...) Possibly, but not likely. Worth checking into, though. >3) LSP can't handle very large procedures? (The code is still <32K > though, and the source file hasn't reached the upper module > size limit either) Not likely. >4) I have too many variables to fit on the program's stack. (doubt > it, I have had programs with many more variables) Same; the compiler will give you an error if there's not enough stack space to invoke a procedure or if too many locals are declared. >5) LSP runs out of memory while compiling or linking? Doubt it because > I have 2M of it.. You should get a warning message before you get a crash. Trust me. :-) R. ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "There is no personal problem which cannot be solved by sufficient application of high explosives." ~~~~~~~~~~~~~~~
rcbaem@eutrc3.urc.tue.nl (Ernst Mulder) (08/30/89)
In article <878@eutrc3.urc.tue.nl> I write: >> Could it be: >>1) The resource manager can't handle the project anymore? Since LSP >> stores all info in separate resources this could be a possibility. In article <2524@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: > Your project document may have gotten munged. Are you using >MacroMaker? According to our Tech Support guys, MacroMaker has a known >track record of smashing projects. No MacroMaker. No INITs whatsoever, I always program on a totally clean and standard System (6.0.2). I rebuilt the program's Project completely from scratch and the problem remained. It MUST be an error in the Linker. I had two Units, one of apr. 22K of compiled code, one of apr. 8K of code. These two untis were in the same Code segment, still <32K. With a real debugger I checked where the address-error at run-time occurred: At the moment this Code segment was loaded and a procedure in it was called. The Linker (while building the Application) crashes, probably while linking these two units.. When I moved the two units into separate Code segments the problem disappeared. And suddenly the Linker doesn't crash anymore and my program runs perfectly... (I, however, would like to have both units in the same Code segment, because one calls the other rather frequently.) It seems to be a linker problem, when Code segments have a size near to the maximum of 32K, however this is weird, really weird. A similar problem occurred earler. When I had 3 units in the same Code segment, the Linker would crash when I DIDN'T call one of the procedures in one of those units, and wouldn't crash when I DID.. The only non-common thing about the two units is that they have only a small number of procedures, and one rather big procedure taking up 90% of the units compiled code size. It's not a compiler's problem, because when the two units are in separate Code segments, they compile just fine and work like they should. I hope this focusses the problem a little more, because I would like to see it solved. :) Compilers shouldn't have bugs, because when something goes wrong you always blame yourself and that costs a lot of time trying to find errornous code which isn't there! :) Anyway, Bye! Ernst. >
slang@bnr.ca (Steven Langlois) (06/11/91)
Are there any rumours out there as to when Symantec will have System 7.0 versions of THINK C and THINK Pascal available. I am still using THINK Pascal but I am a little uncomfortable with using an application which is 90% compatible with System 7.0. I would also like to take advantage of 32 bit mode and virtual memory. I am having a problem with an object variable which suddenly looses its identity (i.e. making a method call causes a runtime error) when running my program under System 7.0. The same program binary runs fine on System 6.0.x. I have tried to trace it down but haven't had any luck as of yet. Do you have to lock an object before making a method call? I don't believe you do but I may be incorrect. Anyone know? Before I go crazy trying to track down this problem, I would like to get a hold of THINK Pascal which is 100% compatible with System 7.0 and see if the problem persists. Steven Langlois ISDN Basic Rate Access BNR, a subsidiary of Northern Telecom Internet: slang@bnr.ca
jtn@potomac.ads.com (John T. Nelson) (06/12/91)
In article <1991Jun11.120016.9941@bmers95.bnr.ca> slang@bnr.ca (Steven Langlois) writes: >Are there any rumours out there as to when Symantec will have System 7.0 >versions of THINK C and THINK Pascal available. I am still using THINK >Pascal but I am a little uncomfortable with using an application which >is 90% compatible with System 7.0. I would also like to take advantage >of 32 bit mode and virtual memory. I called Symantec's technical support people today inquiring about the availability of patches to THINK C or the availability of a new version of THINK C that will correct this deficiency. The response I received was less than helpful, but true to form for Symantec: "We cannot give out that information at this time." Frankly I find this to be a slap in the face. What's the big secret? Witholding information for whatever ludicrous beaurocratic reason can only hinder other product development and make Symantec's customers irate. Announcing product enhancements, on the other hand, can only help Symantec's image and their customers plan their development efforts. Without so much as a rumor as to when a System 7.0 VM compatible release will be available, I'll have to make a decision based on known facts and probably switch over to MPW 3.2 which at least does support VM and has a known release date. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ORGANIZATION: Advanced Decision Systems UUCP: kzin!speaker@mimsy.umd.edu INTERNET: jtn@potomac.ads.com SPOKEN: John T. Nelson PHONE: (703) 243-1611 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
jcav@quads.uchicago.edu (john cavallino) (06/12/91)
In article <1991Jun11.205040.26429@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: >In article <1991Jun11.120016.9941@bmers95.bnr.ca> slang@bnr.ca (Steven Langlois) writes: >>Are there any rumours out there as to when Symantec will have System 7.0 >>versions of THINK C and THINK Pascal available. > >I called Symantec's technical support people today inquiring about the >availability of patches to THINK C or the availability of a new >version of THINK C that will correct this deficiency. The response I >received was less than helpful, but true to form for Symantec: > >"We cannot give out that information at this time." > >Frankly I find this to be a slap in the face. What's the big secret? >Witholding information for whatever ludicrous beaurocratic reason can >only hinder other product development and make Symantec's customers >irate. Announcing product enhancements, on the other hand, can only >help Symantec's image and their customers plan their development >efforts. They had exactly the same attitude back in 1987 with regard to Multifinder compatibility--i.e. "We can't tell you if/when that will ever happen" I suspect that due to the nature of their products and the deep inner knowledge of the operating system they assume, THINK has _much_ more trouble reacting to major system upgrades than other sorts of vendors. I agree that it is silly for them to stonewall about a projected release date for a new version, but did you consider the possibility that they _just don't know yet_, due to the magnitude of the work involved or whatever? In the meantime, cut them a little slack. I mean, if even _Apple_ couldn't have a compatible MPW ready by the release of System 7... -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ c+ g+ k s+(+) e+ h- pv (qv) | Telephone: 312-702-6900
dorner@pequod.cso.uiuc.edu (Steve Dorner) (06/12/91)
In article <1991Jun11.205040.26429@potomac.ads.com> jtn@potomac.ads.com (John T. Nelson) writes: >Without so much as a rumor as to when a System 7.0 VM compatible >release will be available, I'll have to make a decision based on known >facts and probably switch over to MPW 3.2 which at least does support >VM and has a known release date. If you need VM with THINK C, you're gonna be sorry if you switch to MPW. 5 meg is adequate for MPW C + SADE, 8M is comfortable. (Add C++, gcc, or MacApp, and make 8M adequate, but not comfortable.) If you're getting a sizeable chunk of this memory out of VM, performance is really going to suffer. And MPW isn't what I would call fast to begin with. (Don't get me wrong; I use it, and it's ok--it's just a resource pig.) (And it IS a chunk of change, too...) -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
d88-jwa@byse.nada.kth.se (Jon W{tte) (06/12/91)
> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >Without so much as a rumor as to when a System 7.0 VM compatible >release will be available, I'll have to make a decision based on known Okay, here's a rumor: tomorrow. You'll soon find out if it's correct. They maybe want to continue selling 4.0 until they actually ship 5.0... If you need VM with THINK C, you're gonna be sorry if you switch to MPW. True. (And it IS a chunk of change, too...) No it's not. I did the switch in 45 minutes. (Granted, I have a lot of UNIX experience...) plus an additional two hours for porting the project I was working on. (No, that was NOT nethack :-) If I'll go back ? Well, if THINK C works with A/UX and system 7, maybe. Birdie tells me they're trying to stay competetive in the compiler area now, since they already have an environment. (And I hope they include the online stuff the just released as well. It's cool, but could use volume VI as well...) -- Jon W{tte h+@nada.kth.se - Speed !
minow@ranger.enet.dec.com (Martin Minow) (06/12/91)
In a recent article jtn@potomac.ads.com (John T. Nelson) expresses anger that Symantec will not inform him as to when a a 7.0 compatible version of Think C will be available, finding this "a slap in the face." It's also the law -- the Securities and Exchange Commission takes a very dim view of publicly-traded companies leaking information about unannounced product shipping dates -- in their view, it's called "kiting the stock." Martin Minow minow@ranger.enet.dec.com
dorner@pequod.cso.uiuc.edu (Steve Dorner) (06/13/91)
In article <D88-JWA.91Jun12132644@byse.nada.kth.se> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: > [quoting me] (And it IS a chunk of change, too...) > >No it's not. I did the switch in 45 minutes. I meant the kind of change you find in your pocket, that you can trade for food, clothing, shelter OR a copy of MPW; seldom both :-). -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
d88-jwa@byse.nada.kth.se (Jon W{tte) (06/13/91)
> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: > [quoting me] (And it IS a chunk of change, too...) >No it's not. I did the switch in 45 minutes. dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: I meant the kind of change you find in your pocket, that you can trade for food, clothing, shelter OR a copy of MPW; seldom both :-). Just goes to show how international the net is and how strange english idioms are. Or that I make $1332/hour. Take your pick. (I know which one I'd choose :-) -- Jon W{tte h+@nada.kth.se - Speed !
schorsch@oxy.edu (Brent William Schorsch) (06/14/91)
I heard (read: vicious rumor) at the QuickTime rollout that Think C v 5.0 is in beta... Heard also it will have some kind of optimization as well as (somehow) allow you to use any text editor you want. And of course it is to be 7.0 compatible... Ando