0005544: Assertion failure in libutil.cc:942 - Dungeon Crawl Stone Soup Tracker

(0017676)
pipping (reporter)
2012-04-08 21:31

Seems to be related to bringing up the minimap using X.

(0017677)
pipping (reporter)
2012-04-08 21:54

This is with 0.10.1 btw.

(0017736)
KiloByte (manager)
2012-04-14 01:14

Do you happen to use the same screen size for playing? If so, could you say what it is? You can read it from "stty -a".

I didn't manage to reproduce this crash, but it's almost surely something dependent on the exact screen size, which is apparently different from what I tried.

(0017739)
pipping (reporter)
2012-04-14 11:32

I use a tiling window manager (stumpwm); as a result, the size of the terminal inside which I play might change over time. It would usually be either 118x34 or 118x68.

(0017742)
neil (administrator)
2012-04-14 17:18

Might the terminal size have changed while you were playing? That is almost guaranteed to cause a crash, in particular the next time you bring up the minimap.

(0017744)
KiloByte (manager)
2012-04-14 18:31

neil: not "almost guaranteed", any such _known_ bugs should have long since been fixed, and having them is obviously unacceptable. From this crash log, the game has seen a resize, but only 122 seconds before the crash.

It's still possible it is related to a resize, but I somehow doubt that.

(0017745)
neil (administrator)
2012-04-14 19:17
edited on: 2012-04-14 19:24

kilobyte: Try starting a game in an 80x24 terminal, increasing the terminal window to 80x25, then pressing X. It crashes 100% of the time for me, with the above assertion failure (libutil.cc:934 in trunk). Increasing the width seems to crash less reliably: I can drag-resize my terminal window up to at least 382 columns, but if change from 80 to 188 without passing through the intermediate widths (by maximizing horizontally), viewing the map does trigger the crash. Decreasing the height does not seem to crash, or at least not as reliably.

Edit: I am investigating, though I don't know if I'll have time to solve the problem today.

(0017746)
neil (administrator)
2012-04-14 20:27
edited on: 2012-04-14 20:36

One problem: resizing on Unix calls console_shutdown()/console_startup() to re-initialize curses. console_startup() correctly calls initscr() to re-initialise ncurses, then crawl_view.init_geometry() to update crawl's idea of the terminal and subwindow sizes. The curses LINES variable is still at its old value, though, even after initscr(); this means init_geometry() sees the wrong size, and the region keeps its old size, leading to a crash later. It looks like with ncurses one needs to call refresh() to get LINES and COLS to update.

However, if I add a call to refresh() immediately before init_geometry(), resizing gives me another crash, this time related to the message window:

ERROR in 'libutil.cc' at line 938: screen write out of bounds: (1,8) into (80,7)

It's a lot easier to get this second crash if you use something like view_max_height = 50, so that the message window doesn't grow. It's probably also necessary to have a full message window (so not a brand-new game).

(0017747)
neil (administrator)
2012-04-14 20:30

I don't have time to finish looking into this at the moment, so I'm unassigning it from myself for now.

(0017748)
neil (administrator)
2012-04-14 21:01
edited on: 2012-04-14 21:13

The second problem seems to occur when the message window size decreases. In my case, one SIGWINCH is increasing it from 7 to 8 and another from 8 to 7. message_window::add_line() resizes the lines list as it should, but message_window::show() does not (and cannot, because it is const). Stopping the show() loop at i < height() seems to work.

(0017749)
neil (administrator)
2012-04-14 22:43

Okay, so I did have time to continue investigating. . . . The resize crash should now be fixed in trunk (0.11-a0-1137-gefba585) and stable (0.10.2-2-g0f52ca6). There are still a few display glitches related to resizing, though I fixed the most egregious of them in the next commit (0.11-a0-1138-g833bd90 and 0.10.2-3-gf8cb65b).

Sorry for spamming this report with updates.

(0017750)
pipping (reporter)
2012-04-14 22:50

Cool.

Also, thanks for spamming this report with updates. :)

