bobc@attctc.Dallas.TX.US (Bob Calbridge) (01/15/90)
Perhaps someone can give me a suggestion on this. I'm writting a fairly large program under Turbo C. So far, with the debugging information in the program, the executable is about 70K. Without the debugging info its closer to 50K. The program allocates some of the heap, potentially up to 100K but for the testing phase it uses about half that. Each of the allocated areas is in the 10K and under range. All of this information is by way of information just in case it has any bearing on the situation. This is the first time I've attempted to use malloc() so it might have some effect on the program. Here is the problem. The program takes information from one file and uses the allocated space to build information which is eventually output to another file. During this process there are several errors that can be generated. If no error is generated the program prints a message to that effect and waits for the user to press any key to return to the menu. If an error occurs the program prints an error message and prints the line where the error was detected. The user is prompted to press any key to return to the menu. This is where the problem comes in. In the case of an error, when the user presses a key the program appropriately returns to the menu and prints it. However, the system usually locks up at this point. Last night when I made some changes to the program that were not related to correcting the problem (I decided to get the rest of the program working before tackling this problem) the symptoms changed. Instead of locking up, the system started to beep and display the menu continuously. The beep is appropriate if there is an invalid input to getch() which is used to get the option for the menu. All functions pass a status back to the calling routine to indicate a success or failure status so I don't suspect any stack problems. Can anyone suggest what might be causing this to happen. I can't understand why it would happen only with errors. I'm just about ready to experiment with another unfamiliar routine, longjmp(), if I can't get rid of this problem. I should mention that I attempt to free all allocated space before returning to the menu. I don't think that it is being done completely since coreleft() keeps reporting increasingly smaller amounts of memory left. Many thanks, Bob -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- = More stupid questions available on request from = - bobc@attctc Your humble servant (real humble) - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
fredex@cg-atla.UUCP (Fred Smith) (01/15/90)
In article <10987@attctc.Dallas.TX.US> bobc@attctc.Dallas.TX.US (Bob Calbridge) writes: > Last night when I made some changes to the program that were not >related to correcting the problem (I decided to get the rest of the program >working before tackling this problem) the symptoms changed. Instead of >locking up, the system started to beep and display the menu continuously. The >beep is appropriate if there is an invalid input to getch() which is used to get >the option for the menu. > >Many thanks, >Bob Just a hunch: Whenever I make an apparently innocuous change in a program, and some weird behavior in another part of the program suddenly changes, I instantly suspect that somewhere I am clobbering memory in some way. I had an instance of that a while back in my MSDOS version of MORE. In this case on (very) rare occasions, apparently at random, some lines would be drawn on the screen in the BOLD attribute which were not supposed to be bold. It turned out, after MUCH digging and head scratching that I was under those same rare circumstances, overwriting a character array by one byte, thereby clobbering another variable which controlled the display attribute. What you describe sounds very much like that sort of occurrence. Those things can be sheer hell to locate. I wish you well! Fred
scott@hpcvca.CV.HP.COM (Scott Linn) (01/17/90)
/ hpcvca:comp.lang.c / fredex@cg-atla.UUCP (Fred Smith) / 5:20 pm Jan 14, 1990 / >Just a hunch: Whenever I make an apparently innocuous change in a >program, and some weird behavior in another part of the program suddenly >changes, I instantly suspect that somewhere I am clobbering memory in >some way. Another reason is that you may be running out of stack space. Whenever I have these kinds of problems, I turn on stack checking during compilation. This is usually the problem that I have. Scott Linn