drezac@dcscg1.UUCP (Duane L. Rezac) (07/21/89)
I have run into a problem with a C program that has totaly stumped me (That's not too hard, as I'm still new at C :-) System: Z-248 running Quick-C v.2.0 The Program is using the Bplus indexing routines and PC-Curses . When the program is run under Quick-c, it runs fine. When I try to run it from DOS, It will lock up at the same point each time. No errors show on the compile, and CCheck gives it a clean bill of health. This program is a sorting program, indexing a 400-500k file and comparing it to another 400-500k file, the writing the difference to another file. I suspect that the problem may be caused by a difference in the way quick-c allocates memory for a running program as opposed to DOS, but I'm really not sure. Any Suggestions ? Duane L. Rezac -- +-----------------------+---------------------------------------------------+ | Duane L. Rezac |These views are my own, and NOT representitive of my place| | dsacg1!dcscg1!drezac drezac@dcscg1.dcsc.dla.mil of Employment. | +-----------------------+---------------------------------------------------+
len@elxsi.UUCP (Len Mills) (07/26/89)
In article <538@dcscg1.UUCP> drezac@dcscg1.UUCP (Duane L. Rezac) writes: > When the program is run under Quick-c, it runs fine. When I try to > run it from DOS, It will lock up at the same point each time. No > errors show on the compile, and CCheck gives it a clean bill of > health. > ... Any Suggestions ? I've had this symptom from three types of bugs. The easy bug is a change in environment and the failure to rebuild a production program. If you can run the program under QC, then exit QC, then run the program and get a failure without changing the environment, this isn't the cause. The harder bug is, of course, the wild pointer. Do you have the stack checking option On in QC? You may have to resort to checking the pointers and data structures at run-time in order to track this condition. The last one is related to console I/O; QC will, in some way I have not throughly researched, "protect" the programmer due to its interception of the keyboard vector. I once had an erroneous getch() following a screen write. Of course, QC switched screens on the write, and, since I had some breakpoints set, I was using the function keys to continue execution. After a little while, I noticed that I was having to hit the key twice (blaming my keyboard getting dirty (:-)), but eventually noticed a pattern, and found my problem. Happy exterminating! > Duane L. Rezac > > >-- >+-----------------------+---------------------------------------------------+ >| Duane L. Rezac |These views are my own, and NOT representitive of my place| >| dsacg1!dcscg1!drezac drezac@dcscg1.dcsc.dla.mil of Employment. | >+-----------------------+---------------------------------------------------+ -- Len Mills ... {uunet,ucbvax!sun,lll-lcc!lll-tis,altos86,bridge2}!elxsi!len