主页哟偶哦 Sent from my BlackBerry 10 smartphone on the Rogers network. Original Message From: vbox-dev-requ...@virtualbox.org Sent: Monday, February 23, 2015 7:00 AM To: vbox-dev@virtualbox.org Reply To: vbox-dev@virtualbox.org Subject: vbox-dev Digest, Vol 100, Issue 27
Send vbox-dev mailing list submissions to vbox-dev@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-requ...@virtualbox.org You can reach the person managing the list at vbox-dev-ow...@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.mehn...@oracle.com> Subject: Re: [vbox-dev] Virtualbox build failure with gcc 5-20150205 [partial PATCH included] To: vbox-dev@virtualbox.org Cc: "r...@debian.org" <r...@debian.org> Message-ID: <24151951.m9i35pTjLr@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.mehn...@oracle.com> Subject: Re: [vbox-dev] Fix 12611: VNC crash when client connects while restoring To: vbox-dev@virtualbox.org Message-ID: <74988475.sRIJn0sF2j@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@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev End of vbox-dev Digest, Vol 100, Issue 27 ***************************************** _______________________________________________ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev
