[vbox-dev] null pointer in macGuestSize
Ribhi Kamal
rbhkamal at gmail.com
Fri Apr 19 20:53:15 GMT 2013
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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130419/110a2291/attachment.html>
-------------- next part --------------
0:000> !analyze -f -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** ERROR: Symbol file could not be found. Defaulted to export symbols for QtCore4.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for QtGui4.dll -
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/VirtualBox_exe/4_2_8_0/51718c49/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1
FAULTING_IP:
msvcr100!_VEC_memcpy+f2
6b270a21 8917 mov dword ptr [edi],edx
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 00000164
DEFAULT_BUCKET_ID: INVALID_POINTER_READ
PROCESS_NAME: VirtualBox.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - 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 69a92b0b to 6b270a21
PRIMARY_PROBLEM_CLASS: INVALID_POINTER_READ
BUGCHECK_STR: APPLICATION_FAULT_INVALID_POINTER_READ_STATUS_BREAKPOINT
STACK_TEXT:
0565f834 6b270a21 msvcr100!_VEC_memcpy+0xf2
0565f84c 69a92b0b vboxdd!vga_draw_line32_32+0x1b
0565f860 69a97134 vboxdd!vgaPortCopyRect+0x184
0565f88c 69f9d39d vboxc!Display::displayVBVAUpdateProcess+0xed
0565f8f0 69aec40f vboxdd!vbvaFlush+0xbf
0565f93c 69aeddca vboxdd!vbvaChannelHandler+0x17a
0565f964 69b490be vboxdd!HGSMIBufferProcess+0x6e
0565f984 69aee48a vboxdd!HGSMIGuestWrite+0x1a
0565f998 69a945cb vboxdd!vgaR3IOPortHGSMIWrite+0x4b
0565f9b0 6a9498d1 vboxvmm!IOMIOPortWrite+0x91
0565f9d8 6a93891f vboxvmm!HWACCMR3RestartPendingIOInstr+0xcf
0565f9f8 6a8d303c vboxvmm!emR3ExecuteIOInstruction+0x1c
0565facc 6a8d3589 vboxvmm!emR3HwaccmHandleRC+0x189
0565fae0 6a8d3788 vboxvmm!emR3HwAccExecute+0x168
0565fb04 6a8d0d84 vboxvmm!EMR3ExecuteVM+0x274
0565fb2c 6a92b2aa vboxvmm!vmR3EmulationThreadWithId+0x45a
0565fb4c 6a92b2f4 vboxvmm!vmR3EmulationThread+0x14
0565fb60 6a751523 vboxrt!rtThreadMain+0x33
0565fb8c 6a79539b vboxrt!rtThreadNativeMain+0x6b
0565fbac 6b2bc556 msvcr100!_endthreadex+0x3f
0565fbe4 6b2bc600 msvcr100!_endthreadex+0xce
0565fbf0 755ced6c kernel32!BaseThreadInitThunk+0xe
0565fbfc 7714377b ntdll!__RtlUserThreadStart+0x70
0565fc3c 7714374e ntdll!_RtlUserThreadStart+0x1b
STACK_COMMAND: .cxr 000000000565F550 ; kb ; dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; dds 565f834 ; kb
FOLLOWUP_IP:
msvcr100!_VEC_memcpy+0
6b2709f9 57 push edi
SYMBOL_NAME: msvcr100!_VEC_memcpy+0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: msvcr100
IMAGE_NAME: msvcr100.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4d5f0c22
FAILURE_BUCKET_ID: INVALID_POINTER_READ_80000003_msvcr100.dll!_VEC_memcpy
BUCKET_ID: APPLICATION_FAULT_INVALID_POINTER_READ_STATUS_BREAKPOINT_msvcr100!_VEC_memcpy+0
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/VirtualBox_exe/4_2_8_0/51718c49/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1
Followup: MachineOwner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.2.12-withfix-withmymodification.log
Type: application/octet-stream
Size: 5827 bytes
Desc: not available
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130419/110a2291/attachment.obj>
More information about the vbox-dev
mailing list