jerry@altos86.Altos.COM (Jerry Gardner) (02/01/91)
I'm having a strange problem with Turbo C++ Professional that I can't
explain. Perhaps someone else has seen this problem and knows the
cause and a solution.
I have a large application (~25,000 lines of ANSI C (no C++ constructs))
that will compile fine from the hard disk. When I create a 2MB RAM disk
in extended memory (33 MHz 386 with 4MB RAM) using VDISK and attempt to
compile the same source on the RAM disk, the compiler will hang about
halfway through the compilation. There is plenty of room on the RAM
disk for the object files, and the compiler is swapping to the hard
disk. It always hangs at exactly the same place in the source and the
machine can be rebooted using <Ctrl><Alt>-Del. I'm using the TCC++
integrated environment (1.0), MS-Dos 3.3, and no TSR's.
--
Jerry Gardner, NJ6A Altos Computer Systems
UUCP: {sun|pyramid|sco|amdahl|uunet}!altos!jerry 2641 Orchard Parkway
Internet: jerry@altos.com San Jose, CA 95134
Guns don't kill people, bullets do. (408) 432-6200jdb@reef.cis.ufl.edu (Brian K. W. Hook) (02/01/91)
In article <4662@altos86.Altos.COM> jerry@altos86.Altos.COM (Jerry Gardner) writes: > >halfway through the compilation. There is plenty of room on the RAM >disk for the object files, and the compiler is swapping to the hard >disk. It always hangs at exactly the same place in the source and the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I was having a major problem with this using TC 1.00. It seemed that the .PRJ file was becoming corrupted over time and that this would in effect cause it to lock up in the same location over and over. You did not state whether you could compile without the ram disk, whether you had the -Qx (Options--extended memory on) option in use, or whether you were using TC or TCC. Are you using MAKE? A .BAT file? This information would be helpful. Anyway, if you are using a .PRJ file and it locks all the time, delete your .PRJ file and rebuild it. Then do a complete rebuild of all your source. That should work, IF it is your problem. Brian
grimlok@hubcap.clemson.edu (Mike Percy) (02/02/91)
In article <4662@altos86.Altos.COM> jerry@altos86.Altos.COM (Jerry Gardner) writes:
[TC++ locking up using VDISK]
I had similar problems. My problem had to do with how TC++ compiles
function-at-a-time in memory. I had some long functions (generated by
compiler-compiler tool), that compiled fine until I started using more
BUFFERS= and FILES= in my CONFIG.SYS. Seems these buffers took up just
enough room to make it impossible for TC++ to compile the large
functions entirely in memory (TC++ does not write out object code until
the whole function is compiled, and does not swap its data to disk), and
it would hang with garbled messages, required a reboot.
Perhaps you have functions approaching the useful limit. Adding VDISK
(which does take up some room in the 640K) pushes the limit down, and
now things don't work. The best thing to in this case is to get as much
of the 640K for use as possible -- load things into high memory if you
can, balance the need for TSR's against doing useful work, etc.
"I don't know about your brain, but mine is really...bossy."
Mike Percy grimlok@hubcap.clemson.edu
ISD, Clemson University mspercy@clemson.BITNET
(803)656-3780 mspercy@clemson.clemson.edujerry@altos86.Altos.COM (Jerry Gardner) (02/02/91)
In article <26608@uflorida.cis.ufl.EDU> jdb@reef.cis.ufl.edu (Brian K. W. Hook) writes: >In article <4662@altos86.Altos.COM> jerry@altos86.Altos.COM (Jerry Gardner) writes: }>halfway through the compilation. There is plenty of room on the RAM }>disk for the object files, and the compiler is swapping to the hard }>disk. It always hangs at exactly the same place in the source and the } ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } }I was having a major problem with this using TC 1.00. It seemed that }the .PRJ file was becoming corrupted over time and that this would in }effect cause it to lock up in the same location over and over. You }did not state whether you could compile without the ram disk, whether }you had the -Qx (Options--extended memory on) option in use, or whether }you were using TC or TCC. Are you using MAKE? A .BAT file? This }information would be helpful. It compiles fine when I do the compilation on the hard disk. I'm using the integrated environment, not the command line version. I am not using make or a .BAT file. I don't think I have the -Qx option on (I thought this applied to the command line version only). }Anyway, if you are using a .PRJ file and it locks all the time, delete }your .PRJ file and rebuild it. Then do a complete rebuild of all your }source. That should work, IF it is your problem. It compiles fine when I do it on the hard disk. It only hangs when I try to compile from a RAM disk. -- Jerry Gardner, NJ6A Altos Computer Systems UUCP: {sun|pyramid|sco|amdahl|uunet}!altos!jerry 2641 Orchard Parkway Internet: jerry@altos.com San Jose, CA 95134 Guns don't kill people, bullets do. (408) 432-6200
jerry@gumby.Altos.COM (Jerry Gardner) (02/07/91)
In article <12879@hubcap.clemson.edu> grimlok@hubcap.clemson.edu (Mike Percy) writes: }In article <4662@altos86.Altos.COM> jerry@altos86.Altos.COM (Jerry Gardner) writes: } }[TC++ locking up using VDISK] } }I had similar problems. My problem had to do with how TC++ compiles }function-at-a-time in memory. I had some long functions (generated by }compiler-compiler tool), that compiled fine until I started using more }BUFFERS= and FILES= in my CONFIG.SYS. Seems these buffers took up just }enough room to make it impossible for TC++ to compile the large }functions entirely in memory (TC++ does not write out object code until }the whole function is compiled, and does not swap its data to disk), and }it would hang with garbled messages, required a reboot. Further clarification: I don't have long functions (poor programming practice...) and I have 580KB free after loading DOS. }Perhaps you have functions approaching the useful limit. Adding VDISK }(which does take up some room in the 640K) pushes the limit down, and }now things don't work. The best thing to in this case is to get as much }of the 640K for use as possible -- load things into high memory if you }can, balance the need for TSR's against doing useful work, etc. As I said, I have no long functions. The program compiles fine from hard disk (VDISK is installed in this case, just not used). As I said in the initial post, I have no TSRs whatsoever.