Hello Ribhi, Thanks for your testing. I passed on the information about these two crashes to people who might know, though I am not sure how much they will be able to do with it. My fix should be part of any future 4.1 and later releases.
Regards, Michael On 19/04/13 22:53, Ribhi Kamal 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 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] > <mailto:[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] <mailto:[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:[email protected]> > <mailto:michael.thayer@oracle.__com > <mailto:[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]>> > <mailto:[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]>> > <mailto:[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]>> > <mailto:[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> > <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 > <mailto:[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 -- ORACLE Deutschland B.V. & Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:[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 _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
