- 
    Bug 
- 
    Resolution: Fixed
- 
    P3: Somewhat important 
- 
    5.15, 6.3.1, 6.4.1
- 
    None
- 
        
- 
        21
- 
        83f079619 (dev), 6e269fe18 (6.7)
- 
        Foundation Sprint 100
Updating a QJsonObject with a string value causes increasing memory use, the following program exhibits the problem:
#include <QDebug> #include <QJsonObject> #include <QString> int main(int argc, char **argv) { QJsonObject container; while (true) { container.insert("key", "value"); qDebug() << container.size(); } return 0; }
Tested on default packages on Debian and Fedora36 for 5.15 as well as 6.3 on Debian.
5.12 does not exhibit the same problem, but as far as I can tell it doesn't use QCborContainerPrivate as the internal representation.
The problem is that the QByteArray in container.o.d.data keeps growing; after the first loop iteration it is :
data = "\003\000\000\000key\000\005\000\000\000value" = {
 [0] = 3 '\003',
 [1] = 0 '\000',
 [2] = 0 '\000',
 [3] = 0 '\000',
 [4] = 107 'k',
 [5] = 101 'e',
 [6] = 121 'y',
 [7] = 0 '\000',
 [8] = 5 '\005',
 [9] = 0 '\000',
 [10] = 0 '\000',
 [11] = 0 '\000',
 [12] = 118 'v',
 [13] = 97 'a',
 [14] = 108 'l',
 [15] = 117 'u',
 [16] = 101 'e'
 }
after the second:
data = "\003\000\000\000key\000\005\000\000\000value\000\000\000\005\000\000\000value" = {
    [0] = 3 '\003',
    [1] = 0 '\000',
    [2] = 0 '\000',
    [3] = 0 '\000',
    [4] = 107 'k',
    [5] = 101 'e',
    [6] = 121 'y',
    [7] = 0 '\000',
    [8] = 5 '\005',
    [9] = 0 '\000',
    [10] = 0 '\000',
    [11] = 0 '\000',
    [12] = 118 'v',
    [13] = 97 'a',
    [14] = 108 'l',
    [15] = 117 'u',
    [16] = 101 'e',
    [17] = 0 '\000',
    [18] = 0 '\000',
    [19] = 0 '\000',
    [20] = 5 '\005',
    [21] = 0 '\000',
    [22] = 0 '\000',
    [23] = 0 '\000',
    [24] = 118 'v',
    [25] = 97 'a',
    [26] = 108 'l',
    [27] = 117 'u',
    [28] = 101 'e'
  },
Presumably there's a bug in how strings are (re)allocated in QJsonObjects. There doesn't seem to be a problem with int-types. At least I haven't seen one.