Adding echo command makes batch execution correct (OS bug maybe?)

[fadimounir]

Adding the echo command made the R2R CI legs in PR #24333 work correctly.

After being able to repro the CI failures locally using the environment from the lab, I added a bunch of echo commands in the test's .cmd file to debug this. I saw some inconsistent output, suggesting the script execution wasn't flowing correctly, and seemed to jump from one place to the other. After adding more echo commands, suddenly it started to work correctly again, and the scripts stdout started to make sense.
Literally, quite impressive.

I was able to narrow this down to just one extra echo command that for some mysterious reason made the cmd execution correct again

[fadimounir]

cc @hoyosjs @jkotas Can someone PTAL?

Can we somehow get #24333 rebased on master once this hack is in?

[hoyosjs]

Sure, if this gets in just ping me after lunch. Nonetheless, this sounds suspicious. This doesn't seem to affect our master branch at all. They all share hosts for tests, so that'd make me think the new SDK doesn't play well with this script.

[fadimounir]

I'm suspecting an OS bug.

The script code is this:

REM CrossGen Script
if defined RunCrossGen ( 
    if defined LargeVersionBubble ( set OptionalArguments=!OptionalArguments! /largeversionbubble)
    set COMPlus_ZapRequire=2
    set COMPlus_ZapRequireList=osthreadid
    if not exist "osthreadid.org" (
        call :TakeLock
        set CrossGenStatus=0
        if not exist "osthreadid.org" (
            mkdir IL
            copy osthreadid.exe IL\osthreadid.exe 
            ren osthreadid.exe osthreadid.org
            echo "%_DebuggerFullPath% %CORE_ROOT%\crossgen.exe" !OptionalArguments! /Platform_Assemblies_Paths %CORE_ROOT%;%cd%\IL;%cd% /in osthreadid.org /out osthreadid.exe
            %_DebuggerFullPath% "%CORE_ROOT%\crossgen.exe" !OptionalArguments! /Platform_Assemblies_Paths %CORE_ROOT%;%cd%\IL;%cd% /in osthreadid.org /out osthreadid.exe
            set CrossGenStatus=!ERRORLEVEL!
        )
        call :ReleaseLock
        IF NOT !CrossGenStatus!==0 (
            ECHO Crossgen failed with exitcode - !CrossGenStatus!
            Exit /b 1
        )
    )
)

The effect I saw after adding some echo debugging is that right until the “call :TakeLock”, things were fine. Suddenly, the cmd execution jumps to test execution somewhere towards the end of the cmd script (doesn’t even execute the TakeLock logic), then jumps back to that mkdir command, but with a different working dir at that point.

[jkotas]

Can we somehow get #24333 rebased on master once this hack is in?

You can just append the commit with this hack to the Arcade update PR. It is not necessary to commit it to master to just to try it out.

[fadimounir]

You can just append the commit with this hack to the Arcade update PR. It is not necessary to commit it to master to just to try it out.

I don't know how to do that. @hoyosjs do you know how to do that?

[jkotas]

I have done it for. Here are the git commands that I have run to do it:

git fetch upstream
git checkout darc-master-145055cf-390b-45fd-8ad8-3585b3dfc291
git cherry-pick <SHA of your commit>
git push upstream darc-master-145055cf-390b-45fd-8ad8-3585b3dfc291