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
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
