0005449: Crash when attempting to view reanimated zombie

Notes
(0020695) Brightgalrs (reporter) 2012-02-25 20:34	Perhaps I should clarify that this zombie animal was raised while it was inside of the cage. It was not raised and then captured by a cage trap.

(0020703) Kogut (reporter) 2012-02-26 00:21	Please, try disabling true type - maybe it will fix crash. Otherwise, please upload savegame.

(0020749) Footkerchief (manager) 2012-02-26 10:47	Reminder sent to: Brightgalrs Does this still crash if you disable TrueType?

(0020767) jbtw (reporter) 2012-02-26 15:04 edited on: 2012-02-26 15:18	(Continuing here from bug 0005461) Reclaiming the fort where I first had this issue, I constructed a save where I could reliably reproduce this issue, and determined that indeed it doesn't occur if I disable TrueType. Similarly to 0005446 It also doesn't occur if I make the command window wider. I guess you don't need more details at this point, but in case it's useful, here's how to reproduce: - Load the save at http://dffd.wimbli.com/file.php?id=5704 [^] - Ensure TrueType is turned on. Possibly other factors also relevant like tileset size; here's my details: Loading bindings from data/init/interface.txt New window size: 1280x400 Font size: 16x16 Resizing grid to 80x25 Resizing font to 16x16 Picked font at 12 points for ceiling 16 - Hit u to the Units screen - Go right twice to Other - Go up one to Ecemamith - Hit c to zoom to him - Hit i to open inventory - Hit - to scroll backwards through the inventory (it has to be one item at a time to get the crash as I originally described, though other strange things can happen if you do it differently); when you reach the second page up from the bottom DF crashes with the following messages: Asked for nonexistent texture data terminate called after throwing an instance of 'std::length_error' what(): vector::_M_fill_insert ./df: line 6: 22818 Aborted ./libs/Dwarf_Fortress $* (I can now confirm that the "Asked for nonexistent texture data" appears immediately before the crash) I noticed another oddity which may be related: some of the corpses have acquired corrupted names. For example, from a combat report: "The human corpsehuman corpse charges at The militia commander!" I thought that this doubled-up name may make the lines in the inventory longer and make the crash more likely, but on closer inspection there are no such long names in the inventory which I'm using to cause the crash. So most likely this is an independent bug.

(0021116) Footkerchief (manager) 2012-03-05 08:33	Does this still crash in 0.34.04 with TrueType enabled?

Issue History
Date Modified	Username	Field	Change
2012-02-25 20:33	Brightgalrs	New Issue
2012-02-25 20:34	Brightgalrs	Note Added: 0020695
2012-02-26 00:21	Kogut	Note Added: 0020703
2012-02-26 10:45	Footkerchief	Summary	Crash from selecting raised and caged zombie => Crash viewing raised and caged zombie
2012-02-26 10:46	Footkerchief	Summary	Crash viewing raised and caged zombie => Crash when attempting to view reanimated zombie
2012-02-26 10:46	Footkerchief	Relationship added	has duplicate 0005461
2012-02-26 10:47	Footkerchief	Note Added: 0020749
2012-02-26 10:47	Footkerchief	Relationship added	related to 0005446
2012-02-26 15:04	jbtw	Note Added: 0020767
2012-02-26 15:18	jbtw	Note Edited: 0020767	View Revisions
2012-02-27 07:13	Footkerchief	Status	new => assigned
2012-02-27 07:13	Footkerchief	Assigned To	=> Baughn
2012-03-05 08:33	Footkerchief	Note Added: 0021116
2012-03-05 08:33	Footkerchief	Tag Attached: AWAITING UPDATE
2014-01-20 19:37	Footkerchief	Status	assigned => resolved
2014-01-20 19:37	Footkerchief	Resolution	open => unable to reproduce
2014-01-20 19:38	Footkerchief	Resolution	unable to reproduce => fixed
2014-01-20 19:38	Footkerchief	Fixed in Version	=> 0.34.04
2014-08-04 15:01	Footkerchief	Tag Detached: AWAITING UPDATE