[vbox-dev] VirtualBox official debug builds/debug symbols
Samuel Rats
srats at genymobile.com
Wed Apr 18 10:09:23 GMT 2018
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 <knut.osmundsen at oracle.com>:
> 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.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
>>>>>
>>>>>
>>> _______________________________________________
>>> vbox-dev mailing list
>>> vbox-dev at virtualbox.org
>>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>>
>
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> 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
More information about the vbox-dev
mailing list