Issue History
Date Modified	Username	Field	Change
2012-04-08 19:18	pipping	New Issue
2012-04-08 19:18	pipping	File Added: crash-Elias-20120408-191314.txt
2012-04-08 19:20	pipping	File Added: Elias.cs
2012-04-08 21:31	pipping	Note Added: 0017676
2012-04-08 21:53	pipping	File Added: crash-Elias-20120408-192315.txt
2012-04-08 21:53	pipping	File Added: crash-Elias-20120408-213112.txt
2012-04-08 21:54	pipping	Note Added: 0017677
2012-04-14 01:14	KiloByte	Note Added: 0017736
2012-04-14 11:32	pipping	Note Added: 0017739
2012-04-14 17:18	neil	Note Added: 0017742
2012-04-14 17:18	neil	Status	new => feedback
2012-04-14 18:31	KiloByte	Note Added: 0017744
2012-04-14 19:17	neil	Note Added: 0017745
2012-04-14 19:19	neil	Note Edited: 0017745
2012-04-14 19:20	neil	Note Edited: 0017745
2012-04-14 19:24	neil	Note Edited: 0017745
2012-04-14 19:24	neil	Status	feedback => assigned
2012-04-14 19:24	neil	Assigned To	=> neil
2012-04-14 20:27	neil	Note Added: 0017746
2012-04-14 20:29	neil	Note Edited: 0017746
2012-04-14 20:29	neil	Assigned To	neil =>
2012-04-14 20:30	neil	Note Added: 0017747
2012-04-14 20:30	neil	Status	assigned => confirmed
2012-04-14 20:32	neil	Note Edited: 0017746
2012-04-14 20:35	neil	Note Edited: 0017746
2012-04-14 20:36	neil	Note Edited: 0017746
2012-04-14 21:01	neil	Note Added: 0017748
2012-04-14 21:13	neil	Note Edited: 0017748
2012-04-14 22:43	neil	Note Added: 0017749
2012-04-14 22:43	neil	Status	confirmed => resolved
2012-04-14 22:43	neil	Fixed in Branch	=> 0.11 development branch
2012-04-14 22:43	neil	Resolution	open => done
2012-04-14 22:43	neil	Assigned To	=> neil
2012-04-14 22:44	neil	Fixed in Branch	0.11 development branch => 0.10 stable branch
2012-04-14 22:50	pipping	Note Added: 0017750

Notes
(0017676) pipping (reporter) 2012-04-08 21:31	Seems to be related to bringing up the minimap using X.

(0017677) pipping (reporter) 2012-04-08 21:54	This is with 0.10.1 btw.

(0017736) KiloByte (manager) 2012-04-14 01:14	Do you happen to use the same screen size for playing? If so, could you say what it is? You can read it from "stty -a". I didn't manage to reproduce this crash, but it's almost surely something dependent on the exact screen size, which is apparently different from what I tried.

(0017739) pipping (reporter) 2012-04-14 11:32	I use a tiling window manager (stumpwm); as a result, the size of the terminal inside which I play might change over time. It would usually be either 118x34 or 118x68.

(0017742) neil (administrator) 2012-04-14 17:18	Might the terminal size have changed while you were playing? That is almost guaranteed to cause a crash, in particular the next time you bring up the minimap.

(0017744) KiloByte (manager) 2012-04-14 18:31	neil: not "almost guaranteed", any such _known_ bugs should have long since been fixed, and having them is obviously unacceptable. From this crash log, the game has seen a resize, but only 122 seconds before the crash. It's still possible it is related to a resize, but I somehow doubt that.

(0017745) neil (administrator) 2012-04-14 19:17 edited on: 2012-04-14 19:24	kilobyte: Try starting a game in an 80x24 terminal, increasing the terminal window to 80x25, then pressing X. It crashes 100% of the time for me, with the above assertion failure (libutil.cc:934 in trunk). Increasing the width seems to crash less reliably: I can drag-resize my terminal window up to at least 382 columns, but if change from 80 to 188 without passing through the intermediate widths (by maximizing horizontally), viewing the map does trigger the crash. Decreasing the height does not seem to crash, or at least not as reliably. Edit: I am investigating, though I don't know if I'll have time to solve the problem today.

(0017746) neil (administrator) 2012-04-14 20:27 edited on: 2012-04-14 20:36	One problem: resizing on Unix calls console_shutdown()/console_startup() to re-initialize curses. console_startup() correctly calls initscr() to re-initialise ncurses, then crawl_view.init_geometry() to update crawl's idea of the terminal and subwindow sizes. The curses LINES variable is still at its old value, though, even after initscr(); this means init_geometry() sees the wrong size, and the region keeps its old size, leading to a crash later. It looks like with ncurses one needs to call refresh() to get LINES and COLS to update. However, if I add a call to refresh() immediately before init_geometry(), resizing gives me another crash, this time related to the message window: ERROR in 'libutil.cc' at line 938: screen write out of bounds: (1,8) into (80,7) It's a lot easier to get this second crash if you use something like view_max_height = 50, so that the message window doesn't grow. It's probably also necessary to have a full message window (so not a brand-new game).

(0017747) neil (administrator) 2012-04-14 20:30	I don't have time to finish looking into this at the moment, so I'm unassigning it from myself for now.

(0017748) neil (administrator) 2012-04-14 21:01 edited on: 2012-04-14 21:13	The second problem seems to occur when the message window size decreases. In my case, one SIGWINCH is increasing it from 7 to 8 and another from 8 to 7. message_window::add_line() resizes the lines list as it should, but message_window::show() does not (and cannot, because it is const). Stopping the show() loop at i < height() seems to work.

(0017749) neil (administrator) 2012-04-14 22:43	Okay, so I did have time to continue investigating. . . . The resize crash should now be fixed in trunk (0.11-a0-1137-gefba585) and stable (0.10.2-2-g0f52ca6). There are still a few display glitches related to resizing, though I fixed the most egregious of them in the next commit (0.11-a0-1138-g833bd90 and 0.10.2-3-gf8cb65b). Sorry for spamming this report with updates.

(0017750) pipping (reporter) 2012-04-14 22:50	Cool. Also, thanks for spamming this report with updates. :)

Relationships