(probably fixed) Random crashes viewing inventory

[Gambit37]

Sometimes when I go to view the inventory, DSB crashes. I have not been able to determine if there's a common factor causing it.

I'm playing the DM dungeon.

Code: Select all

PROGRAM CRASH!
Location: 3 6 7
Reason: Segmentation Fault
Stack Dump:
DSBmain
DSBgameloop
render_inventory_view

Do you want my save game?

[Sophia]

I guess, though if there's no consistent way to reproduce the bug then it's not likely there's much I can do.

Are you using custom graphics or something else that could be causing a problem?

[Gambit37]

That was my first thought too. But I only have some new graphics: a wallset, a few wallitems and some creatures. No inventory replacement graphics, which is why I thought it weird. Seems to happen a lot on the worm level if that helps...!?

[Gambit37]

I just realised I have a replacement portrait for my champion. It's a 24-bit PNG, placed in the dungeon folder, named port_iaido.png. Could that be causing the crash? It has a solid background and no transparency.

[Gambit37]

Another crash, feeding a dragon steak to Iaido. I could shove it in his mouth, but when he started chewing the game crashed.

Code: Select all

PROGRAM CRASH!
Location: 8 13 12
Reason: Leaky eot_te queue
Stack Dump:
DSBmain
DSBgameloop

[Sophia]

That's an extremely strange way for DSB to crash. What sort of custom Lua code are you using?

[Gambit37]

Nothing too weird yet. Just a few graphical additions to the DM dungeon for testing out wall/creature replacements.

I'm using a copy of the full graphics.lua and making some changes in there, plus a few extra things in a graphics_new.lua. And some minor tweaks to existing objects in my own objects.lua. That's it.

I'll privately send you a link the the dungeon folder so you can have a look

[Sophia]

The way that you're replacing the graphics by just replacing all of graphics.lua is sort of a mess right now. It is definitely the source of one of the mysterious crashes, and given the way it happened, I wonder if there might be other memory corruption that was leading other crashes and strange problems.

I was able to reproduce the inventory viewing crash. It turns out it happens when DSB tries to draw the "POISONED" graphic. It happens because when the dungeon is being loaded, the following sequence of events occurs:

base/graphics.lua is parsed, and a reference to the "POISONED" graphic is stored in gfx.poisoned.
base/conditions.lua is parsed, and gfx.poisoned is passed in and a pointer to the graphic is stored in the native C structures.
Your custom graphics.lua is parsed, and a new "POISONED" graphic is loaded, replacing gfx.poisoned.
The Lua garbage collector is unaware of any stored pointers on the C side, so all it sees is that the old image reference is no longer pointed to by anything, and deletes it.
The engine tries to draw the graphic pointed to by its (old) stored pointer. An invalid pointer in C code is usually an instant crash, so... kaboom.

The way things are "supposed" to work is more like port_iaido. You just drop in new images and DSB transparently picks up on them and loads the new ones when it loads graphics. Of course, this means you have to dump everything in your dungeon's root directory, which is sort of disorganized.

[Gambit37]

Thank you for finding the problem. That was doing my head in!

"sort of disorganised" Yep, that's what I was trying to avoid.

When I was previously tinkering with DSB, I'd organised all my stuff into sub folders and didn't have any crashes. But now that I think about it, I was only adding new graphics, not replacing existing ones.

OK, so I really don't want to put everything in the dungeon folder if I can help it. My OCD can't cope with that and it then becomes really hard to find anything.

I suppose I could define all new graphic names, and update the objects to use those? EG:

Code: Select all

path = "gfx/creatures/"
gfx.new_dragon_front = dsb_get_bitmap(path .. "NEW_DRAGON_FRONT")
obj.dragon.front = gfx.new_dragon_front

Of course, that's a lot of extra work just to satisfy my tidy folder foibles. And would that increase memory usage?

Perhaps I'm just gonna have to do it the DSB way with everything in the root of the folder. I have a windows explorer replacement which does allow filtering a folder view using any string, so I could get into the habit of using that to only display stuff I'm currently working on.

[Sophia]

It's a very specific problem because it only affects graphics that have been passed to the engine before your custom graphics are loaded, and are then replaced by custom graphics. The obj table is not set up yet, so normally you wouldn't have an issue.

Anyway, I think a more elegant solution would be to allow file paths to be specified externally. This is actually closer to how DSB's weird all-caps no-extension way of specifying files is supposed to be a symbolic name, not an actual path. Then you could create a table of paths that the default graphics.lua would then load. As an added benefit, the game would no longer have to load everything and then trash most of it, so load times could improve. I see it working somewhat like this:

Code: Select all

graphics_paths = {
     DRAGON_FRONT = "gfx/creatures/dragon_front.png"
}

When DSB then tries to load "DRAGON_FRONT" it will first look at gfx/creatures/dragon_front.png before searching base/graphics.dat as normal.

[Sophia]

I just tested it. In 0.70 you'll be able to have a graphics.cfg, my test consisted of:

Code: Select all

graphics_paths = {
	ALCOVE_FRONT = "gfx/wall_items/alcove_front.png",
	WALLGRATE_FRONT = "gfx/wall_items/wallgrate_front.png",
	WALLGRATE_SIDE = "gfx/wall_items/wallgrate_side.png",
}

Even after removing your graphics.lua from the manifest these images still loaded.

[Gambit37]

Wow, nice, that's a great solution! Thank you for doing this

One thing I don't understand though: why the poisoned graphic caused the crash? Given your explanation, wouldn't the first replaced bitmap cause the crash?

[Sophia]

Given your explanation, wouldn't the first replaced bitmap cause the crash?

No, because most bitmaps are referenced in objects.lua which is not parsed until all (i.e., both base and custom) graphics have been loaded. Any replaced bitmaps there won't cause a problem. The crash was caused by a bitmap that was referenced in the base code's conditions.lua which is parsed after the base code's gfx.poisoned had been loaded but before your custom code had replaced it. As such, the condition stored a bitmap that then got thrown out when the garbage collector thought nobody was using it anymore. I designed DSB's infrastructure for graphics replacement to be pretty robust so it "just works" in the majority of cases; this was a kind of odd outcome that I didn't think of at the time.

As an aside, this is a separate bug that I've also fixed. In 0.70, bitmaps stored in conditions will be given an additional Lua reference so the garbage collector knows not to mess with them until and unless the condition itself is also replaced.