[BUG]windows 下大空间限制测评空间不准确，甚至负数

[prostylekali]

我在 windows 下某道题目使用了 8s，2048MB 的时空限制配置，测评时发现某个点空间爆了，换用 3072MB 空间限制后通过，发现该点实际空间并没有超过 2048MB 且另有一个点空间为负数。

上为 2048MB 时的情况。

本图为 3072MB 时的情况，可以发现 8-8 并没有爆空间且 8-11 空间显示为负数。

[ZnPdCo]

有个地方爆int了，2048*1024*1024=2147483648，代码中有个地方转成kb了，所以炸了。

Project_LemonLime/src/core/judgingthread.cpp

Line 927 in b5411a4

if (qMax(memoryInfo.PrivateUsage, memoryInfo.PeakWorkingSetSize) > memoryLimit * 1024 * 1024) {

memorylimit 是 int 类型，应该用ull存才对（if左边的类型是ull）。
bug的行为也很对，因为signed与unsigned比较会将两者都变成unsigned long long来比较，3072*1024*1024虽然爆了int，但是转回unsigned long long就是18446744072635809792，相当于没有内存限制了，故可以过

[ZnPdCo]

经过检查，发现存内存用的就是 int：

Project_LemonLime/src/core/judgingthread.cpp

Line 1015 in b5411a4

memoryUsed = memoryInfo.PeakWorkingSetSize;

Project_LemonLime/src/core/judgingthread.h

Line 73 in b5411a4

int memoryUsed;

似乎有很多地方用了 int 存内存，上面只是源头。我还没完全找完所有这种可能爆 int 的地方。

这个感觉耐心找就可以修完了，但是我先咕着。

同时我发现：

Project_LemonLime/src/core/judgingthread.cpp

Line 927 in b5411a4

if (qMax(memoryInfo.PrivateUsage, memoryInfo.PeakWorkingSetSize) > memoryLimit * 1024 * 1024) {

这里同时取了 memoryInfo.PrivateUsage memoryInfo.PeakWorkingSetSize 两个值最大值来检查内存是否超限。但是显示内存却只用了 memoryInfo.PeakWorkingSetSize，原因未知。代码历史悠久查不到是谁写的了，不知道是故意的还是 bug。 😵‍

[CoelacanthusHex]

似乎有很多地方用了 int 存内存，上面只是源头。我还没完全找完所有这种可能爆 int 的地方。

我觉得可以考虑 s/int/int64_t/g 然后挨个修 -Wconversion，从 32b 提升到 64b 造成的性能损失应当可以接受。应当不需要考虑使用 uint64_t 因为 int64_t 已经超过目前最大的 x86 57bits 页表。

这里同时取了 memoryInfo.PrivateUsage memoryInfo.PeakWorkingSetSize 两个值最大值来检查内存是否超限。但是显示内存却只用了 memoryInfo.PeakWorkingSetSize，原因未知。代码历史悠久查不到是谁写的了，不知道是故意的还是 bug。 😵‍

PrivateUsage 是

The Commit Charge value in bytes for this process. Commit Charge is the total amount of private memory that the memory manager has committed for a running process.

commit 在 Windows 内存管理中的意思是让 Windows 实际为其分配内存空间，commit charge 可以理解为 Windows 实际分配了多少内存（Windows 会同时在物理内存和 pagefile 分配等大的空间），Windows 程序一般不会只 reserve 不 commit 所以你可以认为这就是 Windows 一般意义上申请内存的操作。和这个值取 max 可能是考虑会有一些东西在内存达到峰值之前被换出到 pagefile，所以 PeakWorkingSetSize（WorkingSet 只计算内存里的，等同于 Linux 的 Resident Set）会低于实际使用的内存大小。但是代码不是我写的所以我也只能猜。不过 Windows 是有 PeakPagefileUsage 的，不知道为什么当时的开发者没用（难道是这个值和 PagefileUsage 一样在 Windows XP/7 上是0？）

[CoelacanthusHex]

经过检查，发现存内存用的就是 int：

Project_LemonLime/src/core/judgingthread.cpp

Line 1015 in b5411a4
memoryUsed = memoryInfo.PeakWorkingSetSize;

Project_LemonLime/src/core/judgingthread.h

Line 73 in b5411a4
int memoryUsed;

似乎有很多地方用了 int 存内存，上面只是源头。我还没完全找完所有这种可能爆 int 的地方。

这个感觉耐心找就可以修完了，但是我先咕着。

同时我发现：

Project_LemonLime/src/core/judgingthread.cpp

Line 927 in b5411a4
if (qMax(memoryInfo.PrivateUsage, memoryInfo.PeakWorkingSetSize) > memoryLimit * 1024 * 1024) {

这里同时取了 memoryInfo.PrivateUsage memoryInfo.PeakWorkingSetSize 两个值最大值来检查内存是否超限。但是显示内存却只用了 memoryInfo.PeakWorkingSetSize，原因未知。代码历史悠久查不到是谁写的了，不知道是故意的还是 bug。 😵‍

@zhipeng-jia 在 Lemon 1.1 beta 的时候写的
zhipeng-jia/project-lemon@2634599
都十五年了，我怀疑他本人都忘了为啥了

[ZnPdCo]

这里实现上可能会有点小问题：

保存比赛时，QJsonValue 只能存 $2^{53}$ 的整数，所以可能会出现精度问题？

当然这里存内存是不重要的，但是我是需要改写一个较为底层的 utils（read_json 和 write_json 只实现了 int 的存储）：

Project_LemonLime/src/base/LemonUtils.hpp

Lines 26 to 32 in 5abd55e

	inline int jsonReadHelper(int &val, const QJsonValue &jval) {
	if (jval.isDouble()) {
	val = jval.toInt();
	return 0;
	} else
	return -1;
	}

如果就这么写的话，可能会坑到别人（之后哪个字段有可能真的要存一个很大的 long long）。

但是如果用 string 存，新版本的 cdf 旧版本就不兼容了。

我在考虑要不要丢弃这里的兼容性？

之后需不需要在 cdf 里保存一个版本字段，在低版本读取高版本则弹出提示。

[alphagocc]

之后需不需要在 cdf 里保存一个版本字段，在低版本读取高版本则弹出提示。

有版本字段来着（

[ZnPdCo]

之后需不需要在 cdf 里保存一个版本字段，在低版本读取高版本则弹出提示。

有版本字段来着（

这个版本字段一直是 1.0 吧。

要改成实时版本吗

[CoelacanthusHex]

保存比赛时，QJsonValue 只能存 2 53 的整数，所以可能会出现精度问题？

我们已经要求 Qt 6 了，不应该有这个问题了，因为

Since Qt 6.0, QJsonValue can store the full precision of any 64-bit signed integer without loss, but in previous versions values outside the range of ±2^53 may lose precision. Unsigned 64-bit values greater than or equal to 2^63 will either lose precision or alias to negative values, so QMetaType::ULongLong should be avoided.
https://doc.qt.io/qt-6/qjsonvalue.html#loss-of-information-and-other-types

[CoelacanthusHex]

不过不应该使用 QJsonValue::toInt （显然，因为只有 32b），应当使用 QJsonValue::toInteger

[ZnPdCo]

我在 windows 下某道题目使用了 8s，2048MB 的时空限制配置，测评时发现某个点空间爆了，换用 3072MB 空间限制后通过，发现该点实际空间并没有超过 2048MB 且另有一个点空间为负数。

很抱歉我未能够复现。测试代码如下：

#include <bits/stdc++.h>
using namespace std;
int main() {
    vector<int> c(535350912);
    int a, b;
    cin >> a >> b;
    cout << a + b << endl;
    return 0;
}

使用 0.3.6.1 版本测试没有发现问题：

并且使用的空间在 qoj 上测试是差不多的。

不过显示为负数的情况应该是修复了。

如果方便，能否提供一下发生异常的对应测试点和代码呢？谢谢

[ZnPdCo]

有点诡异，某份代码四个变量的值差别很大：

用洛谷测的是 1.82GB:

四个变量都不沾边