Hello friends,
My team has encountered some issues with crashes on our dedicated server, which are affecting our progress.
Lumberyard uses a C++ call backtrace_symbols_fd()
(in CrySystem\SystemInit.cpp
) to safely dump stack trace information to a file in the event of a crash or segmentation fault.
However, this backtrace is lacking information about file and line numbers. This is a blocker for us. How are other teams getting backtrace information on linux server builds?
Notes:
-
I am aware that
_WAF_/settings/platforms/common.clang.json
declares the compile flag-fvisibility=hidden
, which I understand hides symbols in shared objects to avoid conflicts between the declared names in one object and another. Disabling this flag causes the game to lock up after loading gems, so that appears to be a bad idea. -
Using
-fvisibility=protected
introduces a number of compile errors whose fixes would be a hassle for us to maintain across updates. -
Use of the
-rdynamic
and-Wl,--export-dynamic
flags have not helped. -
The linked
libunwind
library is only applicable for Android devices. -
Prior to 1.22, the file
waf-1.7.13/lmbrwaflib/compile_settings_linux.py
contained a task to separate out the debug symbols into separate files:def run(self):
exec_abs_path = self.inputs[0].abspath()
os.system(‘objcopy --only-keep-debug {0} {0}.debug’.format(exec_abs_path))
os.system(‘objcopy --strip-debug {0}’.format(exec_abs_path))
os.system(‘objcopy --add-gnu-debuglink={0}.debug {0}’.format(exec_abs_path))
return False
This approach of separate symbol files (much like Visual Studio’s .pdb
s) worked for us in the past, and I have written a python script to reintroduce that behaviour. This also does not work.
We’ve done about as much homework on this as we can by ourselves. What am I missing?
Thanks,
Softmints