blob: 0c103f0c6632a6d82d7571e51d88791ee6a33123 (
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
54
55
56
57
58
|
graphic: 0.449
device: 0.374
semantic: 0.373
performance: 0.312
socket: 0.219
x86: 0.200
ppc: 0.199
mistranslation: 0.166
debug: 0.166
kernel: 0.156
register: 0.150
network: 0.127
vnc: 0.123
PID: 0.119
architecture: 0.108
i386: 0.107
risc-v: 0.100
arm: 0.096
hypervisor: 0.082
boot: 0.081
peripherals: 0.075
virtual: 0.071
permissions: 0.070
assembly: 0.066
VMM: 0.054
user-level: 0.052
files: 0.047
TCG: 0.046
KVM: 0.023
qemu-system-x86_64 0.12.2 crashes with -m 967 under Windows
qemu 0.12.2 and 0.12.3 exit silently under Windows XP when using an -m value higher than 967. Any value below 967 works fine. Affects both qemu.exe and qemu-system-x86_64.exe (the only binaries currently available).
qemu 0.12.3 under Linux (Ubuntu 8.10) works fine.
Version 0.9.0 for Windows does not have this problem. I do not have any other binaries to test.
Command used:
qemu-system-x86_64 -L . -m 967 -hda linux.img -localtime -M pc
There is plenty of available RAM on the host PC (see attached systeminfo).
Not sure what debugging options to use, but will attach whatever is necessary.
Under 1.0.1 a pop-up window reports a Vis C++ runtime error, the result is the same. -m 966 works fine.
Can you still reproduce this problem with the latest version of QEMU?
I think that QEMU did not crash, but simply was not able to allocate the block of memory which was requested. This is an inherent problem of the fragmented memory of 32 bit applications on Windows.
QEMU reports problems with memory allocation, but QEMU for Windows tries to send those messages to stderr which is redirected to a file when QEMU was built with SDL2.
So no crash and silently by design.
64 bit versions don't have that problem, nor do my pre-built 32 bit binaries which include a patch to use upper memory. And in my latest binaries I dropped SDL support.
I close this issue - please re-open if you think this was wrong.
|