[vbox-dev] null pointer in macGuestSize

Michael Thayer michael.thayer at oracle.com
Thu Apr 18 07:10:19 PDT 2013


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>> 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>
>                      Crash:
>         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>
>
>
>                      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>
>
>
>                      Followup: MachineOwner
>                      ---------


-- 
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