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.tha...@oracle.com <mailto:michael.tha...@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 <sr...@genymobile.com
>     <mailto:sr...@genymobile.com>
>     > <mailto:sr...@genymobile.com <mailto:sr...@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@virtualbox.org <mailto:vbox-dev@virtualbox.org>
>     <mailto:vbox-dev@virtualbox.org <mailto:vbox-dev@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@virtualbox.org <mailto:vbox-dev@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
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev

Reply via email to