Debugging the phoronix-test-suite in Fedora 20: The following tests failed to properly run (TF2)

Caveat:  This is a work in progress, so it’s quite possible that I’m overlooking something stupid.  I basically logged my work as it progressed, and given the length of time I’ve spent on this, I’m probably doing something stupid…

So, as I mentioned earlier, I could not get the TF2 benchmark to operate properly.  Here’s the situation:

The TF2 test fails every time I attempt to launch it, throwing the unhelpful:

The following tests failed to properly run:

– pts/tf2-1.0.1: Resolution: 1600 x 900
– pts/tf2-1.0.1: Resolution: 1920 x 1080

Phoronix Test Suite v5.0.0

Installed: pts/tf2-1.0.1

The test run did not produce a result.
The test run did not produce a result.
The test run did not produce a result.

Test Results:

Average: 0 Frames Per Second
This test failed to run properly.

So I hit the phoronix-test-suite man page and come up with this beaut:

phoronix-test-suite debug-run pts/tf2-1.0.1

Which produces glorious output revealing the error in the command.  The command is attempting to execute a file in my home directory:

Test Run Command: cd /home/REDACTED/.phoronix-test-suite/installed-tests/pts/tf2-1.0.1/ && ./tf2 -w 1920 -h 1080 2>&1

./tf2: line 4: ./hl2_linux: No such file or directory

Now we’re on to something; time to check out that ~/.phoronix-test-suite/installed-tests/pts/tf2-1.0.1/tf2 executable!  With vim, one can easily read it (it’s just a bourne shell script).  It’s pretty short, but of course the line faulting out (4) is gross:

#!/bin/sh
cd $DEBUG_REAL_HOME/.steam/root/SteamApps/common/Team\ Fortress\ 2

LD_LIBRARY_PATH=$DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2/bin:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib:/usr/lib32:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_64:$DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2:$DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2/bin ./hl2_linux -game tf +con_logfile $LOG_FILE +cl_showfps 1 -fullscreen -novid +timedemoquit pts2 $@

From the context, I can infer that the environment variable “$DEBUG_REAL_HOME” points to my home directory.

The LD_LIBRARY_PATH variable is probably used to set the execution path for a shell or application somewhere down the road.  The path is a series of locations in which to search for executable files matching the input provided (for example) to a console.  When you type any commands into the shell, the $PATH variable is consulted for locations (delimited by colons) in which to seek executable files matching the provided input.  We can see that LD_LIBRARY_PATH is constructed as a standard path variable with colons delimiting the locations.

Swapping out the colon delimitation for carriage returns provides a more human-readable list of locations:

• $DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2/bin
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32:
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib
• /usr/lib32
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32
• $DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_64
• $DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2
• $DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2/bin

And then there’s this little stickler at the end:

• ./hl2_linux -game tf +con_logfile $LOG_FILE +cl_showfps 1 -fullscreen -novid +timedemoquit pts2 $@

That text follows a space after the last path value, meaning it is not being assigned to the LD_LIBRARY_PATH variable, but executed after the variable is set to the preceding text.  That’s how sh parses that line.  You can test it out yourself by defining a variable and then inserting a space followed by a simple command:

$ TESTVAR=value
$ TESTVAR=value echo w00t
w00t

So this last section of text (technically still a part of line 4, but the second command written into that line) is likely causing our problem; since the preceding variable declaration is incapable of throwing a file not found error (it’s not referencing any files), we can safely deduce that this command is generating the error.

