ZDoom

Discussion about ZDoom
https://forum.zdoom.org/

Crash Catcher improvements

https://forum.zdoom.org/viewtopic.php?t=28055

Page 1 of 2

Crash Catcher improvements

Posted: Thu Dec 16, 2010 3:29 am
by Chris
This patch attempts to improve the crash handler used by non-Windows builds. It removes code that's been unused for years (don't think it's ever been enabled, honestly), will do a backtrace on all running threads, it no longer attempts to re-trigger the signal, and should more reliably kill the process. As a consequence, the backtrace will also trace inside the signal handler, but it leaves a simple "<signal handler called>" marker to find where the signal was raised.

Re: Crash Catcher improvements

Posted: Thu Dec 16, 2010 3:42 am
by Graf Zahl
I can't apply the patch. TortoiseMerge does not recognize it as valid.

Re: Crash Catcher improvements

Posted: Thu Dec 16, 2010 3:55 am
by Chris
Hmm, odd. Normal "patch" is able to apply it. What about this one?

Re: Crash Catcher improvements

Posted: Mon Dec 20, 2010 4:53 pm
by Aroenai
Chris, what command are you using to make your patches, "svn diff > ~/Desktop/patch.diff" or something else? Your patches don't have revision numbers and that's why tortoisemerge doesn't like them.

Re: Crash Catcher improvements

Posted: Mon Dec 20, 2010 6:14 pm
by Chris
I'm actually using git-svn (allows using Git to interface with an SVN repo). The patch is generated by git-diff, which creates a patch that the normal 'patch' command understands just fine.

Re: Crash Catcher improvements

Posted: Tue Dec 21, 2010 1:51 am
by Graf Zahl
The normal patch command doesn't try to merge with SVN's versioning history.

But since I have had multiple problems with git-svn's patches I'll define a new rule now: If you want to submit patches, make sure they are made with an SVN compatible tool. If not, the submission will be closed.

Re: Crash Catcher improvements

Posted: Tue Dec 21, 2010 8:05 am
by Chris
Here's one made with pure SVN..

Re: Crash Catcher improvements

Posted: Tue Dec 21, 2010 8:15 am
by Graf Zahl
added

Re: Crash Catcher improvements

Posted: Wed Dec 29, 2010 11:03 am
by Hirogen2
Aroenai wrote:Chris, what command are you using to make your patches, "svn diff > ~/Desktop/patch.diff" or something else? Your patches don't have revision numbers and that's why tortoisemerge doesn't like them.
Don't know what's more lame - tortoise rejecting standard patches (without fancy numbers) or maintainers requiring the use of such limiting tools.

Re: Crash Catcher improvements

Posted: Wed Dec 29, 2010 11:08 am
by Gez
Maybe people whining about it.


No, definitely people whining about it.

Re: Crash Catcher improvements

Posted: Wed Dec 29, 2010 11:27 am
by Graf Zahl
I'd say people who think they don't have to adhere to certain rules and THEN whine about it.

This is not your project so if you want to contribute you'll at least have to do it in a way the devs can use.

Re: Crash Catcher improvements

Posted: Wed Dec 29, 2010 1:40 pm
by NeuralStunner
Gez wrote:Maybe people whining about it.
Gez, elsewhere, wrote:You're free to whine to the authors, and the authors are free to whine at you. It's a whine/whine situation!
:P

Re: Crash Catcher improvements

Posted: Thu Dec 30, 2010 7:58 am
by Edward-san
There's something wrong:
look at this example: Doom Tower Defense (here is the topic)

to make zdoom (debug mode compiled with Ubuntu 10.10) crash, do this command:

Code: Select all

./zdoom -iwad doom2.wad -file dtd_2.0.pk3 -skill 1 +map DTD41
wait for the "you have completed the tutorial" print, then it crashes, but the output looks like this:

Code: Select all

*** Fatal Error ***
Address not mapped to object (signal 11)

Generating zdoom-crash.log and killing process 7212, please wait... Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
gdb-respfile-MPuFmV:9: Error in sourced command file:
The program has no registers now.
Killed
then it opens a "xmessage" window with this text:
Spoiler:
when I load-crash the game with root priviledges, like this:

Code: Select all

sudo ./zdoom -config /home/edward-san/.zdoom/zdoom.ini -iwad doom2.wad -file dtd_2.0.pk3 -skill 1 +map DTD41
it appears this output:

Code: Select all

*** Fatal Error ***
Address not mapped to object (signal 11)

Generating zdoom-crash.log and killing process 7705, please wait... 

warning: not using untrusted file "/home/edward-san/.gdbinit"
gdb-respfile-VuVT59:15: Error in sourced command file:
Argument to arithmetic operation not a number or boolean.
Killed
then the same window with this text:
Spoiler:
but if I use gdb, instead:
Spoiler:
so it seems like it's useless using ./zdoom to do debugging ... or did I do something wrong? (Or should it be posted in a new thread at Bugs forum?)

Re: Crash Catcher improvements

Posted: Thu Dec 30, 2010 6:48 pm
by Demolisher
WELL FUCK, I tried to fix this for hours, this is not a bug on the mod's side.

Re: Crash Catcher improvements

Posted: Thu Dec 30, 2010 8:41 pm
by Chris
Edward-san wrote:There's something wrong:
look at this example: Doom Tower Defense (here is the topic)

to make zdoom (debug mode compiled with Ubuntu 10.10) crash, do this command:

Code: Select all

./zdoom -iwad doom2.wad -file dtd_2.0.pk3 -skill 1 +map DTD41
There's definitely something odd about that crash. For me, the spawned process is crashing before it gets a chance to kill ZDoom. Seems to be related to audio.. probably something with PulseAudio. But if I disable audio, it "crashes" properly and gives me a full backtrace (which, btw, is:
Spoiler:
so it seems like it's useless using ./zdoom to do debugging
We're kinda stuck with using ./zdoom to dump the crash info, though. Might be able to get away with invoking another program instead of working directly off of fork(), though that would need changes to ZDoom's main() to watch for a special switch to handle everything (the crash handler would, in essence, invoke another run of ZDoom, but with a special switch that doesn't run the game and instead prints the crash info to stdout).. but I'm not sure how I feel about that. It would be safer since the app can be in a pretty bad state by the time a crash happens, but it would still require doing some work in the forked process (to get some info on the current game state) and passing that to the new ZDoom process for it to print out.
All times are UTC-06:00
Page 1 of 2

Powered by phpBB® Forum Software © phpBB Limited