Path detection failing on BSDs

[Anthony J. Bentley]

Calling pyrogenesis (instead of some path (be it relative or absolute) without being in the right dir) fails with the following error on Linux and BSD.

$ pyrogenesis
ERROR: Cannot find executable (expected at '/home/anthony/pyrogenesis')
Paths.cpp(176): Function call failed: return value was -110301 (No such file or directory)
Function call failed: return value was -110301 (No such file or directory)
Location: Paths.cpp:176 (Root)

Call stack:

(0x1b83f86ed5eb) 0x1b83f86ed5eb <_ZNSt12out_of_rangeD1Ev+342155> at pyrogenesis
(0x1b83f8690c11) 0x1b83f8690c11 <_ZStplIwSt11char_traitsIwESaIwEESbIT_T0_T1_ERKS6_S8_+285153> at pyrogenesis
(0x1b83f86916c2) 0x1b83f86916c2 <_ZStplIwSt11char_traitsIwESaIwEESbIT_T0_T1_ERKS6_S8_+287890> at pyrogenesis
(0x1b83f8691af2) 0x1b83f8691af2 <_ZStplIwSt11char_traitsIwESaIwEESbIT_T0_T1_ERKS6_S8_+288962> at pyrogenesis
(0x1b83f8424c7b) 0x1b83f8424c7b <_ZNSt6vectorImSaImEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPmS1_EEmRKm+240091> at pyrogenesis
(0x1b83f8427af4) 0x1b83f8427af4 <_ZNSt6vectorImSaImEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPmS1_EEmRKm+251988> at pyrogenesis
(0x1b83f840e668) 0x1b83f840e668 <_ZNSt6vectorImSaImEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPmS1_EEmRKm+148424> at pyrogenesis
(0x1b83f8410ce1) 0x1b83f8410ce1 <_ZNSt6vectorImSaImEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPmS1_EEmRKm+158273> at pyrogenesis
(0x1b83f824e8a2) 0x1b83f824e8a2 <__register_frame_info+9666> at pyrogenesis
(0x1b83f824f3b0) 0x1b83f824f3b0 <__register_frame_info+12496> at pyrogenesis
(0x1b83f824c261) 0x1b83f824c261 <+161> at pyrogenesis

errno = 0 (No such file or directory)
OS error = ?


(C)ontinue, (S)uppress, (B)reak, Launch (D)ebugger, or (E)xit?

However, if I'm in the same directory as the executable (e.g., with "cd /usr/local/bin && pyrogenesis"), it works perfectly.

We should get the proper path of the executable if we are started like above (some ways on how to do that for Linux and some BSD variants ​at stackoverflow)

sys_ExecutablePathname() in source/lib/sysdep/os/{linux/linux.cpp,bsd/bsd.cpp}

BSDs might not have procfs available (reusing the code in linux.cpp (move it to unix_executable_path.cpp (see r15996)) might be possible if they do, but we should not rely on that) so using sysctl is the way to go.

[historic_bruno]

Are you using an OpenBSD package of the game? Can you provide the build flags used to build the game or any patches that were applied?

[Anthony J. Bentley]

There is no OpenBSD package of the game. I have been working on one (see ​https://github.com/jasperla/openbsd-wip/tree/master/games/0ad for what I have so far).

Compiled with --without-nvtt --with-system-enet --datadir=${PREFIX}/share/0ad --libdir=${PREFIX}/lib.

Might be related to line 163 of source/ps/GameSetup/Paths.cpp:

OsPath pathname = sys_ExecutablePathname(); // safe, but requires OS-specific implementation

[leper]

There are actually two issues here:

• You should use the 0ad.sh shell script in build/resources/ instead of calling the engine directly.
• The other issue is the code failing to get the path of the executable (sys_ExecutablePathname() in at least source/lib/sysdep/os/{linux/linux.cpp,bsd/bsd.cpp} (see the comment near the end)) which is already bogus in packages which should just use INSTALLED_BINDIR to get the proper path.

[starslayer]

I am a starter and i tried to correct this behavior. I added a diff (pathDetection.diff) to introduce my change. I tried to fullfill the coding conventions.

This works now on my machine.

[leper]

See Coding_Conventions and SubmittingPatches (the part about the review keyword is important).

Some issues:

• You typoed last.
• You should pass length-1 to readlink, else you could hit the case where readlink fills up your buffer and you write \0 after the end of your buffer.
• Just put the implementation before the actual use, no need to put it after it.
• Define endOfPath where you need it.
• Check /proc before trying to solve the issue with parsing argv[0]
• The comment on line 85 is useless.
• Make getPathFromProc static, no need for other TUs to even see that function.

[starslayer]

Patch for linux.cpp

[starslayer]

I changed the things you mentioned. Have I unterstood it correctly?

[leper]

It's better (should be fine after the following changes)

Some more issues:

• getPathFromProc should return a bool (you do not use the size)
• You should \0-terminate buffer (write it into buffer[pos] where pos is the return value of readlink). Else strrchr will read until it finds a null-byte on the stack.
• The comment you removed was not the one I meant. (Remove "Ask /proc/self/exe where we are" as that is obvious from the code, the one for strrchr does not add anything either.)
• Remove braces around single line blocks (See Coding_Conventions).

[starslayer]

Sorry i failed to check the overwrite box. Now the pathDetection.2.diff is the relevant patch. I applied your suggested changes.

[leper]

In 15996:

Query /proc for the executable path on Linux. Patch by starslayer. Refs #2086.

Factor out unix_ExecutablePathname() which is used by BSDs and Linux (as a fallback).

[leper]

Thanks for the patch. Please use tabs for indentation as written in the Coding_Conventions.

[Teiresias]

As in 15996, there seems to be a typo in BSD.cpp:

"#include "lib/sysdep/os/unix/unix_excecutable_pathname.h"

It's easily overlooked (i found it when compiling revision 16000 on a BSD machine): "ex>c<ecu..." instead of "execu...". I have not created a separate ticket as this one still seems to be in progress. I can provide a diff/patch if desired.

[leper]

In 16018:

Fix typo in include. Refs #2086.

[leper]

Thanks for reporting!

[Teiresias]

Yesterday I tested a local build svn rev. 19000 on FreeBSD 10.0 with the following setup:

1. Placed 0AD in ~/0ad-19000
2. Built using the normal update-workspaces.sh; cd gcc; gmake -j4 sequence
3. On xterm issued ~$ export PATH=$PATH:~/0ad-19000/binaries/system
4. Called ~$ pyrogenesis -mod=bug4355 -mod=public -autostart-ai=scenarios/Demo_4355 -autostart-ai=1:Bot4355 -autostart-ai=2:Bot4355 (see the files from #4355)
5. 0AD started and behaved normally (test game ran without any suspicious warnings/console output). No crash output was visible on xterm after it terminated.

Since FreeBSD is now at version 11.0, the situation may be different on more up-to-date platforms, but it might be worth to test whether the problem still exists at all.