[vbox-dev] vbox-dev Digest, Vol 100, Issue 27
hedonghust at gmail.com
hedonghust at gmail.com
Mon Feb 23 13:03:14 GMT 2015
主页哟偶哦
Sent from my BlackBerry 10 smartphone on the Rogers network.
Original Message
From: vbox-dev-request at virtualbox.org
Sent: Monday, February 23, 2015 7:00 AM
To: vbox-dev at virtualbox.org
Reply To: vbox-dev at virtualbox.org
Subject: vbox-dev Digest, Vol 100, Issue 27
Send vbox-dev mailing list submissions to
vbox-dev at virtualbox.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.virtualbox.org/mailman/listinfo/vbox-dev
or, via email, send a message with subject or body 'help' to
vbox-dev-request at virtualbox.org
You can reach the person managing the list at
vbox-dev-owner at virtualbox.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of vbox-dev digest..."
Today's Topics:
1. Re: Virtualbox build failure with gcc 5-20150205 [partial
PATCH included] (Frank Mehnert)
2. Re: Fix 12611: VNC crash when client connects while restoring
(Frank Mehnert)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Feb 2015 10:51:06 +0100
From: Frank Mehnert <frank.mehnert at oracle.com>
Subject: Re: [vbox-dev] Virtualbox build failure with gcc 5-20150205
[partial PATCH included]
To: vbox-dev at virtualbox.org
Cc: "rrs at debian.org" <rrs at debian.org>
Message-ID: <24151951.m9i35pTjLr at noys2>
Content-Type: text/plain; charset="iso-8859-1"
Hi Gianfranco,
On Saturday 14 February 2015 18:25:35 Gianfranco Costamagna wrote:
> I'm sending you a patch to make virtualbox "build" against gcc-5
> (upcoming release, not yet stable.)
>
> As usual my work has to be considered MIT licensed.
actually I had the same idea yesterday evening to use the gcc-5 snapshot
packages which were recently added to Debian/Experimental to compile the
VBox code and later I saw your mail :-)
> I'm not quite confortable with the patch, but I'm happy to share it with you
> (I don't attach a file because as said I'm not quite confortable)
>
>
> 1) usual configure changes (don't know the gcc upper bound)
We will do this change later. Right now gcc 5 is not stable and we
don't want to encourage people to use gcc 5 to compile VBox to not
get false reports.
> 2) three changes because gcc doesn't exactly know how to handle parenthesis
> (not gcc-5 specific, I guess it is spotted because of some "Wparenthesis"
> build flag that gcc-5 defaults to true)
>
> --- a/src/VBox/Runtime/common/asn1/asn1-ut-bitstring.cpp
> +++ b/src/VBox/Runtime/common/asn1/asn1-ut-bitstring.cpp
> @@ -77,7 +77,7 @@ static DECLCALLBACK(int)
> rtAsn1BitStringEncodeCompare(const void *pvBuf, size_t {
> RTASN1BITSTRINGWRITERCTX *pCtx = (RTASN1BITSTRINGWRITERCTX *)pvUser;
> AssertReturn(cbToWrite <= pCtx->cbBuf - pCtx->offBuf, VERR_BUFFER_OVERFLOW);
> - if (!memcmp(&pCtx->pbBuf[pCtx->offBuf], pvBuf, cbToWrite) != 0) +
> if (!memcmp(&pCtx->pbBuf[pCtx->offBuf], pvBuf, cbToWrite))
> return VERR_NOT_EQUAL;
> pCtx->offBuf += (uint32_t)cbToWrite;
> return VINF_SUCCESS;
>
>
> --- a/src/VBox/Runtime/common/asn1/asn1-ut-octetstring.cpp
> +++ b/src/VBox/Runtime/common/asn1/asn1-ut-octetstring.cpp
> @@ -77,7 +77,7 @@ static DECLCALLBACK(int)
> rtAsn1OctetStringEncodeCompare(const void *pvBuf, size_ {
> RTASN1OCTETSTRINGWRITERCTX *pCtx = (RTASN1OCTETSTRINGWRITERCTX *)pvUser;
> AssertReturn(cbToWrite <= pCtx->cbBuf - pCtx->offBuf, VERR_BUFFER_OVERFLOW);
> - if (!memcmp(&pCtx->pbBuf[pCtx->offBuf], pvBuf, cbToWrite) != 0) +
> if (!memcmp(&pCtx->pbBuf[pCtx->offBuf], pvBuf, cbToWrite))
> return VERR_NOT_EQUAL;
> pCtx->offBuf += (uint32_t)cbToWrite;
> return VINF_SUCCESS;
Both your fixes are correct and were committed to the repository. Most
likely this code is not used anyway.
> --- a/src/VBox/Runtime/common/zip/tarvfs.cpp
> +++ b/src/VBox/Runtime/common/zip/tarvfs.cpp
> @@ -366,7 +366,7 @@ static int rtZipTarHdrValidate(PCRTZIPTARHDR pTar,
> PRTZIPTARTYPE penmType) {
> case RTZIPTARTYPE_POSIX:
> if ( !RT_C_IS_ALNUM(pTar->Common.typeflag)
> - && !pTar->Common.typeflag == '\0')
> + && pTar->Common.typeflag != '\0') (maybe we can even remove
> the !='\0) return VERR_TAR_UNKNOWN_TYPE_FLAG;
> break;
Correct, committed.
> 3) a build failure that goes away without the "-O" flag, but needs to be
> fixed :) (I do not have time/knowledge/resources to properly fix this)
>
> [...]
> /virtualbox-4.3.22-dfsg/src/libs/xpcom18a4/xpcom/reflect/xptcall/src/md/uni
> x/xptcinvoke_x86_64_linux.cpp:211:1: error: unable to find a register to
> spill }
> ^
> [...]
That one will be more complicated and so far it looks to me like a regression
in gcc.
> 4) there are two "while (iPage-- > 0)" loops
We fixed this properly.
There are a few more problems lurking in the code. A few will be fixed soon.
As I said, we will keep an eye on gcc-5-related problems but fixing them is
currently not top-priority.
Thank you,
Frank
--
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany
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
------------------------------
Message: 2
Date: Mon, 23 Feb 2015 12:27:14 +0100
From: Frank Mehnert <frank.mehnert at oracle.com>
Subject: Re: [vbox-dev] Fix 12611: VNC crash when client connects
while restoring
To: vbox-dev at virtualbox.org
Message-ID: <74988475.sRIJn0sF2j at noys2>
Content-Type: text/plain; charset="ISO-8859-1"
Hi Yonathan,
On Friday 13 February 2015 15:22:55 Yonathan wrote:
> We would like to contribute this patch for bug
> https://www.virtualbox.org/ticket/12611 under the MIT license. It
> fixes a crash in the VNC Extension of VirtualBoxVM when a VNC client
> connects while VirtualBox is still restoring saved state. The fix is
> to allocate a frame buffer of arbitrary size within
> VRDEEnableConnections that the VNC thread will use until VRDEResize.
>
> Background: This is the standard sequence of events at VM startup:
>
> 1. VirtualBox calls extension entry point VRDECreateServer.
>
> 2. VirtualBox calls extension entry point VRDEEnableConnections, which
> listens for connections and starts VNC server thread.
>
> 3. VirtualBox calls extension entry point VRDEResize. Extension calls
> the callback VRDECallbackFramebufferQuery to obtain the new size and
> screen buffer, and allocates a frame buffer according to this size.
>
> 4. VirtualBox calls extension entry point VRDEUpdate whenever the
> pixels in the screen buffer change, and extension will copy the pixels
> from screen buffer to frame buffer.
>
> There can be a significant time between steps 2 and 3 (e.g., when
> VirtualBox has to restore saved state). If a VNC client happens to
> connect during that gap, then the VNC server tries to copy pixel data
> from the frame buffer to the client. Since the frame buffer was NULL
> at this point, this resulted in SEGV in the VNC event loop thread.
> Sample stack trace:
>
> Exception Type: EXC_BAD_ACCESS (SIGSEGV)
> Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
>
> Thread 41 Crashed:
> 0 libsystem_c.dylib 0x00007fff8bc9c9e7 memmove$VARIANT$sse42 + 31
> 1 libvncserver.0.dylib 0x000000010d3b5c73 rfbTranslateNone + 59
> 2 libvncserver.0.dylib 0x000000010d3b497d rfbSendRectEncodingHextile + 4630
> 3 libvncserver.0.dylib 0x000000010d3ae07e rfbSendFramebufferUpdate + 3314
> 4 libvncserver.0.dylib 0x000000010d3a92fb clientOutput + 320
> 5 libsystem_c.dylib 0x00007fff8bcaf742 _pthread_start + 327
> 6 libsystem_c.dylib 0x00007fff8bc9c181 thread_start + 13
thank you for this patch. I've just applied a slightly modified version
of your patch to the repository. The next 4.3.x maintenance release will
contain the fix as well.
Kind regards,
Frank
--
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany
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
------------------------------
_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
End of vbox-dev Digest, Vol 100, Issue 27
*****************************************
More information about the vbox-dev
mailing list