[vbox-dev] null pointer in macGuestSize

Ribhi Kamal rbhkamal at gmail.com
Fri Apr 19 13:56:09 PDT 2013


Correction:
I modified VirtualBox GUI to* NOT *show close dialog.


On Fri, Apr 19, 2013 at 4:53 PM, Ribhi Kamal <rbhkamal at gmail.com> 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 <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> 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<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>>> 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>>>
>>>> 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>>> 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 at oracle.**com<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
>



-- 
-- Ribhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130419/c4091b1e/attachment-0001.html 


More information about the vbox-dev mailing list