0003092: crash+assert on taking stairs - Dungeon Crawl Stone Soup Tracker

(0010026)
jpeg (manager)
2010-12-30 01:58

I can't reproduce this.

For the record: Things that jumped out at me when trying the save were:
* The next level is partly magic-mapped, so it was apparently visited before.
* There's a labyrinth on the next level.
* Because of this there are a lot of messages when going downstairs.

What does the assert message say?

(0010028)
ortoslon (reporter)
2010-12-30 02:06

ASSERT(index < SIZE) in 'fixedvector.h' at line 65 failed.

(0010029)
jpeg (manager)
2010-12-30 02:26

Argh, I hate that one. You never can tell what index and what SIZE. Might refer to some remembered (or mapped) square, but I've no idea why it works for me.

(0010040)
KiloByte (manager)
2010-12-30 10:44

Perhaps we could add a version of asserts that allow vprintf?

(0010043)
jpeg (manager)
2010-12-30 11:10

Aha, if I open the monster tab before descending I *do* get the crash, still in current trunk (8428bacd).

There's a -More- before the next level is actually loaded, so it's possible the game tries to draw the monster tab before the monsters can be accessed, or the opposite: is still trying to display the D:13 monsters that are no longer there.

(0010047)
jpeg (manager)
2010-12-30 13:10

In trunk there's now an option to force the monster tab to stay undetached, so once the tiles build has been updated, setting

tile_allow_detached_montab = false

should enable to continue your game.

Of course, this is just a stop-gap measure until we can get the bug fixed properly. In any case, thank you for the bug report!

(0010062)
galehar (administrator)
2010-12-30 17:39

I think I've nailed it. When climbing down, the labyrinth entrance triggers a more prompt, which itself triggers a redraw which happens before the monster tab have been able to update its info. m_mon_info still contains monsters from the previous level, and when we try to access to the monster struct through env.mgrid(player2grid(pos)) it fails because the player is already on the next level. I'm fixing it by updating the monster tab before drawing it.

(0010064)
galehar (administrator)
2010-12-30 18:31

Fixed.

Issue History
Date Modified	Username	Field	Change
2010-12-30 01:30	ortoslon	New Issue
2010-12-30 01:30	ortoslon	File Added: Orto.cs
2010-12-30 01:30	ortoslon	Issue Monitored: ortoslon
2010-12-30 01:58	jpeg	Note Added: 0010026
2010-12-30 02:06	ortoslon	Note Added: 0010028
2010-12-30 02:26	jpeg	Note Added: 0010029
2010-12-30 10:44	KiloByte	Note Added: 0010040
2010-12-30 11:10	jpeg	Note Added: 0010043
2010-12-30 11:16	galehar	Issue Monitored: galehar
2010-12-30 13:10	jpeg	Note Added: 0010047
2010-12-30 17:34	galehar	Assigned To	=> galehar
2010-12-30 17:39	galehar	Note Added: 0010062
2010-12-30 17:39	galehar	Status	new => assigned
2010-12-30 18:31	galehar	Note Added: 0010064
2010-12-30 18:31	galehar	Status	assigned => resolved
2010-12-30 18:31	galehar	Fixed in Branch	=> 0.8 development branch
2010-12-30 18:31	galehar	Resolution	open => done

Notes
(0010026) jpeg (manager) 2010-12-30 01:58	I can't reproduce this. For the record: Things that jumped out at me when trying the save were: * The next level is partly magic-mapped, so it was apparently visited before. * There's a labyrinth on the next level. * Because of this there are a lot of messages when going downstairs. What does the assert message say?

(0010028) ortoslon (reporter) 2010-12-30 02:06	ASSERT(index < SIZE) in 'fixedvector.h' at line 65 failed.

(0010029) jpeg (manager) 2010-12-30 02:26	Argh, I hate that one. You never can tell what index and what SIZE. Might refer to some remembered (or mapped) square, but I've no idea why it works for me.

(0010040) KiloByte (manager) 2010-12-30 10:44	Perhaps we could add a version of asserts that allow vprintf?

(0010043) jpeg (manager) 2010-12-30 11:10	Aha, if I open the monster tab before descending I do get the crash, still in current trunk (8428bacd). There's a -More- before the next level is actually loaded, so it's possible the game tries to draw the monster tab before the monsters can be accessed, or the opposite: is still trying to display the D:13 monsters that are no longer there.

(0010047) jpeg (manager) 2010-12-30 13:10	In trunk there's now an option to force the monster tab to stay undetached, so once the tiles build has been updated, setting tile_allow_detached_montab = false should enable to continue your game. Of course, this is just a stop-gap measure until we can get the bug fixed properly. In any case, thank you for the bug report!

(0010062) galehar (administrator) 2010-12-30 17:39	I think I've nailed it. When climbing down, the labyrinth entrance triggers a more prompt, which itself triggers a redraw which happens before the monster tab have been able to update its info. m_mon_info still contains monsters from the previous level, and when we try to access to the monster struct through env.mgrid(player2grid(pos)) it fails because the player is already on the next level. I'm fixing it by updating the monster tab before drawing it.

(0010064) galehar (administrator) 2010-12-30 18:31	Fixed.

Relationships