Opened 14 years ago
Closed 14 years ago
#7720 closed defect (fixed)
g_vbgldata.mutexHGCMHandle is never destroyed (vboxsf.ko module) => Fixed in SVN
Reported by: | Eugene | Owned by: | |
---|---|---|---|
Component: | guest additions | Version: | VirtualBox 3.2.10 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | Windows |
Description
When vboxsf kernel module performs its finalization tasks, the contents of g_vbgldata structure are zeroed before RTSemFastMutexDestroy() is called for g_vbgldata.mutexHGCMHandle.
File: trunk/src/VBox/Additions/common/VBoxGuestLib/Init.cpp from SVN rev. 33540.
Consider VbglTerminate() function (Init.cpp:252). It calls vbglTerminateCommon() and then vbglR0HGCMTerminate(). It seems that the intention was to destroy g_vbgldata.mutexHGCMHandle in the latter. However, vbglTerminateCommon() zeroes the contents of g_vbgldata after it does its part of cleaning up (Init.cpp:164):
DECLVBGL(void) vbglTerminateCommon (void) { VbglPhysHeapTerminate (); RT_ZERO(g_vbgldata); return; }
After that, the value of g_vbgldata.mutexHGCMHandle is lost and the structure it points to will never be released: vbglR0HGCMTerminate() will call RTSemFastMutexDestroy(0) in this case.
The consequences of this problem are probably not that critical. It seems, this results only in a small memory leak (36 bytes on my machine) each time vboxsf module is unloaded, but still.
Host OS: Windows XP SP3 Pro x86
Guest OS: OpenSuSE Linux 11.3 x86
Attachments (1)
Change History (3)
by , 14 years ago
comment:1 by , 14 years ago
Summary: | g_vbgldata.mutexHGCMHandle is never destroyed (vboxsf.ko module) → g_vbgldata.mutexHGCMHandle is never destroyed (vboxsf.ko module) => Fixed in SVN |
---|
Thanks for the report! The next maintenance release will contain the proper fix.
VirtualBox log