WoWInterface - Major issue with saved variables

WoWInterface (https://www.wowinterface.com/forums/index.php)

- WoD Beta archived threads (https://www.wowinterface.com/forums/forumdisplay.php?f=151)

- - Major issue with saved variables (https://www.wowinterface.com/forums/showthread.php?t=49523)

Major issue with saved variables

Just discovered this after a user was reporting that some of his TellMeWhen icons were disappearing every single login/reload (http://wow.curseforge.com/addons/tel...a-few-bugs/#c3)

Something has gone wrong with the serializer for SavedVariables that is causing numbers that are totally able to be represented as integers to get turned into floats WITH ERROR.

See this shot of section of the SavedVariables that the profile is based on: http://i.imgur.com/Ts7WqCp.png

Icons 28 and 29 are the ones that get lost every single reload. There are also duplicates in there - one is the icon data that used to be there (which persisted from previous reload with a key of 28.00000000000001) and the other is the data that was corrupted to have a key of 28.00000000000001.

I will do some more testing, but so far this appears to only happen whenever an array-style table has gaps in it (as this one does at 23 and 24) which forces the values after the gap to get written with explicit keys (as it always has).

PS: If you're here from the report I submitted in-game, thanks for checking this out! Shameless plea: please also bring back the cost and powerType returns from GetSpellInfo() =)

Quick follow up: This is happening with MANY numbers, and not just table keys:

Source:

Lua Code:

TMW.db.global.TEST = {[28] = "test string", [29] = 28}

Result:

Lua Code:

["TEST"] = {
    [28.00000000000001] = "test string",
    [29.00000000000001] = 28.00000000000001,
},

Another test:

Lua Code:

TMW.db.global.TEST = {}
for i = 1, 200 do TMW.db.global.TEST[i] = i end

Lua Code:

["TEST"] = {
    1, -- [1]
    2, -- [2]
    3, -- [3]
    4, -- [4]
    5, -- [5]
    6, -- [6]
    7, -- [7]
    8, -- [8]
    9, -- [9]
    10, -- [10]
    11, -- [11]
    12, -- [12]
    13, -- [13]
    14, -- [14]
    15, -- [15]
    16, -- [16]
    17, -- [17]
    18, -- [18]
    19, -- [19]
    20, -- [20]
    21, -- [21]
    22, -- [22]
    23.00000000000001, -- [23]
    24.00000000000001, -- [24]
    25, -- [25]
    26, -- [26]
    27, -- [27]
    28.00000000000001, -- [28]
    29.00000000000001, -- [29]
    30, -- [30]
    31, -- [31]
    32, -- [32]
    33.00000000000001, -- [33]
    34.00000000000001, -- [34]
    35, -- [35]
    36, -- [36]
    37, -- [37]
    38.00000000000001, -- [38]
    39.00000000000001, -- [39]
    40, -- [40]
    41.00000000000001, -- [41]
    42, -- [42]
    43, -- [43]
    44.00000000000001, -- [44]
    45, -- [45]
    46.00000000000002, -- [46]
    47, -- [47]
    48.00000000000002, -- [48]
    49, -- [49]
    50, -- [50]
    51.00000000000002, -- [51]
    52, -- [52]
    53.00000000000002, -- [53]
    54, -- [54]
    55, -- [55]
    56.00000000000002, -- [56]
    57, -- [57]
    58.00000000000002, -- [58]
    59, -- [59]
    60, -- [60]
    61.00000000000002, -- [61]
    62, -- [62]
    63.00000000000002, -- [63]
    64, -- [64]
    65, -- [65]
    66.00000000000002, -- [66]
    67, -- [67]
    68.00000000000002, -- [68]
    69, -- [69]
    70, -- [70]
    71.00000000000002, -- [71]
    72, -- [72]
    73.00000000000002, -- [73]
    74, -- [74]
    75, -- [75]
    76.00000000000002, -- [76]
    77, -- [77]
    78.00000000000002, -- [78]
    79, -- [79]
    80, -- [80]
    81, -- [81]
    82.00000000000002, -- [82]
    83.00000000000002, -- [83]
    84, -- [84]
    85, -- [85]
    86, -- [86]
    87.00000000000002, -- [87]
    88.00000000000002, -- [88]
    89, -- [89]
    90, -- [90]
    91, -- [91]
    92.00000000000002, -- [92]
    93, -- [93]
    94, -- [94]
    95, -- [95]
    96.00000000000002, -- [96]
    97.00000000000002, -- [97]

The rest of the 200 numbers serialized properly, but this issue isn't limited by any max - I tested up to 20,000 and 9982 was serializing wrong.

You might try storing the integer as a string if you need to store them out of order.

The problem isn't ordering - its that numbers are straight up getting serialized wrong, and its happening no matter where the numbers are - keys and values alike are getting screwed up. Numbers that should be represented just fine as integers when stored as a double are somehow getting floating point error introduced into them. This is not like this on live servers at all.

This cannot be as simple as a floating-point error, because these are IEEE 754 doubles. Every 32-bit integer (actually, every 53-bit integer) can be stored perfectly in a double-precision floating point value, which is how Lua represents numbers.

There's clearly something more insidious going on in the serialization code.

By the way, this is only a problem with writing the saved variables out to file. In memory, the values all display correctly.

Seems to be fixed in build 18663. Thanks, Blizz!