Correction: I modified VirtualBox GUI to* NOT *show close dialog.
On Fri, Apr 19, 2013 at 4:53 PM, Ribhi Kamal <[email protected]> wrote: > Michael, > I spent all day testing/comparing builds, below is my test result: > > I compared the behaviour between unmodified vbox 4.2.8 and vbox 4.2.8 with > your patch. Before the patch, Entering/Leaving fullscreen crashed > virtualbox.exe 3 out of 4 attempts. After the patch, virtualbox crashed 2 > out of 40+ attempts. The two crashes happened in different places, so it > seems that your patch truly fixes the issue but other bugs (faults) got > uncovered. > > Test steps: > 1- Create a linux VM with two virtual monitors (GA needed) > 2- Start the VM > 3- Enable all monitors inside the guest (mirror or spanning) > 4- Run the following script: > #!/bin/bash > > while true > do > xrandr --output VBOX1 --mode 1280x768 # Change this mode if needed > xrandr --output VBOX1 --mode 1440x1050 # Change this mode if needed > done > #------------------- > 5- While the script the running, enter then exit full screen repeatedly. > > The other area that is of interest to me is closing the VM while a resize > event is happening. This issue seem to only affects me because I modified > VirtualBox GUI to* NOT *show the close dialog. Instead, it pauses the > machine and proceeds to power down the VM immediately as if the user > selected the "Power off the machine" option. > > I applied my change along with your fix and then tested closing the > machine from inside the fullscreen window. So far, I'm unable to make > virtualbox crash but this issue requires time (more time). > > Test steps: > 1- Do the same steps as before from 1-4 > 2- In normal view, make sure the the window is not Maximized (both windows) > 3- Enter fullscreen and then run the script > 4- After a few seconds, exit the machine. Be sure to disable the close > dialog. > > Finally, I tried to reproduce the bug using a Debug build. But the problem > did not happen at all because everything was running slow. > > So to sum things up, the patch fixed the issue but two new crashes > surfaced. Both seem like a variation of use-after-free. Attached is one new > crash that happened with 4.2.8 with your fix and no code modification on my > part. The old crash file that I attached previously still applies (attached > again). > > Sorry I didn't have time to dig deeper than this. Once I have more time, I > will try to pin point the source of these two crashes. > > > > On Thu, Apr 18, 2013 at 11:49 AM, Ribhi Kamal <[email protected]> wrote: > >> Sorry about the delay, I'm still unable to confirm if the patch fixed the >> issue. I should be able to give an affirmative yea or nay by tomorrow. I >> have a bunch of projects due and didn't get enough time to test it with a >> clean build, but I already did the build so all that is left is to test it >> tomorrow. >> >> Sorry again, >> Ribhi >> >> >> On Thu, Apr 18, 2013 at 10:10 AM, Michael Thayer < >> [email protected]> wrote: >> >>> Hello Ribhi, >>> >>> Any update here? The crash that you reported after applying my patch >>> looked like it was in a completely different area of the VirtualBox code, >>> so I still have hope that my patch fixes the issue. I would be >>> particularly interested if you happened to prove me wrong on that, but no >>> worries if it is not currently as important for you as it was. >>> >>> Regards, >>> >>> Michael >>> >>> >>> On 16/04/13 23:06, Ribhi Kamal wrote: >>> >>>> I did a quick test against V4.2.12 and, I'm sorry, it did not work. The >>>> crash seems to have moved somewhere else. >>>> >>>> Steps: >>>> 1- Boot up the VM with dual monitors (physical and virtual) >>>> 2- Enter fullscreen >>>> 3- Exit the VM from within fullscreen view. >>>> >>>> There is a small chance that the crash happened due to my changes or >>>> changes in V4.2.12 (vs V4.2.8). I'm still on campus now, but once I'm >>>> home or work I'll do a debug build a test it again against an unmodified >>>> V4.2.8. For now, attached is the dump analysis. >>>> >>>> Thanks, >>>> Ribhi >>>> >>>> >>>> >>>> On Tue, Apr 16, 2013 at 2:51 PM, Michael Thayer >>>> <[email protected] >>>> <mailto:michael.thayer@oracle.**com<[email protected]>>> >>>> wrote: >>>> >>>> Hello Ribhi, >>>> >>>> Does this patch look good to you? >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>> Index: src/VBox/Frontends/VirtualBox/**__src/runtime/UIFrameBuffer. >>>> **cpp >>>> ==============================**__============================** >>>> ==__======= >>>> --- src/VBox/Frontends/VirtualBox/**__src/runtime/UIFrameBuffer.** >>>> cpp >>>> (revision 85072) >>>> +++ src/VBox/Frontends/VirtualBox/**__src/runtime/UIFrameBuffer.** >>>> cpp >>>> >>>> (revision 85073) >>>> @@ -158,24 +158,19 @@ >>>> return E_FAIL; >>>> >>>> NOREF(uScreenId); >>>> - /* A resize event can happen while we are switching machine >>>> view classes, >>>> - * but we synchronise afterwards so that shouldn't be a >>>> problem. We must >>>> - * temporarily remove the framebuffer in Display though while >>>> switching >>>> - * to respect the thread synchronisation logic (see >>>> UIFrameBuffer.h). */ >>>> + *pbFinished = FALSE; >>>> + lock(); /* See comment in setView(). */ >>>> if (m_pMachineView) >>>> QApplication::postEvent(m___**pMachineView, >>>> >>>> new UIResizeEvent(uPixelFormat, >>>> pVRAM, >>>> uBitsPerPixel, >>>> uBytesPerLine, >>>> uWidth, >>>> uHeight)); >>>> else >>>> - { >>>> /* Report to the VM thread that we finished resizing and >>>> rely on the >>>> * synchronisation when the new view is attached. */ >>>> *pbFinished = TRUE; >>>> - return S_OK; >>>> - } >>>> + unlock(); >>>> >>>> - *pbFinished = FALSE; >>>> return S_OK; >>>> } >>>> >>>> @@ -200,9 +195,11 @@ >>>> return E_POINTER; >>>> *pbSupported = TRUE; >>>> >>>> - if (!m_pMachineView) >>>> - return S_OK; >>>> - QSize screen = m_pMachineView->maxGuestSize()**__; >>>> >>>> + lock(); /* See comment in setView(). */ >>>> + QSize screen; >>>> + if (m_pMachineView) >>>> + screen = m_pMachineView->maxGuestSize()**__; >>>> >>>> + unlock(); >>>> if ( (screen.width() != 0) >>>> && (uWidth > (ULONG)screen.width()) >>>> && (uWidth > (ULONG)width())) >>>> @@ -249,7 +246,10 @@ >>>> reg += rect; >>>> ++ rects; >>>> } >>>> - QApplication::postEvent(m___**pMachineView, new >>>> >>>> UISetRegionEvent(reg)); >>>> + lock(); /* See comment in setView(). */ >>>> + if (m_pMachineView) >>>> + QApplication::postEvent(m___**pMachineView, new >>>> >>>> UISetRegionEvent(reg)); >>>> + unlock(); >>>> >>>> return S_OK; >>>> } >>>> @@ -271,6 +271,12 @@ >>>> >>>> void UIFrameBuffer::setView(__**UIMachineView * pView) >>>> >>>> { >>>> + /* We are not supposed to use locking for things which are done >>>> + * on the GUI thread. Unfortunately I am not clever enough to >>>> + * understand the original author's wise synchronisation logic >>>> + * so I will do it anyway. */ >>>> + lock(); >>>> m_pMachineView = pView; >>>> m_WinId = (m_pMachineView && m_pMachineView->viewport()) ? >>>> (LONG64)m_pMachineView->__**viewport()->winId() : 0; >>>> >>>> + unlock(); >>>> >>>> } >>>> >>>> >>>> On 28/03/13 01:30, Ribhi Kamal wrote: >>>> >>>> It seems that UIMachineView::maxGuestSize() continues to execute >>>> while >>>> some other thread/process destroys the UIMachineView object. To >>>> test >>>> this out, I put in a hack in UIMachineView to basically SpinLock >>>> until >>>> any existing maxGuestSize exits. Then it sets a flag using a >>>> static >>>> variable to prevent maxGuestSize from using any member variables >>>> after >>>> the view has been destroyed. When the view is recreated, the >>>> flag is reset. >>>> >>>> I've attached is my hack (based on 4.2.10), it works pretty >>>> well and >>>> seems to stop the crash. I hope this will help you put in a >>>> better fix >>>> in the future. >>>> >>>> Just one question, Which process/thread executes maxGuestSize? >>>> An EMT >>>> thread? >>>> >>>> Cheers! >>>> >>>> fyi, There are cases where this hack will not work (in theory) >>>> so please >>>> don't use it. >>>> >>>> >>>> On Sat, Mar 16, 2013 at 4:09 PM, Ribhi Kamal < >>>> [email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>> >>>> Just happened while switching from full screen back to >>>> normal view. >>>> This is something new, only in 4.2, because the virtual >>>> machine used >>>> to crash only while closing it so it wasn't a big deal. >>>> I'll open a >>>> bug once I reproduce it with the released binaries... don't >>>> wait. >>>> >>>> Meanwhile, please let me know if you need any additional >>>> information/testing. >>>> >>>> Thanks, >>>> Ribhi >>>> >>>> >>>> >>>> On Fri, Mar 15, 2013 at 8:26 PM, Ribhi Kamal >>>> <[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> >>>> wrote: >>>> >>>> "Unfortunately, I can't find the log files" >>>> >>>> Obviously that is not true, I uploaded the logs to my >>>> dropbox >>>> >>>> >>>> On Fri, Mar 15, 2013 at 8:25 PM, Ribhi Kamal >>>> <[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] >>>> >>>> <mailto:[email protected]>>> wrote: >>>> >>>> I've been seeing a crash when closing >>>> VirtualBox.exe that is >>>> almost never reproducible. Few days ago I managed >>>> to get a >>>> crash dump and ran the analysis, see below. At the >>>> time of >>>> the crash, I was closing the virtual machine after >>>> it had >>>> been running for ~24 hours. Unfortunately, I can't >>>> find the >>>> log files >>>> >>>> I'm using the following: >>>> VirtualBox 4.2.8 (Cross compiled with VS2010-SP1 on >>>> windows >>>> 7 64bit, Target Host = x86) >>>> Host Win7 32bit >>>> Guest Linux 2.6 32bit >>>> Build Type: Release >>>> >>>> Please let me know if you have any questions. >>>> >>>> Thanks, >>>> Ribhi >>>> >>>> Log files: >>>> Successful: >>>> >>>> https://www.dropbox.com/s/__**xrvcr8sud4z63ia/Success.log<https://www.dropbox.com/s/__xrvcr8sud4z63ia/Success.log> >>>> >>>> <https://www.dropbox.com/s/**xrvcr8sud4z63ia/Success.log<https://www.dropbox.com/s/xrvcr8sud4z63ia/Success.log> >>>> > >>>> Crash: >>>> >>>> https://www.dropbox.com/s/__**p5pslbt3sl9cpeo/Crash.log<https://www.dropbox.com/s/__p5pslbt3sl9cpeo/Crash.log> >>>> >>>> >>>> <https://www.dropbox.com/s/**p5pslbt3sl9cpeo/Crash.log<https://www.dropbox.com/s/p5pslbt3sl9cpeo/Crash.log> >>>> > >>>> >>>> >>>> 0:000> !analyze -v -f >>>> >>>> ********************************__***************************** >>>> ***__******************* >>>> >>>> >>>> * >>>> * >>>> * Exception >>>> Analysis * >>>> * >>>> * >>>> >>>> ********************************__***************************** >>>> ***__******************* >>>> >>>> >>>> >>>> GetPageUrlData failed, server returned HTTP status >>>> 404 >>>> URL requested: >>>> http://watson.microsoft.com/__**StageOne/VirtualBox_exe/4_2_8_* >>>> *__0/51420e3b/unknown/0_0_0_0/_**_bbbbbbb4/80000003/00000000.__** >>>> htm?Retriage=1<http://watson.microsoft.com/__StageOne/VirtualBox_exe/4_2_8___0/51420e3b/unknown/0_0_0_0/__bbbbbbb4/80000003/00000000.__htm?Retriage=1> >>>> <http://watson.microsoft.com/**StageOne/VirtualBox_exe/4_2_8_** >>>> 0/51420e3b/unknown/0_0_0_0/**bbbbbbb4/80000003/00000000.** >>>> htm?Retriage=1<http://watson.microsoft.com/StageOne/VirtualBox_exe/4_2_8_0/51420e3b/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1> >>>> > >>>> >>>> >>>> FAULTING_IP: >>>> VirtualBox!UIMachineView::__**maxGuestSize+18 >>>> >>>> [c:\vboxbuild\virtualbox\4.2._**_8\src\src\vbox\frontends\__** >>>> virtualbox\src\runtime\__**uimachineview.cpp >>>> >>>> @ 702] >>>> *0145ed68 f00fc70f lock cmpxchg8b qword ptr >>>> [edi] * >>>> >>>> >>>> EXCEPTION_RECORD: ffffffff -- (.exr >>>> 0xffffffffffffffff) >>>> ExceptionAddress: 00000000 >>>> ExceptionCode: 80000003 (Break instruction >>>> exception) >>>> ExceptionFlags: 00000000 >>>> NumberParameters: 0 >>>> >>>> FAULTING_THREAD: 00000ef4 >>>> >>>> DEFAULT_BUCKET_ID: STATUS_BREAKPOINT >>>> >>>> PROCESS_NAME: VirtualBox.exe >>>> >>>> ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} >>>> Breakpoint >>>> A breakpoint has been reached. >>>> >>>> EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651 >>>> <tel:%282147483651> >>>> <tel:%282147483651>) - One or more arguments are >>>> invalid >>>> >>>> >>>> MOD_LIST: <ANALYSIS/> >>>> >>>> NTGLOBALFLAG: 0 >>>> >>>> APPLICATION_VERIFIER_FLAGS: 0 >>>> >>>> ADDITIONAL_DEBUG_TEXT: Followup set based on >>>> attribute >>>> [Is_ChosenCrashFollowupThread] from Frame:[0] on >>>> thread:[PSEUDO_THREAD] >>>> >>>> LAST_CONTROL_TRANSFER: from 0143bea0 to 0145ed68 >>>> >>>> PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT >>>> >>>> BUGCHECK_STR: >>>> APPLICATION_FAULT_STATUS___** >>>> BREAKPOINT_NULL_POINTER_READ >>>> >>>> STACK_TEXT: >>>> 03a3ca98 0145ed68 >>>> virtualbox!UIMachineView::__**maxGuestSize+0x18 >>>> 03a3cab0 0143bea0 >>>> virtualbox!UIFrameBuffer::__** >>>> VideoModeSupported+0x30 >>>> 03a3cac8 6927c724 vboxc!__** >>>> vmmdevVideoModeSupported+0x74 >>>> 03a3caec 690b4edc vboxdd!vmmdevRequestHandler+__** >>>> 0xecc >>>> >>>> 03a3fb5c 72f198d1 vboxvmm!IOMIOPortWrite+0x91 >>>> 03a3fb84 72f0891f >>>> vboxvmm!__**HWACCMR3RestartPendingIOInstr+**__0xcf >>>> 03a3fba4 72ea303c >>>> vboxvmm!__**emR3ExecuteIOInstruction+0x1c >>>> 03a3fc78 72ea3589 vboxvmm!emR3HwaccmHandleRC+__** >>>> 0x189 >>>> >>>> 03a3fc8c 72ea3788 vboxvmm!emR3HwAccExecute+0x168 >>>> 03a3fcb0 72ea0d84 vboxvmm!EMR3ExecuteVM+0x274 >>>> 03a3fcd8 72efb2aa >>>> vboxvmm!__**vmR3EmulationThreadWithId+__**0x45a >>>> 03a3fcf8 72efb2f4 vboxvmm!vmR3EmulationThread+__** >>>> 0x14 >>>> >>>> 03a3fd0c 69ca1523 vboxrt!rtThreadMain+0x33 >>>> 03a3fd38 69ce539b vboxrt!rtThreadNativeMain+0x6b >>>> 03a3fd58 6bb6c556 msvcr100!_endthreadex+0x3f >>>> 03a3fd90 6bb6c600 msvcr100!_endthreadex+0xce >>>> 03a3fd9c 76b4ed6c kernel32!BaseThreadInitThunk+_** >>>> _0xe >>>> 03a3fda8 7722377b ntdll!__RtlUserThreadStart+__** >>>> 0x70 >>>> >>>> 03a3fde8 7722374e ntdll!_RtlUserThreadStart+0x1b >>>> >>>> >>>> STACK_COMMAND: .cxr 0000000003A3C7B4 ; kb ; dds >>>> 3a3ca98 ; kb >>>> >>>> FOLLOWUP_IP: >>>> VirtualBox!UIMachineView::__**maxGuestSize+0 >>>> >>>> [c:\vboxbuild\virtualbox\4.2._**_8\src\src\vbox\frontends\__** >>>> virtualbox\src\runtime\__**uimachineview.cpp >>>> >>>> @ 701] >>>> 0145ed50 83ec0c sub esp,0Ch >>>> >>>> FAULTING_SOURCE_CODE: >>>> 697: >>>> RT_MAKE_U64(maxSize.height(), >>>> maxSize.width())); >>>> 698: } >>>> 699: >>>> 700: QSize UIMachineView::maxGuestSize() >>>> > 701: { >>>> 702: uint64_t u64Size = >>>> ASMAtomicReadU64(&m___**u64MaxGuestSize); >>>> >>>> 703: return QSize(int(RT_HI_U32(u64Size)), >>>> int(RT_LO_U32(u64Size))); >>>> 704: } >>>> 705: >>>> 706: QSize UIMachineView::guestSizeHint() >>>> >>>> >>>> SYMBOL_NAME: >>>> virtualbox!UIMachineView::__**maxGuestSize+0 >>>> >>>> >>>> FOLLOWUP_NAME: MachineOwner >>>> >>>> MODULE_NAME: VirtualBox >>>> >>>> IMAGE_NAME: VirtualBox.exe >>>> >>>> DEBUG_FLR_IMAGE_TIMESTAMP: 51420e3b >>>> >>>> FAILURE_BUCKET_ID: >>>> >>>> STATUS_BREAKPOINT_80000003___**VirtualBox.exe!UIMachineView::** >>>> __maxGuestSize >>>> >>>> >>>> BUCKET_ID: >>>> >>>> APPLICATION_FAULT_STATUS___**BREAKPOINT_NULL_POINTER_READ__** >>>> _virtualbox!UIMachineView::__**maxGuestSize+0 >>>> >>>> >>>> WATSON_STAGEONE_URL: >>>> http://watson.microsoft.com/__**StageOne/VirtualBox_exe/4_2_8_* >>>> *__0/51420e3b/unknown/0_0_0_0/_**_bbbbbbb4/80000003/00000000.__** >>>> htm?Retriage=1<http://watson.microsoft.com/__StageOne/VirtualBox_exe/4_2_8___0/51420e3b/unknown/0_0_0_0/__bbbbbbb4/80000003/00000000.__htm?Retriage=1> >>>> >>>> <http://watson.microsoft.com/**StageOne/VirtualBox_exe/4_2_8_** >>>> 0/51420e3b/unknown/0_0_0_0/**bbbbbbb4/80000003/00000000.** >>>> htm?Retriage=1<http://watson.microsoft.com/StageOne/VirtualBox_exe/4_2_8_0/51420e3b/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1> >>>> > >>>> >>>> >>>> Followup: MachineOwner >>>> --------- >>>> >>> >>> >>> -- >>> ORACLE Deutschland B.V. & Co. KG Michael Thayer >>> Werkstrasse 24 VirtualBox engineering >>> 71384 Weinstadt, Germany >>> mailto:michael.thayer@oracle.**com<[email protected]> >>> >>> Hauptverwaltung: Riesstr. 25, D-80992 München >>> Registergericht: Amtsgericht München, HRA 95603 >>> Geschäftsführer: Jürgen Kunz >>> >>> Komplementärin: ORACLE Deutschland Verwaltung B.V. >>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >>> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher >>> >> >> >> >> -- >> -- Ribhi >> > > > > -- > -- Ribhi > -- -- Ribhi
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