So what’s the working directory in which this command is being executed (it’s using a relative path – note the period at the start – we need to know the location to which it is relative?  From line 2 of the tf2 script, we know the current working directory is ~/.steam/root/SteamApps/common/Team\ Fortress\ 2, meaning that the path to that hl2_linux file is ~/.steam/root/SteamApps/common/Team\ Fortress\ 2/hl2_linux.  I check to ensure the file being called exists:

$ ll ~/.steam/root/SteamApps/common/Team\ Fortress\ 2/hl2_linux

ls: cannot access /home/REDACTED/.steam/root/SteamApps/common/Team Fortress 2/hl2_linux: No such file or directory

Well there’s your problem right there.  Where is that hl2_linux file?

$ locate hl2_linux
/home/REDACTED/.local/share/steamvr/logs/client_hl2_linux.txt
/opt/steam/SteamApps/common/Left 4 Dead 2/hl2_linux
/opt/steam/SteamApps/common/Team Fortress 2/hl2_linux

Hmm.. this may be a problem in that the phoronix-test-suite is expecting steam games to be installed in their default location (in /home/), but since I’m a big boy and I install my optional software in /opt/ (that’s what it’s for, damn it!), my Team Fortress 2 hl2_linux executable is elsewhere.

So I simply modify the line in the tf2 script to reflect that.  Now my ~/.phoronix-test-suite/installed-tests/pts/tf2-1.0.1/tf2 script has a single difference from the original file in that the last line (bulleted above) is changed to:

• /opt/steam/SteamApps/common/Team\ Fortress\ 2/hl2_linux -game tf +con_logfile $LOG_FILE +cl_showfps 1 -fullscreen -novid +timedemoquit pts2 $@

Unfortunately, this still results in an error:

/opt/steam/SteamApps/common/Team Fortress 2/hl2_linux: error while loading shared libraries: libtcmalloc_minimal.so.4: cannot open shared object file: No such file or directory

I probably should’ve expected this.  Remember that LD_LIBRARY_PATH variable?  Since we’re having trouble loading shared libraries, I’m guessing the path specified again presumes storage in /home/ and not /opt/.  We know the library is located in /opt/:

$ locate libtcmalloc_minimal.so.4
/opt/steam/SteamApps/common/Team Fortress 2/bin/libtcmalloc_minimal.so.4

And we know that’s not referenced in the path.  So, I’ll simply add two paths to content in /opt/ which would otherwise be stored in the home directory:

• /opt/steam/SteamApps/common/Team\ Fortress\ 2
• /opt/steam/SteamApps/common/Team\ Fortress\ 2/bin

Now I try to execute the test and receive the following error:

Test Run Command: cd /home/REDACTED/.phoronix-test-suite/installed-tests/pts/tf2-1.0.1/ && ./tf2 -w 1920 -h 1080 2>&1

Failed to load the launcher

So, let’s break this script down.  The high-level view of the tf2 script is:

1. Require the bourne shell
   1. #!/bin/sh
2. Change the current working directory to /home/REDACTED/.steam/root/SteamApps/common/Team\ Fortress\ 2
   1. cd $DEBUG_REAL_HOME/.steam/root/SteamApps/common/Team\ Fortress\ 2
3. Set the LD_LIBRARY_PATH so that hl2_linux can locate the shared libraries it needs (including our modified library paths we discovered previously in bold)
   1. LD_LIBRARY_PATH=$DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2/bin:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/lib:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib:/usr/lib32:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_32:$DEBUG_REAL_HOME/.local/share/Steam/ubuntu12_64:$DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2:$DEBUG_REAL_HOME/.local/share/Steam/SteamApps/common/Team\ Fortress\ 2/bin:/opt/steam/SteamApps/common/Team\ Fortress\ 2:/opt/steam/SteamApps/common/Team\ Fortress\ 2/bin
4. Execute the hl2_linux script from within the current directory and pass the parameters necessary to get this thing running.  The original line (not the one modified to include an absolute path to the hl2_linux command as listed above) is below:
   1. ./hl2_linux -game tf +con_logfile $LOG_FILE +cl_showfps 1 -fullscreen -novid +timedemoquit pts2 $@

Rather than make that into an absolute path to point to the hl2_linux file in /opt/, the proper thing to do is probably to change the working directory on line 2 (who knows what other dependencies the system may have on the current working directory containing the expected contents).  So, I modify line 2 as seen below:

cd $DEBUG_REAL_HOME/.steam/root/SteamApps/common/Team\ Fortress\ 2

to

cd /opt/steam/SteamApps/common/Team\ Fortress\ 2

Lo and behold, when the “phoronix-test-suite debug-run pts/tf2-1.0.1” command is executed, TF2 actually starts up!  Unfortunately, it loads into the main menu and does nothing further, but a quick look at the developer console yields (with the line catching my eye in bold):

maxplayers set to 24
Error: Material “debug/debugluxels” uses unknown shader “DebugLuxels”
Error: Material “___fillrate_0” uses unknown shader “FillRate”
Error: Material “___debugnormalmap_1” uses unknown shader “DebugNormalMap”
Error: Material “___debugdrawenvmapmask_2” uses unknown shader “DebugDrawEnvmapMask”
Error: Material “___debugdepth_3” uses unknown shader “DebugDepth”
Error: Material “___debugdepth_4” uses unknown shader “DebugDepth”
Steam config directory: /opt/steam/SteamApps/common/Team Fortress 2/platform/config
CClientSteamContext logged on = 0
Cleaning up unneeded replay block data…
Replay cleanup done.
Loading default settings for high sensitivity
JOY_AXIS_X:  mapped to Turn (absolute)
JOY_AXIS_Y:  mapped to Look (absolute)
JOY_AXIS_Z:  unmapped
JOY_AXIS_R:  mapped to Forward (absolute)
JOY_AXIS_U:  mapped to Side (absolute)
JOY_AXIS_V:  unmapped
Advanced Joystick settings initialized
Can’t use cheat cvar cam_snapto in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar cam_ideallag in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar cam_idealdelta in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar cam_idealyaw in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar cam_idealpitch in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar cam_idealdist in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar cam_idealdistright in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar cam_idealdistup in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar cam_collision in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar c_maxpitch in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar c_minpitch in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar c_maxyaw in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar c_minyaw in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar c_maxdistance in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar c_mindistance in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar c_orthowidth in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar c_orthoheight in multiplayer, unless the server has sv_cheats set to 1.
Unknown command “cl_thirdperson”
Unknown command “sv_backspeed”
Not playing a local game.
m_face->glyph->bitmap.width is 0 for ch:32 TF2 Build
CDemoFile::Open: couldn’t open file pts2.dem for reading.
Can’t use cheat cvar fog_start in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar fog_end in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar fog_startskybox in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar fog_endskybox in multiplayer, unless the server has sv_cheats set to 1.
Can’t use cheat cvar r_farz in multiplayer, unless the server has sv_cheats set to 1.

Console initialized.

So it can’t open that pts2.dem file, eh?  Where is it?

$ locate pts2.dem
/home/REDACTED/.local/share/Steam/SteamApps/common/Team Fortress 2/tf/pts2.dem

Well, the question is, how is that file supposed to be found?  I can see a “pts2” argument being passed to the hl2_linux file, but it lacks the .dem portion of the name and the current working directory is not (and never was) sufficient to locate the file on that basis alone. So our mystery is how the following execution locates the pts2.dem file:

./hl2_linux -game tf +con_logfile $LOG_FILE +cl_showfps 1 -fullscreen -novid +timedemoquit pts2 $@

This is as far as I’m going to go with this one for now; if anyone out there has any solutions or has gotten any further, let me know.