OpenXcom Forum
Modding => Help => Topic started by: Nord on October 05, 2017, 10:25:52 am
-
Hello.
I has modded the game enough to get constant crashes because of "segmentation fault". :)
Please, recommend me a way to trace this bugs on my own, because post all of them here will be annoying.
I understand a little in programming, e.t.c., so do not try to simplify it. ;)
Gratefully thanks.
-
Well, the easiest way is to download and compile the source code and use the debugging feature of your favourite IDE.
-
Oh. Thanks.
Now i need only to find an unused PC somewhere here... :)
-
well, i know 0 programming but i´m also having segmentation fault, only at the end of the missions when i complete then , and both are custom maps and missions for the 40k mod, can someone point a light i can give the 2 save´s, but seems that the problem is the same , also only occur in new modded missions/maps and when i end mission (abort also crash)
-
If crash is 100% reproduce then you need post save and your mod data (if it not published yet) and then someone (could be me :>) could run in debugger to see where it crash
-
If crash is 100% reproduce then you need post save and your mod data (if it not published yet) and then someone (could be me :>) could run in debugger to see where it crash
Thanks Yankes, but Meridian just help me and solved the issue, turns out i created unit´s without the "live" corresponding item´s so at the end of mission crash occur
-
I wish the error message could give some clue as to where the segmentation fault lies, rather than leaving it up to me to guess. I kept making changes to my craft map because it kept having a segmentation fault. Turns out it was the UFO map that was causing it.
-
Problem with segmentation is that it happens when you do not except it, if we could give meaningful information for any possible case then we could easy get ride of this completely in first place.
-
It seems to always refer to a specific file being a size other than the size it expects it to be. Couldn't it just tell which file is the wrong size? Even if it says somewhat useless things like BIGOBS.PCK, it will at least be a step in the right direction. We could probably work from there to get it to say where it was in the code when it encountered a wrong size on BIGOBS.PCK.
-
I second this, in zdoom it tells you when and where it chokes up when its loading.
I dont know how simple it would be to implement but openxcom definitely needs to mention what it was that caused the error that kills it. I mean if you go to fire a weapon and it chokes because the ammo type doesnt exist or something, it should at least say what the offending event was related to ("segmentation default in object heavy laser rifle", etc).
I dont know how this didnt get put in from the start.
-
Go to OpenXcom on GitHub (https://github.com/SupSuper/OpenXcom/), open up something in the src/Battlescape folder, search for things like "something->getRules()." Every time you see that, replace with a block of code like
try
{
something->getRules();
}
catch (...)
{
throw Exception("Could not find ruleset for " + something->getType());
}
end
and repeat over the 300+ files of the project. This is only one possibility for a segfault happening, now guess the other 3 dozen and repeat the same process over again. Graceful error handling doesn't just happen; you really do have to guess where the error is going to happen before it does, or add the handling after some user reports it.
-
Why can't you just tell the system to record what line it was on when it crashed? It may not look very useful to the average modder, and it may be misleading to many, but at least it's info and a programmer may be able to understand it.
-
Why can't you just tell the system to record what line it was on when it crashed? It may not look very useful to the average modder, and it may be misleading to many, but at least it's info and a programmer may be able to understand it.
That's exactly what the thing Meridian suggested does. Normally, compiling optimizes out pretty much everything human-readable in order to speed up execution of the program, but compiling with a debug flag keeps the line number, variable name, file name, etc. information available such that on crash, you can have that information. Doing so can also enormously slow down execution of the program, such that everybody will complain about low FPS. Good, or even just marginally useful, error handling is not an easy thing to just throw in the code, unless you want side effects like massive slowdown.
-
but compiling with a debug flag keeps the line number, variable name, file name, etc. information available such that on crash, you can have that information. Doing so can also enormously slow down execution of the program, such that everybody will complain about low FPS.
That's useful for a debug mode, but I was thinking just offer up the offset flag of the first bad segment. Even with only that information along with the exact mod(s) and OXC version, one could run a compiler to translate the offset into a line and column number.
But it would be neat to also have an option in the menu to run in debug mode, sacrificing run speed and efficiency for improved error reporting.
-
But it would be neat to also have an option in the menu to run in debug mode, sacrificing run speed and efficiency for improved error reporting.
That's not possible... an application can be compiled either in Release mode or in Debug mode... not both.
That's exactly what the thing Meridian suggested does. Normally, compiling optimizes out pretty much everything human-readable in order to speed up execution of the program, but compiling with a debug flag keeps the line number, variable name, file name, etc. information available such that on crash, you can have that information. Doing so can also enormously slow down execution of the program, such that everybody will complain about low FPS. Good, or even just marginally useful, error handling is not an easy thing to just throw in the code, unless you want side effects like massive slowdown.
I'm no C++ expert, but I believe you don't have to compile in Debug mode to get a stack trace.
[04-12-2017_11-54-59] [FATAL] A fatal error has occurred: Item STR_SKYRANGER not found
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom13CrossPlatform10stackTraceEPv+0x1e) [0x824301e]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom13CrossPlatform9crashDumpEPvRKSs+0x444) [0x8243834]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_Z15exceptionLoggerv+0x5f) [0x80f1f1f]
[04-12-2017_11-54-59] [FATAL] /usr/lib/i386-linux-gnu/libstdc++.so.6(+0x70833) [0xb7393833]
[04-12-2017_11-54-59] [FATAL] /usr/lib/i386-linux-gnu/libstdc++.so.6(+0x708ad) [0xb73938ad]
[04-12-2017_11-54-59] [FATAL] /usr/lib/i386-linux-gnu/libstdc++.so.6(__cxa_rethrow+0) [0xb7393b70]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZNK8OpenXcom3Mod7getRuleINS_8RuleItemEEEPT_RKSsS6_RKSt3mapISsS4_St4lessISsESaISt4pairIS5_S4_EEEb+0x16b) [0x84397cb]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZNK8OpenXcom3Mod7getItemERKSsb+0x62) [0x8411232]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom20ManufactureInfoState14initProfitInfoEv+0xcc) [0x812766c]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom20ManufactureInfoState7buildUiEv+0x1668) [0x8129d48]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom20ManufactureInfoStateC2EPNS_4BaseEPNS_15RuleManufactureE+0x3d) [0x812b0ad]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom21ManufactureStartState13btnStartClickEPNS_6ActionE+0x41a) [0x812d50a]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom18InteractiveSurface6handleEPNS_6ActionEPNS_5StateE+0x1a2) [0x8261892]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom5State6handleEPNS_6ActionE+0x7b) [0x83028eb]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(_ZN8OpenXcom4Game3runEv+0x2e8) [0x825c848]
[04-12-2017_11-54-59] [FATAL] /tmp/.mount_OpenXc8hpJ9e/usr/bin/openxcom(main+0x165) [0x80dc215]
[04-12-2017_11-55-05] [FATAL] OpenXcom has crashed: Item STR_SKYRANGER not found
Extra information has been saved to openxcom.log.
You should be able to get something like this also from Release mode... which already helps a LOT!
I am just using SupSuper's (for Linux), Yankes's (for Windows), darklord42's (for OSX) and sfalexrog's (for Android) build scripts/methods and for some reason, they don't generate such output (at least the one for Windows doesn't, I didn't check the rest really)... but I've seen stack traces in reports from people who compile themselves (like the one above) so it must be somehow possible.
As I said in the beginning, I am no C++ expert, I don't know how to configure this... but if anyone can help... I'll be happy to merge the change into OXCE+ repo(s).
-
My version do not print stack race because is compiled by GCC and stack trace print is handled by Windows that use bit different mechanism.
I read that is possible to configure GCC to output code that could be stack track by windows but I never have time to do it.
If compiled by VS then showing stack track will be easy, because MS can handle it own stuff.
-
That's not possible... an application can be compiled either in Release mode or in Debug mode... not both.
Easy, if you select a different option in the menu, when you exit the menu it will restart and recompile the game. It would be similar to changing mods, except it might take longer.
-
...when you exit the menu it will restart and recompile the game...
That doesn't even make sense. Just believe me, it's really not possible.
-
Easy, if you select a different option in the menu, when you exit the menu it will restart and recompile the game. It would be similar to changing mods, except it might take longer.
First off, compiling takes extra software (a compiler!) and the libraries necessary to run the code. Then, recompiling from scratch can take 10-30 minutes, depending on your computer. Then you need a debugger to work in concert with the debug exe. Easier to just make your own debug exe and run it yourself when you crash.
Thanks for the correction Meridian and Yankes, perhaps we need to improve the backtrace for all systems - it's never been useful to me.
-
As I said in the beginning, I am no C++ expert, I don't know how to configure this... but if anyone can help... I'll be happy to merge the change into OXCE+ repo(s).
As Yankes mentioned, it depends on how you compile it. Producing stack traces in C++ is a very difficult platform-specific affair and I worked really hard to get it to work (https://github.com/SupSuper/OpenXcom/blob/master/src/Engine/CrossPlatform.cpp#L904). If you use GCC/Clang with debug info, or Visual Studio with PDB, then the executable can generate stack traces. Other platforms like Android would require their own code.
Sadly, most people use the nightly builds which are compiled with MinGW, which can't produce stack traces due to Windows/Linux debug format differences. The only solutions involve bulky third-party libraries that I didn't wanna deal with.