Re: [vbox-dev] VirtualBox official debug builds/debug symbols

Samuel, you're using a non-hardened build (which is meant for direct use by a developer, generally straight from out//bin, not for installing system-wide) with the same permissions as a hardened build (i.e. suid root). This explains why the result ends up running as root, because only

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

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

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

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

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

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

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

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

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

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, >

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

Hi, Does VBOX_ASSERT=no affect kernel mode assertions? Regards, Mihai On Wed, Apr 11, 2018 at 11:30 AM, Michael Thayer 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

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

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

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

On Tue, 10 Apr 2018 23:35:12 +0300, Mihai Hanor said: > 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. Are

Re: [vbox-dev] VirtualBox official debug builds/debug symbols

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

[vbox-dev] VirtualBox official debug builds/debug symbols

Hi VBox people! In order to investigate an issue I recently opened (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