[vbox-dev] null pointer in macGuestSize
Michael Thayer
michael.thayer at oracle.com
Thu Apr 25 10:36:32 GMT 2013
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 <rbhkamal at gmail.com
> <mailto:rbhkamal at gmail.com>> 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
> <michael.thayer at oracle.com <mailto:michael.thayer at oracle.com>> 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
> <michael.thayer at oracle.com
> <mailto:michael.thayer at oracle.com>
> <mailto:michael.thayer at oracle.__com
> <mailto:michael.thayer at oracle.com>>> 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
> <rbhkamal at gmail.com <mailto:rbhkamal at gmail.com>
> <mailto:rbhkamal at gmail.com <mailto:rbhkamal at gmail.com>>
> <mailto:rbhkamal at gmail.com
> <mailto:rbhkamal at gmail.com> <mailto:rbhkamal at gmail.com
> <mailto:rbhkamal at gmail.com>>>> 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
> <rbhkamal at gmail.com <mailto:rbhkamal at gmail.com>
> <mailto:rbhkamal at gmail.com <mailto:rbhkamal at gmail.com>>
> <mailto:rbhkamal at gmail.com
> <mailto:rbhkamal at gmail.com> <mailto:rbhkamal at gmail.com
> <mailto:rbhkamal at gmail.com>>>> 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
> <rbhkamal at gmail.com <mailto:rbhkamal at gmail.com>
> <mailto:rbhkamal at gmail.com <mailto:rbhkamal at gmail.com>>
> <mailto:rbhkamal at gmail.com
> <mailto:rbhkamal at gmail.com>
>
> <mailto:rbhkamal at gmail.com
> <mailto:rbhkamal at gmail.com>>>> 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 at oracle.__com
> <mailto:michael.thayer at oracle.com>
>
> 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:michael.thayer at oracle.com
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
More information about the vbox-dev
mailing list