If a property of CPlayer.ReadyWeapon is checked when there is no ReadyWeapon, a Very Fatal Error occurs instead of a VM abort.
In the attached example, simply remove all weapons via, for instance, console "take weapons"
Very Fatal Error checking ReadyWeapon property
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Ed the Bat
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
- Contact:
Very Fatal Error checking ReadyWeapon property
- Attachments
-
readyweapon.pk3- (552 Bytes) Downloaded 33 times
- Graf Zahl
- Lead GZDoom+Raze Developer

- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Very Fatal Error checking ReadyWeapon property
This falls through the cracks when calling an intrinsic function through a null pointer. The only way to guard this would be to add additional instructions to the VM code which I'd prefer not to do.
Re: Very Fatal Error checking ReadyWeapon property
There is a dedicated CLSS instruction which doesn't have any guards against null pointer dereference. Was it a performance reason to avoid such check? The same applies to META instruction I guess.
- Graf Zahl
- Lead GZDoom+Raze Developer

- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Very Fatal Error checking ReadyWeapon property
No. I guess adding a NULL check for those would be ok. Natively that's 2 machine instructions, but when doing it in script code it really gets expensive.
That said, I think something needs to be done about 'bound' instructions for dynamic arrays. That's way too inefficient right now. Maybe dedicated array access instructions that do all the multiplication and checking as part of a single instruction? Only problem: It'd require approx. 20 opcodes but it's something that could really count as currently such an access can end up 8 VM instructions.
That said, I think something needs to be done about 'bound' instructions for dynamic arrays. That's way too inefficient right now. Maybe dedicated array access instructions that do all the multiplication and checking as part of a single instruction? Only problem: It'd require approx. 20 opcodes but it's something that could really count as currently such an access can end up 8 VM instructions.
Re: Very Fatal Error checking ReadyWeapon property
Crash fixed in 62bac1d.
As for dynamic arrays, I'm not quite sure what inefficiency you mentioned. I see no bound checking there, in Insert() and Delete() functions in particular.
As for dynamic arrays, I'm not quite sure what inefficiency you mentioned. I see no bound checking there, in Insert() and Delete() functions in particular.
- Graf Zahl
- Lead GZDoom+Raze Developer

- Posts: 49252
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Very Fatal Error checking ReadyWeapon property
I mean in the VM. Have you ever checked the code that gets generated for a [] access to a dynamic array?
Also: Careful with VM code! What you did there whacked the optimizer quite well. Have you ever wondered why the VM is written this strangely? It's all to help out the optimizer. Your GetClass() function will never get inlined.
Also: Careful with VM code! What you did there whacked the optimizer quite well. Have you ever wondered why the VM is written this strangely? It's all to help out the optimizer. Your GetClass() function will never get inlined.