Ticket #9011 (closed defect: fixed)

Opened 7 years ago

Last modified 6 years ago

Linux Guest on Windows Host with 1 virtual CPU freezes after randomly, often after 24 hours

Reported by: vensasa Owned by:
Priority: major Component: other
Version: VirtualBox 4.0.4 Keywords:
Cc: Guest type: Linux
Host type: Windows


I have 32-bit Ubuntu Linux running inside Virtualbox on a Windows 7 64 bit host. Host system is an AMD Athlon II X2 dual core system. One virtual CPU is configured in the VM. After an amount of time, often 12 to 24 hours, the VM will completely freeze up. This includes no mouse or keyboard activity apparently getting through, the guest display locking up. This sometimes is preceded by a period of sluggish perfomance. the system often slows down and then completely locks up. When the lock up occurs, no disk activity indicator on the virtual box window does not flash or light up, although there is activity on the disk indicator as the system begins to slow down. I am posting the log files.


linux-2011-05-17-08-30-55.log Download (57.7 KB) - added by vensasa 7 years ago.
linux-2011-05-18-11-01-38.log Download (93.1 KB) - added by vensasa 7 years ago.
linux-2011-05-19-07-51-53.log Download (160.4 KB) - added by vensasa 7 years ago.
linux-2011-05-19-20-54-09.log Download (63.4 KB) - added by vensasa 7 years ago.
linux-2011-05-19-21-10-08.log Download (89.2 KB) - added by vensasa 7 years ago.
linux-2011-06-02-15-02-33.log Download (79.3 KB) - added by vensasa 7 years ago.
linux-2011-06-08-19-12-51.log Download (84.6 KB) - added by vensasa 7 years ago.
linux-2011-06-30-10-34-53.log Download (80.6 KB) - added by vensasa 7 years ago.

Change History

Changed 7 years ago by vensasa

Changed 7 years ago by vensasa

Changed 7 years ago by vensasa

Changed 7 years ago by vensasa

Changed 7 years ago by vensasa

comment:1 Changed 7 years ago by vensasa

I can also shut down the guest system via the virtualbox GUI, the virtualbox GUI does not lockup. I can only do that via a power off the machine type shutdown, the guest OS is locked up and unresponsive.

comment:2 Changed 7 years ago by vensasa

These problems also appeared after upgrading to 4.x. There were no freezing problems prior to 4.x.

comment:3 Changed 7 years ago by vensasa

Previously virtualbox was using software virtualisation. I have today switched it to hardware virtualisation. The crashing is still going on and I am going to attach a new log that I have just taken after a crash with hardware virtualisation enabled. I had to enabled AMD-V in the BIOS. Please note that the crashing is therefore occuring under both hardware and software virtualisation. It features the system becoming increasingly slow and then just freezing completely, the display becomes frozen with all of the contents of the screen being frozen in place, and no keyboard or mouse activity gets through. After the freeze up, the hard disk indicator on the VM window does not light up or turn on.

As well, the VM is also not responsive at all to pings or daytime server requests from other system on the LAN to such servers running on the VM system.

Thank you.

Changed 7 years ago by vensasa

comment:4 Changed 7 years ago by frank

Your latest logfile shows that you are using VBox 4.0.6. Please could you check the latest available version, 4.0.8?

comment:5 Changed 7 years ago by vensasa

I upgraded to 4.0.8 and Ubuntu still crashes about every day or so. I am attaching a new log file of a crash after 4.0.8 was upgraded to. These freeze ups cause the guest OS to freeze, the virtualbox UI still works so I am able to shut down the VM session and restart it.

Changed 7 years ago by vensasa

comment:6 Changed 7 years ago by vensasa

On several ocassions the guest has locked up while playing videos. I cannot say that is the cause. I do use flash player in firefox and I also use x11vnc and Xvfb combination as well for network transparency.

comment:7 Changed 7 years ago by frank

Please test if VBox 4.0.10 makes a difference because there were some timer fixes which will affect especially SMP Linux guests.

comment:8 Changed 7 years ago by vensasa

