Hi all. The VBOX_ASSERT=no environment variable only works for ring-3 code and will not be picked up by kernel drivers or raw-mode.
The risk of hitting an assertion in the kernel drivers is reasonably low these days. I run debug everything all the time and haven't seen any spurious BSODs for years (I'm not counting the times I modified the drivers and are testing the modifications). That said, we could probably make it possible to disable them in a similar manner as SUPLoggerCtl uses. However, we're a bit busy at the moment (or at least I am) so, that may take a while to surface. -bird. On 2018-04-12 8:09 AM, Michael Thayer wrote: > Indeed. We have an API function RTAssertSetMayPanic() which is > available in the support driver but with no way of triggering it. Might > make sense to add something, on the lines of > SUP_IOCTL_LOGGER_SETTINGS/SUPLoggerCtl. > > Regards > Michael > > 11.04.2018 20:48, Klaus Espenlaub wrote: >> 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 >> _______________________________________________ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev