#7089 closed defect (fixed)
GUI: Crash in vector renderer when opening/closing console
| Reported by: | salty-horse | Owned by: | salty-horse |
|---|---|---|---|
| Priority: | normal | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
When opening/closing the console repeatedly, it sometimes crashes. (See attached backtrace)
The issue happens in drawInteriorRoundedSquareAlg(). When it gets a small enough h, it goes through the the h>0 test.
h is then modified a few lines later:
h -= 2*Base::_strokeWidth;
Here it turns to 0 and causes the crash.
This can be easily guarded with another if(h<=0){return;} at that point.
However, I think there's another bug behind this: strokeWidth is usually 0 when the console slides, so h shouldn't change by the above snipept. In my crash (and tests where I slowed down the slide and printed the values), _strokeWidth was always 1. I'm not sure what caused it to change to 1.
Ticket imported from: bugs/7089.
Attachments (1)
Change History (6)
by , 10 years ago
| Attachment: | backtrace.txt added |
|---|
comment:1 by , 10 years ago
comment:2 by , 10 years ago
The problem is with the scroll bar in the console, which uses a stroke >= 0.
To consistently get the error, type several "help" commands to get a scrollbar, before closing the console. You have to slow down the console sliding so it will always try to render the last few frames at the top of the screen:
--- a/gui/console.cpp
+++ b/gui/console.cpp
@@ -227,7 +227,7 @@ void ConsoleDialog::handleTickle() {
if (_slideMode != kNoSlideMode) {
const float tmp = (float)(g_system->getMillis() - _slideTime) / kConsoleSlideDownDuration;
if (_slideMode == kUpSlideMode) {
- _y = (int)(_h * (0.0 - tmp));
+ _y -= 1;
} else {
_y = (int)(_h * (tmp - 1.0));
}
So, do you think a good solution to move the if (w <= 0 || h <= 0) { return; }?
I don't like the idea of performing the calculation inside the test itself - IMO it should be kept simple.
comment:3 by , 10 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:5 by , 7 years ago
| Component: | → GUI |
|---|
I think it might be best to change the early check to assure w and h are bigger than the values subtracted at a later point. Or simply move the check further down below (if that doesn't cause other issues).