blob: 1c685f4fa5a979bc254d84fdb141d610bdc0fdac (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
Memory leak for x86 guest on macOS ARM host
Description of problem:
QEMU is used by docker to run `x86` binaries on Apple silicon. Then using `mmap` followed by `munmap` results in a memory leak manifested by continuously growing RSS memory usage when running `mmap` and `munmap` in a loop, e.g., when running the following binary:
```
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
const int page = 4096;
int work(int N) {
int *ptr = mmap(NULL, N * sizeof(int), PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
if (ptr == MAP_FAILED) {
printf("Mapping Failed\n");
return 1;
}
for(int i = 0; i < N; i++) {
ptr[i] = i * 10;
}
int err = munmap(ptr, N * sizeof(int));
if (err != 0) {
printf("UnMapping Failed\n");
return 1;
}
return 0;
}
int main() {
int N = page * 1024;
while (1) {
int res = work(N);
if (res) {
return res;
}
printf(".\n");
}
return 0;
}
```
Steps to reproduce:
```
$ LEAK=$(docker run --platform linux/amd64 -d -it martin2718/mmap-leak ./a.out)
$ docker exec -it $LEAK top # you should observe that RES for a.out keeps growing
$ docker exec -it $LEAK pmap -x 1 # you should see a single memory mapping whose RSS memory usage keeps growing
$ docker kill $LEAK # abort the experiment
```
|