Opened 6 years ago
Last modified 5 years ago
#18640 new defect
xoBV tag memory leak
Reported by: | supsup | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 6.0.6 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | other |
Description
Just to save some time, here is the link to virtualbox discussion about this:
https://forums.virtualbox.org/viewtopic.php?f=6&t=93104&p=448516
Let me know if I can help somehow to solve the problem!
Attachments (1)
Change History (6)
by , 6 years ago
Attachment: | Win10-2019-05-14-10-02-32.log added |
---|
follow-up: 4 comment:2 by , 6 years ago
Which tool did you use to figure out that xoBV was the responsible tag? Would that tool also show a few more bytes of the allocations? Or just the sizes?
The tag is only used in two places, both look perfectly fine at first glance. The first place is during drive loading, which should only happen once so it cannot be the cause of the leak. The other place is VBoxDrvNtFastIoDeviceControl() in vbox/trunk/src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp@77816#L1211, but the memory is freed again on line 1271. It is thinkable that something raises an exception while processing an I/O control and thereby bypasses the free call, but I would've though that should BSOD the system rather than be quietly ignored.
comment:3 by , 6 years ago
Replying to michaln:
Is this something that did not happen in previous VirtualBox versions? In other words, is this a change in VirtualBox behavior or is it something specific to your setup?
Unknown...probably started to notice this from version 6. Currently on version 6.0.8 r130520 (Qt5.6.2) and the bug is still there
comment:4 by , 6 years ago
Replying to bird:
Which tool did you use to figure out that xoBV was the responsible tag? Would that tool also show a few more bytes of the allocations? Or just the sizes?
The tag is only used in two places, both look perfectly fine at first glance. The first place is during drive loading, which should only happen once so it cannot be the cause of the leak. The other place is VBoxDrvNtFastIoDeviceControl() in vbox/trunk/src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp@77816#L1211, but the memory is freed again on line 1271. It is thinkable that something raises an exception while processing an I/O control and thereby bypasses the free call, but I would've though that should BSOD the system rather than be quietly ignored.
Actually explained everything (eg. which tool I used) in virtualbox forum. Did you see the link above in my first post? There are much more information about it. Thanks for detailed information. While I understand you can not see the problem at the first glance, I'm sure the problem is there, as I can see xoBV is growing... The only weird thing I noticed, is that only me it seems having the problem, as I could not find others people by googling to report the problem. Anyway, I well described everything in my post above in virtualbox forum. Please check it and let me know if you have any questions. I would be glad to help to track and kill the bug! ;)
comment:5 by , 5 years ago
I believe I have the same issue since about a month or so. Sadly I dont know exactly when it started, so I cannot tell if a windows update triggered this problem. I've updated Virtualbox from a version 5 to stable 6, and now to 6.1.6 r137129 but there is no change in behaviour.
I'm running Windows 10 1709 as host os, and Ubuntu 18.04 as guest. When I do resource heavy operations in the guest the ram usage climbs both on the guest and host as expected. When I'm done I close all guest programs and the memory usage on the guest goes down. In the past also the memory usage on the host went down by the same amount. But now it does not.
I have 16GB ram, and limited the guest to 11.3GB ram. My guest currently idles at 24% memory usage after a work day, but my host is still at 87%. When I shutdown my guest the ram would get freed. When I reboot my guest it wont get freed. This is all reproducable.
I today tried poolmon from the Windows Driver Kit, which shows that not only xoBV is at 11GB, but also that it is constantly climbing by 200KB every two seconds or so. It never goes down!
This is what poolmon shows:
Memory:16652928K Avail: 2195316K PageFlts: 30274 InRam Krnl:38608K P:661724K Commit:16576248K Limit:23206528K Peak:19812260K Pool N:1806536K P:1166740K System pool information Tag Type Allocs Frees Diff Bytes Per Alloc xoBV Nonp 110226404 (1456) 110226398 (1456) 6 384 ( 0) 64
On my guest audio is disabled and 3d acceleration is turned of, I've never changed that. A shared folder is in use, maybe I could try switching that off.
Is this something that did not happen in previous VirtualBox versions? In other words, is this a change in VirtualBox behavior or is it something specific to your setup?