VirtualBox

Ticket #1192 (closed defect: worksforme)

Opened 6 years ago

Last modified 4 years ago

Random crashes of VBox also crashing the X server

Reported by: ugemkow Owned by:
Priority: major Component: other
Version: VirtualBox 1.5.4 Keywords:
Cc: Guest type: other
Host type: other

Description

We are using VBox on linux host (fedora 6 based, vanilla kernel 2.6.22) with Windows XP guest. We have added own compiled X drivers (radeon, intel) with xrandr 1.2 enabled.

We see on different notebooks (Thinkpad R51, 52 - single core processor and Thinkpad R60 - dual core) regular crashes of VBox where also the X server crashes. The crash often happens after a few secondes, sometimes without even doing something in the guest. On other machines, no single crash was observed.

We tried the OSE version and the provided binaries, we tried the debug and the release build of the OSE version. The log files did not contain any useful information.

I am aware that this is not a very helpful bug report but I found no pattern which would produce more information. It seems that the SMP (dual core) machines had more problemes but this is not really significant.

I cannnot say whether this problem is caused by the own compiled video drivers but only when using VBox there are problems. Unfortunately I cannot use the distro provided drivers for difficult reasons.

Change History

comment:1 Changed 6 years ago by michael

Could you check to see if this still persists when you disable the shared clipboard for the VM you are running?

comment:2 Changed 6 years ago by ugemkow

Yes, we tried this and the crashes happen also with the clipboard disabled.

comment:3 Changed 6 years ago by ugemkow

This problem still exists in 1.5.6. I have to give up now - For us VBox is unfortunately not usable because of its various stability problems. Without this it would be a great product.

comment:4 follow-up: ↓ 5 Changed 6 years ago by sandervl73

Why don't you try the distro display drivers as a test? Such instability can be caused by a variety of things. Buggy Qt themes are a known issue.

With so little information to go on it's rather hard to say anything meaningful. It's rather premature to point the finger at us right now as you're the only one reporting such issues (with 1.5.6).

comment:5 in reply to: ↑ 4 Changed 6 years ago by ugemkow

Replying to sandervl73:

Why don't you try the distro display drivers as a test? Such instability can be caused by a variety of things. Buggy Qt themes are a known issue.

We cannot use the distro drivers because they do not support our hardware (Notebooks with varying external displays)

With so little information to go on it's rather hard to say anything meaningful. It's rather premature to point the finger at us right now as you're the only one reporting such issues (with 1.5.6).

I really understand how difficult it is to act on this bug report - but I cannot give more info. I conviced about 15 collegues to report all circumstances of these crashes and we found no pattern which would give a hint in which direction to search. The same crashes happen with VBoxSDL, so qt seems to be not guilty.

No other program causes such crashes, only VBox. So I can only conclude that VBox does "something" which brings the X server in trouble. If you can give me a hint what to test I would be more the happy to do so.

comment:6 Changed 6 years ago by michael

Can you get a backtrace of the X server crash? I don't know the details of how to do this in Fedora 6, but if set up correctly, the X server will print the backtrace into its log file /var/log/Xorg.*.log) when it crashes. Obviously you have a rather uncommon setup, as I suspect that very few people are using RandR 1.2 with Fedora 6, and we are rather dependent on the information that you can provide us regarding this issue.

comment:7 Changed 6 years ago by frank

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

No response, closing.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use