No it doesn't from what I remember. Env variables are not available in
kernel context. This means that unless on Windows you really like BSODs
(or have set up kernel debugging) or on the other platforms like panics
(or where applicable have set up kernel debugging) you really should go
for release builds of the kernel components. Not all of them are
executed in the context of a VM.

Klaus

On 11.04.2018 11:51, Michael Thayer wrote:
> 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
>>
>>
> 
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev

Reply via email to