Opened 11 years ago
Last modified 3 years ago
#2086 new defect
Path detection failing on BSDs
Reported by: | Anthony J. Bentley | Owned by: | |
---|---|---|---|
Priority: | Nice to Have | Milestone: | Backlog |
Component: | Core engine | Keywords: | simple |
Cc: | marcel.stieglitz@… | Patch: |
Description (last modified by )
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.
Attachments (2)
Change History (20)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
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
comment:3 by , 11 years ago
Description: | modified (diff) |
---|---|
Keywords: | simple added |
Priority: | Should Have → Nice to Have |
Summary: | Path detection on OpenBSD → Path detection failing |
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.
comment:4 by , 9 years ago
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.
comment:5 by , 9 years ago
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 parsingargv[0]
- The comment on line 85 is useless.
- Make getPathFromProc static, no need for other TUs to even see that function.
comment:6 by , 9 years ago
Cc: | added |
---|---|
Keywords: | review patch added |
Milestone: | Backlog → Alpha 18 |
Summary: | Path detection failing → [PATCH] Path detection failing |
comment:8 by , 9 years ago
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 intobuffer[pos]
where pos is the return value of readlink). Elsestrrchr
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 forstrrchr
does not add anything either.) - Remove braces around single line blocks (See Coding_Conventions).
by , 9 years ago
Attachment: | pathDetection.2.diff added |
---|
comment:9 by , 9 years ago
Sorry i failed to check the overwrite box. Now the pathDetection.2.diff is the relevant patch. I applied your suggested changes.
comment:11 by , 9 years ago
Description: | modified (diff) |
---|---|
Keywords: | review patch removed |
Summary: | [PATCH] Path detection failing → Path detection failing on BSDs |
Thanks for the patch. Please use tabs for indentation as written in the Coding_Conventions.
comment:12 by , 9 years ago
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.
comment:15 by , 9 years ago
Milestone: | Alpha 18 → Backlog |
---|
comment:16 by , 7 years ago
Yesterday I tested a local build svn rev. 19000 on FreeBSD 10.0 with the following setup:
- Placed 0AD in
~/0ad-19000
- Built using the
normal update-workspaces.sh; cd gcc; gmake -j4
sequence - On xterm issued
~$ export PATH=$PATH:~/0ad-19000/binaries/system
- Called
~$ pyrogenesis -mod=bug4355 -mod=public -autostart-ai=scenarios/Demo_4355 -autostart-ai=1:Bot4355 -autostart-ai=2:Bot4355
(see the files from #4355) - 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.
comment:17 by , 3 years ago
Keywords: | simple removed |
---|---|
severity: | → simple |
comment:18 by , 3 years ago
Keywords: | simple added |
---|
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?