lipa@POLYA.STANFORD.EDU (William Lipa) (04/27/88)
I have a program written in LSP which causes a system error or the "flashing"
empty dialog box when it transfers control back to LSP after finishing. It
appears as though the program is trashing some structure necessary for LSP, but
I can't imagine how it would do this, since the program doesn't do any funny
pointer manipulation and all memory is allocated by standard toolbox calls.
I know there is a great tendency to blame the compiler; I was just wondering
whether there was a known bug in LSP that could cause this behavior.
Reasons I believe it might be LSP, not my code:
1. The program never bombs when it is running as an application.
2. No errors are caught by LSP when it is running in Debug mode.
3. The program never causes neighboring programs to bomb while running in
MultiFinder, so it doesn't seem to be randomly trashing memory.
4. The problem goes away if I use a Mac Plus or if I turn off the color on
my Mac II. My program does not use color.
5. The problem does not go away if I increase the heap and stack size of my
program, so it's not a simple memory error.
System configuration: Mac II, Apple color monitor, System release 5.0, regular
Finder, 16-color mode, 40SC disk, LightSpeed Pascal 1.11.
Even if nobody has ever heard of anything like this, I would be very interested
to see a list of known bugs in LSP since I do a lot of development with it (and
like it!)
Thanks,
Bill Lipa
lipa%polya@forsythe.stanford.edualibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) (04/27/88)
I am sure the Rich knows ore about this than I do, but I ran into some compatibility tests with LSP on a Mac II running in color. Most of them were fixed, and the rememaing few (sounds like you hit one of 'em...) are to be fixed for the next release, which is upposed to bring LSP up to speed with LSC, adding in several of the most-requested features. As for the exact problem, I am not sure, although I know that when LSP acts as a shell to your program, it has to fiddle a lot with the normal operation of things. This causes many difficulties, including some involving color. I am not sure that your problem is related to the use of color, but more to the memory involved. When a II is in color, it uses up a lot of memory, and LSP needs a chunk of its own. LSP gives your program a bunch of memory to use, and this can cause some problems, with regards to memory useage. This is particularly apparent on 1 meg machines. When you switch it to color mode, or build the aplication to run on its own, it gets more free memory, and less problems of this sort will occur. ------------------------------------------------------------------------------- - Alexander M. Rosenberg - INTERNET: alibaba@ucscb.ucsc.edu - Yoyodyne - - Crown College, UCSC - UUCP:...!ucbvax!ucscc!ucscb!alibaba- Propulsion - - Santa Cruz, CA 95064 - BITNET:alibaba%ucscb@ucscc.BITNET - Systems - - (408) 426-8869 - Disclaimer: Nobody is my employer - :-) - - - so nobody cares what I say. - -
rs4u+@andrew.cmu.edu (Richard Siegel) (04/27/88)
I need more information before I can give a definitive answer, such as:
- What does your program do?
- Does Lightspeed Pascal crash on exit every single time you run your
program?
- What system error do you get when it crashes (and the bomb box is
displayed)?
- Are you using any standard procedures (WriteLn to the text window,
for example)?
There is a crasher that occasionally shows up when running in 256-color mode;
when a program exits, at some later point in time, a bus error occurs for no
good reason. It's spurious and hard to track down, but we're getting it.
Also, there have been some remarkable problems (again spurious) that I can't
consistently reproduce, but which seem to be linked to use of the standard
library console i/o and color mode. The standard libraries are being redone for
the next version, so that may go away.
But any more information would be much appreciated. If you have a trivial
program that exhibits this behavior, I'd much appreciate it if you can send me
the source and project files...
--Rich
Rich Siegel
Quality Assurance Technician
THINK Technologies