VirtualBox

Opened 8 years ago

Closed 7 years ago

#16195 closed defect (fixed)

VBox crashes caused by video

Reported by: iwicfm666 Owned by:
Component: other Version: VirtualBox 5.1.8
Keywords: Cc:
Guest type: Windows Host type: other

Description

I use VirtualBox on a Dell Precision M6500 laptop. Host is Mageia 5, guest is Win7.

While at work my laptop is connected to an external monitor. I don't remember where or how I configured it, but when the external monitor is connected and I select Full Screen in VirtualBox, my Win7 VM snaps to the external monitor. That worked great in 5.0.16. I could even use xrandr to disable the external monitor, and the VM would switch between the external monitor and the laptop screen. Well, 5.1.8 not only broke that process, but every time the external monitor is enabled or disabled with xrandr, the VM would crash.

I just tested this with the latest build (5.1.9-111957), which has the same problem.

My log is attached. Please let me know if I need to recreate the log with debugging options enabled.

Attachments (2)

Win7-2016-11-17-08-27-31.log (80.2 KB ) - added by iwicfm666 8 years ago.
VBox Video Crash from 5.1.10.log (78.4 KB ) - added by iwicfm666 8 years ago.

Download all attachments as: .zip

Change History (11)

by iwicfm666, 8 years ago

comment:1 by iwicfm666, 8 years ago

5.1.10 r112026 still has this bug.

by iwicfm666, 8 years ago

comment:2 by iwicfm666, 8 years ago

To help determine which version created this problem, I wanted to install the latest 5.0 version. The D/L link for 5.0.30 is broken, so I had to D/L 5.0.28.

Note that 5.0.28 DOES NOT have this problem. I guess I'll stick with 5.0.28 for a while.

comment:3 by iwicfm666, 8 years ago

This bug applies to 5.1.8, 5.1.9 and 5.1.10. I created the ticket under 5.1.8, but I can't change the header to 5.1.10.

Why has this ticket received zero responses in 5 weeks? Is this the proper place to log bugs in VirtualBox?

Perhaps I need to open a new ticket for 5.1.10.

in reply to:  3 ; comment:4 by Socratis, 8 years ago

Replying to iwicfm666:

This bug applies to 5.1.8, 5.1.9 and 5.1.10. I created the ticket under 5.1.8, but I can't change the header to 5.1.10.

Why has this ticket received zero responses in 5 weeks? Is this the proper place to log bugs in VirtualBox?

Perhaps I need to open a new ticket for 5.1.10.

  • The "version" applies to when you noticed the bug, not if the bug is current or not.
  • Tickets don't necessarily receive replies immediately, the developers have other things to do as well, like, develop.
  • Oh, no, don't. You'll only create a duplicate which someone has to look at, evaluate it, search through the database, compare it and declare it what it is; a duplicate, aka a waste of time.
  • Finally, may I suggest something? It's usually better and faster, if problems like this one (configuration) get first addressed in the forums (https://forums.virtualbox.org/). More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of.

in reply to:  4 ; comment:5 by iwicfm666, 8 years ago

Replying to socratis:

Replying to iwicfm666:

This bug applies to 5.1.8, 5.1.9 and 5.1.10. I created the ticket under 5.1.8, but I can't change the header to 5.1.10.

Why has this ticket received zero responses in 5 weeks? Is this the proper place to log bugs in VirtualBox?

Perhaps I need to open a new ticket for 5.1.10.

  • The "version" applies to when you noticed the bug, not if the bug is current or not.

That is illogical. Since my original ticket said the problem applies to 5.1.8, someone could easily think the problem was fixed in 5.1.10.

  • Tickets don't necessarily receive replies immediately, the developers have other things to do as well, like, develop.

You do realize that bug fixing qualifies as development, don't you?

  • Finally, may I suggest something? It's usually better and faster, if problems like this one (configuration) get first addressed in the forums (https://forums.virtualbox.org/). More than 95% of the issues are resolved over there, which keeps the developers focusing on the bug fixes and enhancements, and there is no need for another ticket to keep track of.

Um, it worked in one version, but not in the next version. That is the definition of a bug. I have to downgrade in order to use the software. Again, that is the definition of a bug.

If I had changed something within my configuration, and that change broke VBox, then your point would be valid. But I didn't do that, and your point is not valid.

I will try the forums. Maybe someone there will actually help me instead of just making excuses.

in reply to:  5 comment:6 by Socratis, 8 years ago

Replying to iwicfm666:

That is illogical. Since my original ticket said the problem applies to 5.1.8, someone could easily think the problem was fixed in 5.1.10.

No, it would have been marked as "Fixed in version X.Y.Z". But if someone at a later date had the problem with 5.1.8, they wouldn't know it. In any event, the ticket version is the earliest version that this behavior was noticed, not if it's current or not. It is assumed as current, unless otherwise noted.


You do realize that bug fixing qualifies as development, don't you?

Fixing bugs, yes. Replying to reports, no, it does not qualify as developing, unless they require clarification. Maybe they're aware of the issue already, but it's not top priority.


Um, it worked in one version, but not in the next version. That is the definition of a bug. I have to downgrade in order to use the software. Again, that is the definition of a bug.

If I had changed something within my configuration, and that change broke VBox, then your point would be valid. But I didn't do that, and your point is not valid.

I'm not saying it is or it isn't a bug. I'm saying that we could be having this conversation in the forums instead of here. And it was advice in general. Since I didn't see anything in the forums, chances are that you didn't ask the question there. The chances of someone using the same setup as your are much higher there. The forums have a much larger audience with the experience to point you to escalate the issue if need be.


I will try the forums. Maybe someone there will actually help me instead of just making excuses.

Please do not come with that attitude in the forums, it won't be very fruitful I'm afraid.

comment:7 by Simon Coleman, 7 years ago

I would consider this the same defect as I reported in #16240 where the host is win10. This was thought to be fixed in 5.1.14 & I agree the behaviour for fullscreen guests with external monitors is much improved, although snap back on re-attach is not important to me.

I have just added further detail, since similar problems [guest aborting] continue to occur with guests utilising multiple monitors & where the host locks (probably will occur whenever the host changes the underlying monitor count).

[Aside: The OP was querying whether the lack of responses could be down to it being recorded under an older version & whether he should re-report it correctly, but if the bug report isn't being read then its also not the best place to ask the question]

comment:8 by Simon Coleman, 7 years ago

After several releases, now appears fixed in 5.1.24 - please retest!

comment:9 by Frank Mehnert, 7 years ago

Resolution: fixed
Status: newclosed

Thanks! Please reopen if still relevant with 5.1.24.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use