Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Help...cl.exe hangs on big project

Help...cl.exe hangs on big project

Scheduled Pinned Locked Moved C / C++ / MFC
jsonperformancehelpannouncementlearning
6 Posts 4 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    Ron Olson
    wrote on last edited by
    #1

    Hey all- I have a huge project that has dependencies on approximately 18 other projects, all which are configured correctly through the depends section so that I should be able to just hit build and everything compiles (the exe and all associated dlls). Ok, this has been working fine for one version of the project, but I downloaded a new version from a different folder in sourcesafe, and I find that the compiler hangs, and can't be quit, no matter what. It's typically been limited to one of three files, that if I compile seperately, I can get the rest of the project to compile. However, if I do a rebuild all, it'll hit a file and as I said, cl.exe just sits there. I waited an hour, but it never came back. What's worse is that I can't *kill* cl.exe, no matter what. I've tried kill from the Resource Kit, using the -f switch, which reports it killed it, but it's still there in the task list. What's worse is that it prevents NT4(sp6) from rebooting...I have to hit the power button to reset. I've looked in the knowledge base, even on Google, but nothing comes up. The compiler heap (/Zm switch I think) is set to the max...2000, so in theory it's got all the memory it needs. I have plenty of disk space, and the machine has 256 meg of ram, dual processor. This is making development very difficult...any help would be appreciated. Ron

    C M R 3 Replies Last reply
    0
    • R Ron Olson

      Hey all- I have a huge project that has dependencies on approximately 18 other projects, all which are configured correctly through the depends section so that I should be able to just hit build and everything compiles (the exe and all associated dlls). Ok, this has been working fine for one version of the project, but I downloaded a new version from a different folder in sourcesafe, and I find that the compiler hangs, and can't be quit, no matter what. It's typically been limited to one of three files, that if I compile seperately, I can get the rest of the project to compile. However, if I do a rebuild all, it'll hit a file and as I said, cl.exe just sits there. I waited an hour, but it never came back. What's worse is that I can't *kill* cl.exe, no matter what. I've tried kill from the Resource Kit, using the -f switch, which reports it killed it, but it's still there in the task list. What's worse is that it prevents NT4(sp6) from rebooting...I have to hit the power button to reset. I've looked in the knowledge base, even on Google, but nothing comes up. The compiler heap (/Zm switch I think) is set to the max...2000, so in theory it's got all the memory it needs. I have plenty of disk space, and the machine has 256 meg of ram, dual processor. This is making development very difficult...any help would be appreciated. Ron

      C Offline
      C Offline
      Chris Hafey
      wrote on last edited by
      #2

      Yikes, sounds like a real pain in the butt. Here are a few things to try: *) Install latest service pack *) Do a rebuild all *) Double check your include file paths (in the project and in dev studio) *) Change the precompiled header settings for the problem files. (try using automatic first, then none at all) *) Split up the problem files into multiple files *) Replace your hard drive (it could be a hardware problem!) *) Replace your RAM (unless you are using ECC) *) Remove one of your processors (doubt this is the problem, but who knows) Hope this helps. Chris Hafey

      1 Reply Last reply
      0
      • R Ron Olson

        Hey all- I have a huge project that has dependencies on approximately 18 other projects, all which are configured correctly through the depends section so that I should be able to just hit build and everything compiles (the exe and all associated dlls). Ok, this has been working fine for one version of the project, but I downloaded a new version from a different folder in sourcesafe, and I find that the compiler hangs, and can't be quit, no matter what. It's typically been limited to one of three files, that if I compile seperately, I can get the rest of the project to compile. However, if I do a rebuild all, it'll hit a file and as I said, cl.exe just sits there. I waited an hour, but it never came back. What's worse is that I can't *kill* cl.exe, no matter what. I've tried kill from the Resource Kit, using the -f switch, which reports it killed it, but it's still there in the task list. What's worse is that it prevents NT4(sp6) from rebooting...I have to hit the power button to reset. I've looked in the knowledge base, even on Google, but nothing comes up. The compiler heap (/Zm switch I think) is set to the max...2000, so in theory it's got all the memory it needs. I have plenty of disk space, and the machine has 256 meg of ram, dual processor. This is making development very difficult...any help would be appreciated. Ron

        M Offline
        M Offline
        Mike Nordell
        wrote on last edited by
        #3

        What's worse is that I can't *kill* cl.exe, no matter what. Isn't it wonderful? Just what you'd expect from Macroshaft, and here you got it. Bend over and say "Thanks!". Seriously, this is a design decision (IMO a serious error in the NT kernel) that Microsoft apparently don't see as an error. The easiest way you can exhibit it is to create a process (only tested win NT5 - aka W2k) that 1) CreateFile a dummy file 2) Call SetEndOfFile to be at a gig (or five, or whatever is needed to make you disk subsystem use a large amount of time to zero-fill) Now try to kill that process while it's running step 2... Good luck. It's locked from killing since it's now in a locked kernel-call that can take forever to complete...

        C 1 Reply Last reply
        0
        • M Mike Nordell

          What's worse is that I can't *kill* cl.exe, no matter what. Isn't it wonderful? Just what you'd expect from Macroshaft, and here you got it. Bend over and say "Thanks!". Seriously, this is a design decision (IMO a serious error in the NT kernel) that Microsoft apparently don't see as an error. The easiest way you can exhibit it is to create a process (only tested win NT5 - aka W2k) that 1) CreateFile a dummy file 2) Call SetEndOfFile to be at a gig (or five, or whatever is needed to make you disk subsystem use a large amount of time to zero-fill) Now try to kill that process while it's running step 2... Good luck. It's locked from killing since it's now in a locked kernel-call that can take forever to complete...

          C Offline
          C Offline
          Chris Hafey
          wrote on last edited by
          #4

          Hmm, are you sure other operating systems support killing processes that are in kernel mode? If so can you describe the mechanism? It sounds like a terribly difficult problem! Chris Hafey

          M 1 Reply Last reply
          0
          • C Chris Hafey

            Hmm, are you sure other operating systems support killing processes that are in kernel mode? If so can you describe the mechanism? It sounds like a terribly difficult problem! Chris Hafey

            M Offline
            M Offline
            Mike Nordell
            wrote on last edited by
            #5

            No. But on the other hand I'm not aware of any other operating system that has system calls that can take up to several minutes, even hours, to complete - possibly even freezing the system from the users POV. But this shouldn't be a problem, simply a matter of aborting an I/O request. Not exactly rocket science.

            1 Reply Last reply
            0
            • R Ron Olson

              Hey all- I have a huge project that has dependencies on approximately 18 other projects, all which are configured correctly through the depends section so that I should be able to just hit build and everything compiles (the exe and all associated dlls). Ok, this has been working fine for one version of the project, but I downloaded a new version from a different folder in sourcesafe, and I find that the compiler hangs, and can't be quit, no matter what. It's typically been limited to one of three files, that if I compile seperately, I can get the rest of the project to compile. However, if I do a rebuild all, it'll hit a file and as I said, cl.exe just sits there. I waited an hour, but it never came back. What's worse is that I can't *kill* cl.exe, no matter what. I've tried kill from the Resource Kit, using the -f switch, which reports it killed it, but it's still there in the task list. What's worse is that it prevents NT4(sp6) from rebooting...I have to hit the power button to reset. I've looked in the knowledge base, even on Google, but nothing comes up. The compiler heap (/Zm switch I think) is set to the max...2000, so in theory it's got all the memory it needs. I have plenty of disk space, and the machine has 256 meg of ram, dual processor. This is making development very difficult...any help would be appreciated. Ron

              R Offline
              R Offline
              Rassman
              wrote on last edited by
              #6

              Hello Ron. I haven't had this particular problem lately and like you say I can't see it being a resource problem. But, I used to have trouble with an old Windows and to save me going in and out of Windows to run nmake, I split my make file. Then did an Nmake of mafefiles, sort of thing. To get yourself going I would do that very thing again. Though I am a touch worried that you say the problem seems to hinge arround one of three files. I would do a build of those you suspect and at least one before (thinking of the likely order of build) with full warnings switched on , I know you have to plough through junk too with this build, but as you do consider an old type problem, where you used to get a corrupt byte in the source file that confused the compilers. Even notepad is capable of this. Mike. Are you saying that MS have got their cl.exe running at kernal-0 level? I would find that difficult to believe, or maybe your saying that a call it happens to make hi-lights a kernal bug? We do it for the joy of seeing the users struggle.

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups