Hi everyone. First of all, thank you all for your replies!
I have a strange behavior that is blocking me at the moment: my debug build of VBoxHeadless process is started with the root user, while it was started with the actual user with the official release build. Is this due to not using a hardened build, or am I missing something else? What I did was basically replace the official VBoxHeadless binary with my debug one. Access rights have been conserved (root:root, mode(4511)). 2018-04-13 12:16 GMT+02:00 Knut St. Osmundsen <[email protected]>: > 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 >>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]> >>>>> > <mailto:[email protected] <mailto:[email protected]>>> 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 >>>>> > [email protected] <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>> > 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 >>>>> > [email protected] <mailto:[email protected]> >>>>> > 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 >>> [email protected] >>> https://www.virtualbox.org/mailman/listinfo/vbox-dev >>> > > > _______________________________________________ > vbox-dev mailing list > [email protected] > https://www.virtualbox.org/mailman/listinfo/vbox-dev -- Samuel Rats - Design & Development Engineer Mobile: +33 6 09 51 22 26 279bis Rue de Créqui, 69007, Lyon, France www.genymobile.com _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
