• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 55 subscribers
  • Views 2872 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler: Occasional error finding temporary files

Matthew Waddell
Intellectual 255 points


Tool/software: TI C/C++ Compiler

Hi,

Occasionally, we see compilation failures that appear to be due to inaccessible or missing temporary files ("Error!: [E1000] Cannot open source file").  Our build (on Windows) is configured to run in parallel, so there may be numerous instances of cl6x all running at any given time.  We have been observing this for a while (with at least two variants of the 7.3.x compiler), and have noted that it does not correlate to low disk space on the host machine.  I am wondering if this is possibly related to contention over the temporary directory, between the various instances of cl6x, resulting in an occasional race condition where by one or more instances of cl6x effectively try to use the same temporary file.  What mechanism does the compiler use to allocate a temporary file?  Is it known to be atomic?  Are there other things that might cause this behavior?

Here is a sample error:

C:\ti\ccsv5\tools\compiler\c6000_7.3.15\bin\cl6x.exe -pden -mv6400+ --abi=coffabi -mi10000 -qq -o3 -s -mw -eo=.obj -fr="C:\path\to\obj\dir" C:\path\to\file.cpp

"C:\BuildAgent\temp\buildTmp\3841612", ERROR! : [E1000] Cannot open source file
C:\BuildAgent\temp\buildTmp\3841612:
No such file or
directory

Thanks,

-Matthew

  • 0
    TI__Guru* 84285 points
    Briefly, the compiler uses _tempnam with a prefix equal to the lowest 5 decimal digits of the pid (I'll skip the rationale for now, as I am not the expert on this topic). It seems to me that this should suffice unless you are running an amazing number of compiler invocations in parallel; just how many might you have going? I don't know offhand of any other mechanisms that might be causing this problem.
  • 0 in reply to Archaeologist
    TI__Guru* 84285 points
    Also, is this a local drive or a network drive? Do you have more than one machine writing to the directory?
  • 0 in reply to Archaeologist
    Intellectual 255 points

    Thanks for the information. Compilation is done on a local drive, which is not accessible via a network share.

    Our build system uses a version of gmake which does not allow you to specify the number of processes that are spawned, so at certain points during our build, there may be several hundred instances of cl6x at some phase of compilation. (Not ideal). It's a very interesting hint that only the lowest 5 digits of the pid end up being used, which could conceivably lead to two instances sharing the same temporary file prefix. The host machine is windows 7, which will recycle pids from time to time, so it stands to chance that there could be two instances with pids like 154423, and 54423. My understanding of _tempnam is that it will append a monotonically incrementing number after the prefix (a sequence which begins anew for each process).

    George privately suggested a test, capturing a log with extended debugging information to try and catch it in the act.

    Thanks again!

  • 0 in reply to Matthew Waddell
    Intellectual 255 points

    I've managed to capture a log containing more detailed information about the issue (containing information about the various temp files at play for each compilation step).  The log shows two compilations, overlapping in time, that both share the same temporary file name.  Though this log does not explicitly show it, based on your description of how temporary file names are generated, I am surmising that the two compilations had a PID which shared their lower 5 digits.

    I'd really like to file a bug report about this, and have the full PID used as the temporary filename prefix.  Even though we may have an atypically high number of parallel processes, it stands to reason that this, or other potentially worse and less obvious issues could occasionally arise when performing parallel builds.

    Thanks you, guys for your input.

    -Matt

  • 0 in reply to Matthew Waddell
    TI__Guru**** 251180 points

    I filed CODEGEN-2098 in the SDOWP system to have this situation investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 255 points
    Thank you! When the ticket becomes public, I will keep an eye on it.

    Cheers,
    -Matt
  • 0 in reply to Matthew Waddell
    Intellectual 255 points

    The ticket has been marked as fixed, with the following targets:

    ARM_15.12.5.LTS, C2000_15.12.5.LTS, MSP430_15.12.5.LTS, PRU_2.1.5, C6000_8.1.4, C2000_17.6.0.STS, ARM_17.6.0.STS, MSP430_17.6.0.STS, MSP430_16.9.3.LTS, ARM_16.9.3.LTS, C2000_16.9.3.LTS, C6000_7.4.22