I want to be able to run MSBuild to get an executable, then run that to check if it crashes for some reason.
Currently, what I’m doing is just
language: cpp
scripts:
- MSBuild.exe MySol.sln [FLAGS]
- START /WAIT Bin/Executable.exe
It refuses to return an error despite crashing on my local build.
I’ve even tried using ofstream to generate a file, append a file, replace a file.
I’ve also tried try catch, return error 1, exit 1.
I’ve also tried using || travis_terminate 1, which I’ve realised is deprecated. I’ve also tried exit 1. Also tried || bash -c "exit 1;"
All those failed to work. I’m convinced that it didn’t run at all. Can anybody advice how do I get an executable from compiling a VS2017 project to work?
I’ve only managed to use g++ to just return 0 and 1 for testing. It’s working fine. But for some reason running my executable using VS Project, seem to not start at all.
Can anybody advice? Thanks in advanced!
It’s not clear from your explanation what exactly you’re getting and what you are expecting. Could you clarify and/or provide a link to the build?
If the Critical Error dialog is disabled in Windows (either globally or via SetErrorMode), a crashing program will simply return a non-zero exit code.
From what I can currently see, this is exactly what is happening for you.
As a side note, running just bin/executable.exe should be sufficient since Travis build is run with Git Bash which does wait for a command to complete.
Hi,
Sorry for not being clear.
Basically, I want to be able to build my C++ Win32 Visual Studio 2017 project (which I’ve done with MSBuild.exe, it’s working as intended, no problem here), then running that built executable, telling me if there’s any error upon running.
I’m however unable to detect any error generated from that executable after MSBuild-ing the project. It’s as if the executable wasn’t running in the first place.
Here’s the output and config file. I’m unable to provide a link since my group’s project is private. I’ve truncated some data in that file (mostly just file names that may be sensitive data to my group.
I know it’s not working because I’ve purposely put crash-able code right before my program ends. (*(int *)0 = 0;) and my app should crash, giving me an error code instead of 0 for a clean run. Additionally, if it’s successfully ran, my bin folder would have another two extra files generated.
Hope this is clearer.
If the Critical Error dialog is disabled in Windows (either globally or via SetErrorMode ), a crashing program will simply return a non-zero exit code.
Hmmm. But all I got was zero exit code. No other error codes provided. No matter whether i’ve purposefully crashed the program, or let it run normally, it’s always error code 0.
As a side note, running just bin/executable.exe should be sufficient since Travis build is run with Git Bash which does wait for a command to complete.
I’ve tried and this is what i got back. The command "Bin/Fire_Engine.exe" exited with 127.
The lines
travis_time:start:0836ce91
[0K$ start /WAIT Bin/Fire_Engine.exe
travis_time:end:0836ce91:start=1552875531981682700,finish=1552875532223614900,duration=241932200
[0K[32;1mThe command “start /WAIT Bin/Fire_Engine.exe” exited with 0.[0m
indeed suggest that the program is never run: timestamps are in nanoseconds, so it took 0,25s.
According to Client Management Suite - Symantec Enterprise , exit code 127 means “procedure not found” (those are just the corresponding Windows error codes but my practice shows that they, and sometimes NTSTATUS values, are used as process exit codes if the process is terminated by the system).
Which suggests that you have a DLL load problem.
You can trace DLL load with Debugging Tools for Windows as explained at Debugging LoadLibrary Failures | Microsoft Learn . It mentions that the program must be run under debugger to see the trace; ntsd.exe is the command-line debugger. Fusion Log Viewer is supposed to be the diagnostic tool at assembly metadata level but I don’t see a command-line mode for it, so you’ll have to request remote desktop access from Travis or something. Or try ro replicate their system using info from The Windows Build Environment - Travis CI and reproduce the problem locally.
A very possible cause is you’re compiling a debug configuration since Windows SDKs are known to not put debug runtimes on PATH and/or into the GAC.
indeed suggest that the program is never run: timestamps are in nanoseconds, so it took 0,25s.
I need to add, my code actually detects whether the file .testrun is present. If it is, it’ll perform one frame of my app (it’s a game, so one update loop, then proceed to destroy everything that is needed to be destroyed, what not, but that’s sufficient enough for most test cases). Would this information change the prognosis?
I will give the DLL route a try and report back. Thanks for the direction!
After some messing around, I still can’t got it to work. Decided to switch to Jenkins. Works perfectly.