[0.65] Crash in qswap

This forum is for the Lua scriptable clone of DM/CSB called Dungeon Strikes Back by Sophia. Use DSB to build your own highly customised games.

Moderator: Sophia

Forum rules
Please read the Forum rules and policies before posting.
Post Reply
kaypy
Artisan
Posts: 171
Joined: Sun Jan 19, 2014 7:11 am

[0.65] Crash in qswap

Post by kaypy »

I managed to trigger a segfault from somewhere in my temporary curses code.
logfile wrote: PROGRAM CRASH!
Location: 8 12 26
Reason: Segmentation Fault
Stack Dump:
DSBmain
DSBgameloop
run_timers
deliver_msg(leggings_cursed)
lua.dsb_qswap
luaobjarch
I'll dig around and see if
a) I can reproduce it (preferably in a reliable fashion)...
b) ... in 0.66
Friends don't let friends eat worm round
kaypy
Artisan
Posts: 171
Joined: Sun Jan 19, 2014 7:11 am

Re: [0.66b] Crash in qswap

Post by kaypy »

Ok, with a bit of tweaking around the random number generator, I can semi-reliably reproduce this in a save moved over to 0.66b

http://en.file-upload.net/download-1129 ... p.zip.html

If you stand in front of the gor face for a while, it should zap the party and make some equipment cursed. (If the 0.66b random number issue is fixed, it might alternatively apply a debuff, but if you wait a while it will keep zapping). When the curse wears off, there's some chance of the game crashing.

The process for the curse behaviour is to yank the items to limbo (in order to trigger any removal code), qswap it to the new type, and put it back a frame later.

I have added some logging to the relevent functions in cursed/cursed.lua to try to track what is going wrong. The crash occurs at the uncurse qswap around line 186.
Friends don't let friends eat worm round
User avatar
Sophia
Concise and Honest
Posts: 4239
Joined: Thu Sep 12, 2002 9:50 pm
Location: Nowhere in particular
Contact:

Re: [0.65] Crash in qswap

Post by Sophia »

Yuck. This one is messy. Your code was doing something wrong... or, more properly, something a little too clever for DSB. It was a condition that I did not at all anticipate so DSB had no error checking and simply crashed.

You store direct table references to archetypes (rather than just a string naming it) which in theory works fine. However, the problem is, when these tables are stored in exvars, DSB tries to serialize them when you save the game, and its serialization code is not all that smart. It has no idea this is a link to something in obj, so it simply blindly serializes the entire table, including all sorts of internal data that will certainly not be valid when you reload... so, when you do reload, everything explodes.

I've changed it to throw a Lua error if dsb_qswap (or any other function requiring an arch) is passed anything other than a string, which eliminates the problem. The key in obj for a valid arch is stored in arch.ARCH_NAME, that is, arch == obj[arch.ARCH_NAME], so changing things to use strings should hopefully not be too painful. The current save file is still going to have errors, because it has some invalid tables saved in it, but I've at least updated it so DSB will just throw Lua errors instead of segfaulting if it encounters something that looks like an arch table but turns out not to be.

Here's a DSB 0.66c exe, fixing both this bug and the RNG bug.

By the way, thanks for all your help with debugging! Being a one-person project, DSB often doesn't get enough (or any...) real testing.
kaypy
Artisan
Posts: 171
Joined: Sun Jan 19, 2014 7:11 am

Re: [0.65] Crash in qswap

Post by kaypy »

Sophia wrote:Yuck. This one is messy. Your code was doing something wrong... or, more properly, something a little too clever for DSB. It was a condition that I did not at all anticipate so DSB had no error checking and simply crashed.
My preference for DSB could likely be summarized as "Here is an engine I can use to make stuff that's too clever for its own good" 8-)
Sophia wrote: You store direct table references to archetypes (rather than just a string naming it)... so, when you do reload, everything explodes.
kaypy's troubleshooting train of thought wrote:Hmm. Qswap uses strings elsewhere. Might that be the problem? Nah. Cant be- otherwise why would it ever work at all?
I should know better, too. I have been burned by reference serialization before... (in scheme, not lua, but the same root cause)
Sophia wrote:By the way, thanks for all your help with debugging! Being a one-person project, DSB often doesn't get enough (or any...) real testing.
Thank you for all the fixes. I think most of the last couple of release have basically been a wishlist of whatever I needed at the time for my crazy plans...
Friends don't let friends eat worm round
kaypy
Artisan
Posts: 171
Joined: Sun Jan 19, 2014 7:11 am

Re: [0.65] Crash in qswap

Post by kaypy »

arch.ARCH_NAME isnt available when I'm setting the initial item configuration up, but that's not a big deal- I need to already know the arch names because I'm in the process of constructing them.

Even better, if there's no curse actually running, then the exvar arch is just a cache. And if I'm just storing a string there, I may as well just overwrite it every time, and my save is thus recovered.

So now if I don't run into any new glitches I can get back to -murdering-my-way-to-the-bottom-of-the-dungeon- "performing vital extensive playtesting" 8-)
Friends don't let friends eat worm round
Post Reply