Crash Catcher improvements
Moderator: GZDoom Developers
-
Chris
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Crash Catcher improvements
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.
- Attachments
-
cc-patch.zip- (1.9 KiB) Downloaded 50 times
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49229
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Crash Catcher improvements
I can't apply the patch. TortoiseMerge does not recognize it as valid.
-
Chris
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: Crash Catcher improvements
Hmm, odd. Normal "patch" is able to apply it. What about this one?
- Attachments
-
- cc-patch.zip
- (1.86 KiB) Downloaded 52 times
Re: Crash Catcher improvements
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.
-
Chris
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: Crash Catcher improvements
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.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49229
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Crash Catcher improvements
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.
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.
-
Chris
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: Crash Catcher improvements
Here's one made with pure SVN..
- Attachments
-
- cc-patch.zip
- (1.81 KiB) Downloaded 46 times
-
Hirogen2
- Posts: 2033
- Joined: Sat Jul 19, 2003 6:15 am
- Operating System Version (Optional): Tumbleweed x64
- Graphics Processor: Intel with Vulkan/Metal Support
- Location: Central Germany
- Contact:
Re: Crash Catcher improvements
Don't know what's more lame - tortoise rejecting standard patches (without fancy numbers) or maintainers requiring the use of such limiting tools.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.
Re: Crash Catcher improvements
Maybe people whining about it.
No, definitely people whining about it.
No, definitely people whining about it.
-
Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49229
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Crash Catcher improvements
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.
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.
-
NeuralStunner
-
- Posts: 12328
- Joined: Tue Jul 21, 2009 12:04 pm
- Preferred Pronouns: No Preference
- Operating System Version (Optional): Windows 11
- Graphics Processor: nVidia with Vulkan support
- Location: capital N, capital S, no space
- Contact:
Re: Crash Catcher improvements
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!
-
Edward-san
- Posts: 1774
- Joined: Sat Oct 17, 2009 9:40 am
Re: Crash Catcher improvements
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:
wait for the "you have completed the tutorial" print, then it crashes, but the output looks like this:
then it opens a "xmessage" window with this text:
it appears this output:
then the same window with this text:
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 DTD41Code: 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
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 DTD41Code: 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
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?)
-
Demolisher
- Posts: 1749
- Joined: Mon Aug 11, 2008 12:59 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Winchester, VA
- Contact:
Re: Crash Catcher improvements
WELL FUCK, I tried to fix this for hours, this is not a bug on the mod's side.
-
Chris
- Posts: 2971
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: Crash Catcher improvements
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: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
Spoiler:
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.so it seems like it's useless using ./zdoom to do debugging