-
-
Notifications
You must be signed in to change notification settings - Fork 988
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
almost (?) reproducible complex crash involving the whiteboard (GNA #24020) #1517
Labels
Bug
Issues involving unexpected behavior.
Confirmed
Issues that have been successfully reproduced by at least one developer.
Whiteboard
Issues with the Planning Mode (a.k.a. Whiteboard) feature.
Comments
wesnoth-bugs
added
Bug
Issues involving unexpected behavior.
Linux
OS-specific issues that apply to Linux-based operating systems.
Whiteboard
Issues with the Planning Mode (a.k.a. Whiteboard) feature.
labels
May 8, 2017
Modified on 2015-11-03 anonymissimus wrote:
|
Modified on 2015-11-04 gfgtdf wrote:
|
Wedge009
added
Confirmed
Issues that have been successfully reproduced by at least one developer.
and removed
Linux
OS-specific issues that apply to Linux-based operating systems.
labels
May 9, 2017
gfgtdf
added a commit
that referenced
this issue
May 5, 2018
the wb recruit actions store temp units with fake ids and live longer than a turn, so resetting the underlying id counter between turns might result in dublicate id errors in wb recruit actions ( #1517 ), which might lead to errors later. With this it is of course possible to get erros when more than 2^31 (or 2^63 on a 64 bit wesnoth version.) fake units are generated during a game, but that is less likely.
Vultraz
pushed a commit
that referenced
this issue
May 5, 2018
the wb recruit actions store temp units with fake ids and live longer than a turn, so resetting the underlying id counter between turns might result in dublicate id errors in wb recruit actions ( #1517 ), which might lead to errors later. With this it is of course possible to get erros when more than 2^31 (or 2^63 on a 64 bit wesnoth version.) fake units are generated during a game, but that is less likely.
tested to be fixed after 1a135b7 |
jostephd
pushed a commit
to jostephd/wesnoth
that referenced
this issue
Oct 6, 2018
the wb recruit actions store temp units with fake ids and live longer than a turn, so resetting the underlying id counter between turns might result in dublicate id errors in wb recruit actions ( wesnoth#1517 ), which might lead to errors later. With this it is of course possible to get erros when more than 2^31 (or 2^63 on a 64 bit wesnoth version.) fake units are generated during a game, but that is less likely.
jostephd
pushed a commit
to jostephd/wesnoth
that referenced
this issue
Oct 7, 2018
the wb recruit actions store temp units with fake ids and live longer than a turn, so resetting the underlying id counter between turns might result in dublicate id errors in wb recruit actions ( wesnoth#1517 ), which might lead to errors later. With this it is of course possible to get erros when more than 2^31 (or 2^63 on a 64 bit wesnoth version.) fake units are generated during a game, but that is less likely. (cherry-picked from commit 775f3ec)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Bug
Issues involving unexpected behavior.
Confirmed
Issues that have been successfully reproduced by at least one developer.
Whiteboard
Issues with the Planning Mode (a.k.a. Whiteboard) feature.
Original submission by anonymissimus on 2015-11-03
Start a networked MP game with 3 clients 1, 2, 3. 3 is host, 1 and 3 are allied.
While it is client 1's turn, plan actions with client 3: 2 recruits and moving the leader to a village.
End client 1's turn so it's now client 2's turn. See attached screenshot for what it looks like from client 3's perspective now. The fighter is the first recruit, archer second.
Switch to client 3 and delete the planned leader move.
Delete the planned fighter recruit.
Plan to recruit a fighter on the same spot the previous fighter had been.
Repeat steps 5 and 6 until the game crashes. It always happened when trying to delete, with a deterministic backtrace, but not always after the same number of repeats I think. Most of the time, I had to do 2 deletes and 1 recruits following step 6.
(Reproduced on Lubuntu 14.04)
Release: 1.12.4+dev@2212e7c
Priority: 5 - Normal
Severity: 3 - Normal
The text was updated successfully, but these errors were encountered: