[vbox-dev] VirtualBox official debug builds/debug symbols
Michael Thayer
michael.thayer at oracle.com
Wed Apr 11 09:51:49 GMT 2018
I would not be able to answer that properly without investigation. I
expect that it does, but that you need to work out how to pass that
variable to the driver. (In Linux a module parameter might do it. The
source code will know.)
Regards
Michael
11.04.2018 11:17, Mihai Hanor wrote:
> Hi,
>
> Does VBOX_ASSERT=no affect kernel mode assertions?
>
> Regards,
> Mihai
>
> On Wed, Apr 11, 2018 at 11:30 AM, Michael Thayer
> <michael.thayer at oracle.com <mailto:michael.thayer at oracle.com>> wrote:
>
> Hello Both,
>
> On the whole the debug build should be usable for day to day work for a
> developer (not for an innocent person of course). Assertions can be
> made non-fatal by either running in the debugger ("gdb VBoxSVC" in one
> terminal and "gdb --args VirtualBox --startvm ..." in another) - the
> preferred option - or setting the environment variable VBOX_ASSERT=no.
> See the source file src/VBox/Runtime/VBox/RTAssertShouldPanic-vbox.cpp.
> I must admit that I was never happy with the "gdb" option, to the extent
> that I added the "wait" option for myself, but feel free to experiment.
>
> I would certainly recommend trying to investigate using a debug version.
> That said, you can also build your own release version. Building with
> "VBOX_WITHOUT_HARDENING=1" set will probably make you happier either
> way.
>
> Regards
> Michael
>
> 10.04.2018 22:35, Mihai Hanor wrote:
> > Hi Samuel,
> >
> > The VirtualBox debug build is not for regular usage. The debug build
> > runs unoptimized code and some of its code paths may differ from a
> > release build. This includes debug assertions, that will stop your
> VM or
> > even the host OS without warning, if they trigger. On Windows, at
> least,
> > an assert in the VirtualBox kernel driver will stop your OS with a
> BSOD
> > -- I don't know how the Linux kernel handles a kernel module
> fault. With
> > a debug build, it may even be harder or impossible to reproduce a
> > scenario. You can use the official build to see where it crashes, then
> > use a self-build release build to obtain a detailed stack trace,
> if the
> > crash is in VirtualBox code. From this point forward, it depends
> on the
> > issue and your skills.
> >
> > Best regards,
> > Mihai
> >
> > On Tue, Apr 10, 2018 at 6:31 PM, Samuel Rats <srats at genymobile.com
> <mailto:srats at genymobile.com>
> > <mailto:srats at genymobile.com <mailto:srats at genymobile.com>>> wrote:
> >
> > Hi VBox people!
> >
> > In order to investigate an issue I recently opened
> > (https://www.virtualbox.org/ticket/17644
> <https://www.virtualbox.org/ticket/17644>
> > <https://www.virtualbox.org/ticket/17644
> <https://www.virtualbox.org/ticket/17644>>), I was looking for some
> > official debug builds of the VirtualBox package, but couldn't
> manage
> > to find any.
> > Even the "testing" builds are release build.
> >
> > Can I find them somewhere, or should I build VirtualBox in debug
> > mode myself?
> > Additional question, do you know if the debug build is of
> VirtualBox
> > is much slower than a release build, or is it still usable for
> > days-to-days operations?
> >
> > This issue is really bothering us, and I have time to
> > investigate/fix it.
> > Thanks in advance.
> >
> > --
> > Samuel Rats
> > _______________________________________________
> > vbox-dev mailing list
> > vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
> <mailto:vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>>
> > https://www.virtualbox.org/mailman/listinfo/vbox-dev
> <https://www.virtualbox.org/mailman/listinfo/vbox-dev>
> > <https://www.virtualbox.org/mailman/listinfo/vbox-dev
> <https://www.virtualbox.org/mailman/listinfo/vbox-dev>>
> >
> >
> >
> >
> > _______________________________________________
> > vbox-dev mailing list
> > vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
> > https://www.virtualbox.org/mailman/listinfo/vbox-dev
> <https://www.virtualbox.org/mailman/listinfo/vbox-dev>
> >
>
> --
> Michael Thayer | VirtualBox engineer
> ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstraße 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
> der Handelskammer Midden-Nederland, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
>
--
Michael Thayer | VirtualBox engineer
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt
ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister
der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
More information about the vbox-dev
mailing list