I recently upgraded to 4.0.10. I was very hopeful that this would solve the problems with the crashing. But, alas, no cigar. Pretty much on schedule, 4.0.10 froze up after about 24 hours of running, which is quite typical and normal. I will post another log on this.

Changed 7 years ago by vensasa

comment:9 Changed 7 years ago by frank

What makes me wonder is that you apparently were still able to cleanly power off the VM. So probably only the guest is frozen but not the VM itself...

comment:10 Changed 7 years ago by vensasa

I mentioned that in the original description. It has always been the case that the guest session would freeze up, but the virtualbox UI is still functional. this happens on a daily basis and is undesirable. The guest is 32 bit Ubuntu Linux. it is likely to be a virtualbox problem. Linux is tested on a large array of different systems, so any showstopper bug in Linux code tends to get caught. If this were a Linux problem it would effect far more users than virtualbox users.

comment:11 Changed 7 years ago by vensasa

This bug is still occuring with Virtualbox 4.1. I tried to experiment with disabling the swap partition in Linux, reducing the VM memory to 900 MB, and turning on PAE and installing a PAE kernel, but none of these have made any difference. In some cases now, the VM freezes up just after 7 hours of use.

comment:12 Changed 7 years ago by vensasa

I tried asnother experiment, enabling the host IO cache. This has absolutely no effect on the freezing problem as it still freezes and locks up regularly. this has been a very serious business issue and we hope that there is a possibility that this issue will be fixed? Is there any suspected cause or subsystem that may be at fault, or a certain section of code that may be the cause? Is there expectation of a fix for this issue?

comment:13 Changed 7 years ago by vensasa

i am disabling the host cache since it has no effect on the freezing issue

comment:14 Changed 7 years ago by vensasa

This problem is continueing and since we run many important business functions, this has been a very serious problem for us. When will this problem be fixed, what subsystem does this problem involve, what part of virtualbox is causing this problem, what lines of code, what is being done to fix it. We need to know when this problem will be fixed so we are not left wondering if this problem will ever be fixed. Please help.

comment:15 Changed 7 years ago by vensasa

This issue seems to be aggravated by high memory and/or CPU usage. I have seen the system slow down as memory usage increased and I managed to kill some programs to free up some memory and the system recovered. in Some of the desktop VMs there is Firefox running and it seems that since Firefox uses outrageous amounts of memory, that tends to cause Virtualbox to crash much more quickly. In some cases I noticed the slowdown as if it was headed for a freeze and was able to kill a few programs and stop the freeze and the system recovers. However in some cases the freeze is sudden and there is absolutely no indication via a slow down, but sometimes it is preceded by a slow down. I hope this helps you find and fix the problem.

comment:16 Changed 7 years ago by vensasa

by recover the system i mean i noticed the system slowing down and i killed firefox and that seemed to cause things to return to normal, but sometiems the system totally freezes so i can only restart the VM

comment:17 Changed 7 years ago by vensasa

This is an update. I am as of 4.1.2 having freezing problems still, and problems with extreme sluggishness of the VM guest. I am now able to SSH into the guest sometimes and kill chromium or firefox sessions which are running. The GUI often becomes completely unresponsive and unuseable, and even the SSH becomes very slow with often characters taking minutes to display as they are typed in. Often killing these chromium and firefox cause the system to unfreeze. Chromium and firefox running for a while seem to increase the chance of the freeze and sluggish performance. Whether this is due to their high memory, CPU, sockets, i/o, or graphics usage. I do not know. I do know that when the near freeze or extreme sluggishness occurs, killing these two programs does unfreeze the system. I have 1.3 GB of memory allocated, which should be more than enough.

This bug is a general reliability problem and should be high priority. If we are having this problem here, it is also probably occuring elsewhere. When this problem occurs, it is undesirable and unacceptable, and may occur in data center setups and so on. It is an indication that there are problems with durability and reliability of the system and its ability to tolerate high loads, something it should be able to tolerate if it is to be considered reliable.

comment:18 Changed 7 years ago by vensasa

This is an update. This problem is still occuring o 4.1.4. The problem may be related to memory use or exhaustion since the problem seems to occur when a program is using a very large amount of memory, the lock ups will occur, however the system can become unlocked by that program being killed. One such program is firefox which can use a large amount of memory over time.

