by Hypersonic » Sat Oct 21, 2017 2:19 pm
Are the crashes always logged? Seems that something called DoomSpecificInfo is called on a crash, defined in i_main.cpp
https://github.com/coelckers/gzdoom/blo ... i_main.cpp
int main (int argc, char **argv)
{
#if !defined (__APPLE__)
{
int s[4] = { SIGSEGV, SIGILL, SIGFPE, SIGBUS };
cc_install_handlers(argc, argv, 4, s, GAMENAMELOWERCASE "-crash.log", DoomSpecificInfo);
}
There seems to also be a win32 version of DoomSpecificInfo (though this returns void rather than int, and takes slightly difference parameters)
https://github.com/coelckers/gzdoom/blo ... i_main.cpp
The data currently logged might not help pinpoint the problem, but if it is called it should be possible to add more debugging data to the log which may help track down the problem(s). Maybe enter 'kill monsters' into the console to factor out monster targeting issues.
Are the crashes always logged? Seems that something called DoomSpecificInfo is called on a crash, defined in i_main.cpp
https://github.com/coelckers/gzdoom/blob/master/src/posix/sdl/i_main.cpp
int main (int argc, char **argv)
{
#if !defined (__APPLE__)
{
int s[4] = { SIGSEGV, SIGILL, SIGFPE, SIGBUS };
cc_install_handlers(argc, argv, 4, s, GAMENAMELOWERCASE "-crash.log", DoomSpecificInfo);
}
There seems to also be a win32 version of DoomSpecificInfo (though this returns void rather than int, and takes slightly difference parameters)
https://github.com/coelckers/gzdoom/blob/master/src/win32/i_main.cpp
The data currently logged might not help pinpoint the problem, but if it is called it should be possible to add more debugging data to the log which may help track down the problem(s). Maybe enter 'kill monsters' into the console to factor out monster targeting issues.