Enough Segmentation.

[Nord]

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.

[Meridian]

Well, the easiest way is to download and compile the source code and use the debugging feature of your favourite IDE.

[Nord]

Oh. Thanks.
Now i need only to find an unused PC somewhere here...

[bulletdesigner]

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)

[Yankes]

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

[bulletdesigner]

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

[The Reaver of Darkness]

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.

[Yankes]

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.

[The Reaver of Darkness]

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.

[RSSwizard]

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.

[ohartenstein23]

Go to OpenXcom on GitHub, 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

Code: [Select]

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.

[The Reaver of Darkness]

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.

[ohartenstein23]

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.

[The Reaver of Darkness]

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.

[Meridian]

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.

Code: [Select]

[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).