[comp.lang.c] C program won't run by itself

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