VC Utilities - cl.exe returns "error 9" with no other output

Author

cl.exe returns "error 9" with no other output

MattG

2006-02-08, 10:12 am

(Is this the right newsgroup for discussion of the C/C++ compiler itself? I
see 10 different vc.* newsgroups, but none that really pertains to the core
compiler.)

My build process invokes cl.exe from make, and every so often, not
reproduceable but a couple times a day, CL will die with no output, returning
exit code 9 to its parent process.

If you invoke the same build again, it works. So the problem isn't
deterministic, at least relative to the source files and CL arguments.

What does exit code 9 mean?
Why is there no error message?
Is there a fix available for this problem?

John Dallman

2006-02-08, 10:12 am

In article <0362622F-2325-446E-898F-4A89D240029E@microsoft.com>,
MattG@discussions.microsoft.com (=?Utf-8?B?TWF0dEc=?=) wrote:

> (Is this the right newsgroup for discussion of the C/C++ compiler
> itself? I see 10 different vc.* newsgroups, but none that really
> pertains to the core compiler.)

It seems to be where we deal with weird interstitial issues, so give it a
try.

> My build process invokes cl.exe from make, and every so often, not
> reproduceable but a couple times a day, CL will die with no output,
> returning exit code 9 to its parent process.

That's interesting. In a decade of being cruel to cl.exe, I've never seen
anything like this. More details are definitely required.

Which version of the compiler? What OS? What command-line options? What
kind of source? C? C++? Precompiled headers? Headers or source produced by
earlier steps in the build? What kind of disk are the files on - local or
network? If network, which kind of server?

> If you invoke the same build again, it works. So the problem isn't
> deterministic, at least relative to the source files and CL arguments.

Umm... That might not be true. You're using nmake here, so if an object
file was produced before the compile went screwy, and hasn't been deleted
before the build is tried again, that exact compile won't be re-attempted.

> What does exit code 9 mean?

I have no idea. I've only ever trusted the compiler to return zero for
success, non-zero for failure.

> Why is there no error message?
> Is there a fix available for this problem?

My first guess would that something is happening that's messing up the
compiler's internal handling of errors. It's normally very good at
catching errors within itself as "Internal Compiler Error". So looking for
places where it trusts binary files - as in precompiled headers - is one
thing to try.

---
John Dallman jgd@cix.co.uk
"C++ - the FORTRAN of the early 21st century."

MattG

2006-02-08, 10:12 am

> That's interesting. In a decade of being cruel to cl.exe, I've never seen
> anything like this. More details are definitely required.

Thanks for the reply. I should have given more info up front, but I'm
especially interested in hearing from the MS internal team what exit code 9
means, and figured they can describe when/where that could happen from
looking at the code without knowing how I got there.

I've actually seen behavior like this from several different versions of
MSVC6, but only this manifestation from VS2003.

> Which version of the compiler? What OS? What command-line options? What
> kind of source? C? C++? Precompiled headers? Headers or source produced by
> earlier steps in the build? What kind of disk are the files on - local or
> network? If network, which kind of server?

This is the compiler from MSVC2003, version 12.00.8804. The OS can be either
XP or 2000. Compiling C code without precompiled headers. Options something
like "-O2 -Oy- -G5".

Source on local disk, headers probably on local disk but I'm not entirely
sure (this happens on multiple different systems and not everybody builds
exactly the same way), and the source isn't produced by earlier build steps.

> Umm... That might not be true. You're using nmake here, so if an object
> file was produced before the compile went screwy, and hasn't been deleted
> before the build is tried again, that exact compile won't be re-attempted.

Actually gnu make, not nmake. And you could be right in general here, but in
this specific case, I know that it's not reusing screwy files from a previous
attempt, and is retrying the same inputs.

>
> My first guess would that something is happening that's messing up the
> compiler's internal handling of errors. It's normally very good at
> catching errors within itself as "Internal Compiler Error".

Yeah, so I claim this is a compiler bug and would like to hear from
Microsoft on what they know about it...

Thanks for your attention.

Sponsored Links