Opened 6 years ago
Closed 6 years ago
#18048 closed defect (fixed)
"SUPLIB not initiated successfully" with --disable-hardening --build-debug ==> fixed in SVN
| Reported by: | Cake | Owned by: | |
|---|---|---|---|
| Component: | VMM | Version: | VirtualBox 5.2.18 |
| Keywords: | Cc: | ||
| Guest type: | Windows | Host type: | Linux |
Description
In VirtualBox-5.2.18/src/VBox/VMM/VMMR3/VM.cpp
- Line 212 calls VMR3GlobalInit, which eventually ends up calling suplibOsIOCtl.
- Line 238 calls SUPR3Init, which is too late.
The VM starts when I call SUPR3Init(NULL) earlier. I attached a patch, but I assume you will know how to fix it better.
I see someone else has experienced this issue before: https://forums.virtualbox.org/viewtopic.php?f=10&t=84300
Attachments (3)
Change History (4)
by , 6 years ago
| Attachment: | VBox.log.1 added |
|---|
by , 6 years ago
| Attachment: | sup-backtrace.txt added |
|---|
by , 6 years ago
| Attachment: | initialize-sup.patch added |
|---|
comment:1 by , 6 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
| Summary: | "SUPLIB not initiated successfully" with --disable-hardening --build-debug → "SUPLIB not initiated successfully" with --disable-hardening --build-debug ==> fixed in SVN |
Note:
See TracTickets
for help on using tickets.
This shouldn't normally happen if vboxdrv is working an accessible and the application called RTR3InitExe w/ RTR3INIT_FLAGS_SUPLIB, however I see it could be annoying, so I've moved the probe initialization down till after the SUPR3Init call. The changes will make it out to SVN before long, I hope.