Workertable in buildings is broken

Bug #1685645 reported by Notabilis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Fix Released
High
Unassigned

Bug Description

In bzr8334[trunk] the table of workers inside a production building isn't displayed correctly. Most of the time, only the first column ("Worker") is displayed, while the other columns (experience, next level) aren't shown. Closing and reopening the window often enough sometimes shows the complete table.

Tags: ui

Related branches

GunChleoc (gunchleoc)
Changed in widelands:
status: New → Confirmed
importance: Undecided → High
milestone: none → build20-rc1
tags: added: lowhangingfruit ui
Revision history for this message
Notabilis (notabilis27) wrote :

The bug has probably been introduced in revision 8313.
Strangely this was over 1.5 month ago and no-one seems to have noticed it (or at least: Not reported). It also only seems to appear in the tables of the production sites.

The merged branch for reference:
https://code.launchpad.net/~widelands-dev/widelands/bug-1653460-panel-init-width/+merge/318358

Revision history for this message
kaputtnik (franku) wrote :

I have noticed this also, but was unsure about it and had no time to file a bug/question.

Thanks Notabilis for doing so :-)

Notabilis (notabilis27)
tags: removed: lowhangingfruit
Revision history for this message
Notabilis (notabilis27) wrote :

I tried a solution for this bug, see the attached branch. One of the problems was a too big width of the 340282366920938463463374607431768211456 column* in the vector. I am fine with my fix for that part. Kaputtnik, as penance for your laziness you may review it. ;-)

I am not so sure with skipping the method when "get_w() == 0". When this is the case, the calculation of column widths fails, resulting in only one column being shown. The other columns are reduced to a width of 0. It seems to work when we skip the method call in that case, but I would like someone who knows the UI code to confirm it.

As far as I see it, the previous linked merge only showed the bug but did not produced it. Previous to the merge the code was probably just happy with a negative value for the table width, which was clamped to 0 after the code was merged.

* That is, we used size_t::max() to access the vector, resulting in a read of random memory.

GunChleoc (gunchleoc)
Changed in widelands:
status: Confirmed → Fix Committed
Revision history for this message
GunChleoc (gunchleoc) wrote :

Fixed in build20-rc1

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.