VirtualBox

Ticket #7064 (closed defect: fixed)

Opened 4 years ago

Last modified 5 months ago

Virtualbox crash in QtGuiVBox4!QWidget::repaint+0x5dcb

Reported by: mhanor Owned by:
Priority: major Component: GUI
Version: VirtualBox 3.2.10 Keywords:
Cc: Guest type: Windows
Host type: Windows

Description (last modified by frank) (diff)

I can reproduce the crash every time I attempt to do it.

Host OS: Windows XP SP3 32 bit
Guest OS: Windows XP SP3 32 bit, GA installed, 2D/3D disabled, (VT-x enabled or disabled, it doesn't matter)

I've first encountered the crash by mistake (switching between 2 VM windows at the right moment) while playing with VB 3.2.6 beta.
VB 3.2.4 and VB 3.2.6.r63112 are also affected.

Steps:

  1. Start the guest OS, let it load
  2. Shutdown the XP guest (ACPI shutdown). While it does that, switch back and forth between the VM window and some other window covering the first (of another program or it can be another VM window, it's your choice). Or you can continuously minimize and maximize the VM window (click the VM window's taskbar button).

Approximately 2 cycles of minimize/maximize (or 4-6 window switching) per second are enough, just click the VM window's taskbar button to do that, while the guest is shutting down.

Attachments

QtGuiVBox4_repaint.zip Download (20.6 KB) - added by mhanor 4 years ago.
VB 3.2.6.r63112
Windows XP 3D-2010-10-05-00-31-32.log Download (65.3 KB) - added by Technologov 4 years ago.
VBox Log of WinXP guest, after crashed-on-close
103e0000 becomes available to the user process.txt Download (4.0 KB) - added by mhanor 3 years ago.
svn 36094
crash.txt Download (6.9 KB) - added by mhanor 3 years ago.
the call stack backtraces are taked in different VB run sessions
normal_operation.txt Download (35.4 KB) - added by mhanor 3 years ago.
crash2.txt Download (6.8 KB) - added by mhanor 3 years ago.
windbg.log Download (31.6 KB) - added by mhanor 3 years ago.
103e0000 gets freed

Change History

Changed 4 years ago by mhanor

VB 3.2.6.r63112

comment:1 Changed 4 years ago by mhanor

please, can someone put the missing tags/spaces

comment:2 Changed 4 years ago by Technologov

+1. I also experience such crashes.

Host: Windows XP + VBox 3.2.6-BETA2 (also tried VBox 3.2.0).

-Technologov

comment:3 Changed 4 years ago by frank

  • Description modified (diff)

comment:4 Changed 4 years ago by Dsen

Should be fixed. Please tell me if not.

comment:5 Changed 4 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Please reopen if still relevant with VBox 3.2.8.

comment:6 Changed 4 years ago by mhanor

Are you sure that old 3.2.8.r64453 contains the fix? I can still crash it.

comment:7 Changed 4 years ago by Technologov

  • Status changed from closed to reopened
  • Resolution fixed deleted

mhanor: Sometimes they fix a related bug and hope that this one was fixed "along the way".

However in this case it still crashes (after 3rd try, which makes this bug a "sometimes reproducible".)

Reopened.

-Technologov

comment:8 Changed 4 years ago by Technologov

Host: Windows XP + VBox 3.2.8

Changed 4 years ago by Technologov

VBox Log of WinXP guest, after crashed-on-close

comment:9 Changed 4 years ago by mhanor

it requires more aggressive window switching

comment:10 Changed 4 years ago by mhanor

that is, if you want to reproduce it

comment:11 Changed 4 years ago by frank

  • Component changed from other to GUI

comment:12 Changed 4 years ago by mhanor

no change from 3.2.8 to 3.2.10

comment:13 Changed 3 years ago by frank

  • Version changed from VirtualBox 3.2.6 to VirtualBox 3.2.10

comment:14 Changed 3 years ago by mhanor

apparently, the guest additions have nothing to do with this crash... VB 4.0 beta1 crashes without having GA installed, same setup

comment:15 Changed 3 years ago by mhanor

VB crashes when it tries to write to the guest video memory, address 0x103e0000 and size 08000000 (128*220) in my examples. Usually, the address is the same at every VB run (that helped me). I've only set guest vram to 128MB to better identify it, it's the same thing with 16/22MB. You'll have to ignore the weird parameters windbg displays for qt_blend_rgb32_on_rgb32. I've compared the top of the crash raw call stack with other call stacks (taken during normal operation), and they are similar. It always happens when it enters MSVCR100 memcpy code (maybe the dll was compiled with FPO enabled). I've also attached a call stack backtrace, for qt_blend_rgb32_on_rgb32, during normal operation, running with similar parameters. I have yet to find out how to catch the release of 0x103e0000 memory segment, to show you what thread 0 is doing in the VirtualBox.exe process, while I try to crash it.

Again, no guest additions are not involved. Only a fresh installed XP SP3 32 bit is required.

Changed 3 years ago by mhanor

svn 36094

Changed 3 years ago by mhanor

the call stack backtraces are taked in different VB run sessions

Changed 3 years ago by mhanor

comment:16 Changed 3 years ago by mhanor

The first line from "103e0000 becomes available to the user process.txt" is manually pasted there, it was displayed by the QtGui4 after 103e0000 became available, it was displayed by a qt_blend_rgb32_on_rgb32 call.

Changed 3 years ago by mhanor

comment:17 Changed 3 years ago by mhanor

crash2.txt contains the proper interpretation of the call stack backtrace, right before it crashes (the crash is imminent), caught it with an assert on the content of the first byte of 0x103e0000.

comment:18 Changed 3 years ago by mhanor

EMT thread give command to the driver, to release 103e0000, while thread 0 is still processing events, redraws the windows, etc.

Changed 3 years ago by mhanor

103e0000 gets freed

comment:19 Changed 3 years ago by mhanor

VB 4.0.6 still crashes. Duplicates: #8397 #8400

comment:20 Changed 2 years ago by frank

Still relevant with VBox 4.1.6?

comment:21 Changed 2 years ago by mhanor

Unfortunately, yes...

comment:22 Changed 5 months ago by mhanor

You can close this ticket. I can't reproduce the issue, anymore.

comment:23 Changed 5 months ago by frank

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Description modified (diff)

Thanks!

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use