This is a general reliability problem, this bug needs to be fixed. This problem indicates severe unreliability in virtualbox and could cause stability in other server environments. Because of this problem significant investments in server infrastructure have been compromised.

Virtualbox needs to take this problem seriously and fix this problem.

comment:19 Changed 7 years ago by vensasa

This is an update. This problem still continues in 4.1.6 and seems to be linked to memory usage of programs running in the VM. It seems as though the problem appears as the system memory usage reaches a certain point, this includes sluggish behaviour and then a total lockup (for all intents and purposes). Even logging into SSH can take over 15 minutes, to just enter a command to kill programs that are consuming a lot of RAM can take over 15 minutes. the system is so slow. The GUI becomes totally unresponsive. SSH access is extremely slow. Killing memory intensive programs via SSH, does cause the system to totally unfreeze. I see no reason why this problem cannot be fixed. This problem can affect millions of users and causes the threat of severe instability. To improve the reliability of virtualbox for all users this problem needs to be fixed.

comment:20 Changed 6 years ago by frank

Please forgive me but I don't get it how VirtualBox is responsible for a memory intensive application running in the guest and making the guest sluggish. I would be really interested in a guest log (/var/log/kern.log and/or /var/log/message) when this happened. I think the freezes you observe are very similar to what could happen on real hardware.

comment:21 Changed 6 years ago by frank

If you still see this problem with VBox 4.1.8 / 4.1.10 then please attach a VBox.log file for such a session.

comment:22 Changed 6 years ago by vensasa

Of course, the problem still exists. I will post the log you asked for, but I do not think there is much of interest there. The problem seems to occur about the same time as the system is out of memory. On the logs, it shows that in some cases during the lockup, linux's out of memory killer is activated, Linux deals with out of memory by killing the program using the most resources. An OS usually avoids locking up as a result of being out of memory. the oomkiller does not always work for some reason or the system locks up for a long period of time before it is activated, the system is basically frozen, althoygh very slow, I have sometimes been ablwe to login with SSH to kill the largest memory consuming program, which unfreezes the system. So the system seems to become basically frozen, but sometimes very slow access is possible through SSH.

I am not sure if this is a problem with Linux or virtualbox or some combination of them. Turning on or off AMD-V has no effect it seems, nor turning off the swap. Giving less memory to the VM seems to make it freeze up more often as the memory is more quickly exhausted.

comment:23 Changed 6 years ago by vensasa

Clearly what seems to be happening is that some process ends up using up a lot of RAM, perhaps firefox, the system runs out of RAM as a result. Normally Linux will kill the most memory hungry application so that other programs who need memory can have some. Apparently this is not happening very quickly. Instead, the system now grinds to a near halt and it may be an hour before Firefox is finally killed by the kernel.

Then the system unfreezes and returns to normal.

I have seen many times the error messages announcing that oomkiller is killing the firefox process. Then the system un freezes.

Recently as well, I have been recieving error messages such as , i am paraphrasing: "Cannot fork, cannot allocate memory" during the freezeup period before Linux kills a process to free more RAM.

Throughout all of this the Windows host system has gigabytes free.

This problem may be an interaction between Linux and Virtualbox. For instance, are you giving Linux bad information on the amount of free memory. If Linux tries to use unavailable memory, could this be causing a lock up? Eventually anyway Linux manages to detect out of memory and kill the largest process and the system unfreezes.

Its a very reproducible problem, I just find it odd that this bug is not fixed already. its a huge glaring bug that really should be fixed.

Last edited 6 years ago by vensasa (previous) (diff)

comment:24 Changed 6 years ago by vensasa

Also, there really is nothing in syslog, nothing. Sometimes a message would appear there that out of memory killer was killing the largest process because of the out of memory condition. But thats it, The log files do not say anything else .

Version 0, edited 6 years ago by vensasa (next)

comment:25 Changed 6 years ago by frank

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

The reason is that we were never able to reproduce it. Please reopen if still relevant with VBox 4.1.22 / 4.2.0.

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use