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 hardened
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 harde
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 year
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 fr
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
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,
>
>
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 course). Assertions can be
> made
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
prefe
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 th
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 as
10 matches
Mail list logo