Linux host crashing with VirtualBox 4.0.12 and 4.1.2

[CrazyCasta]

I'm running a Win7 (32-bit) guest. Repeatedly my system (host) will restart within 24 hours if I leave VirtualBox running. The system does not restart if VirtualBox is not running. This happens with 4.0.12 and 4.1.2 (I have not verified with other versions, but I think 4.1.0 was also broken). It's bad enough that anything is crashing, but it is unacceptable that it is crashing the host.

As far as I can tell, there is no information in any logs. The only data I see in the VirtualBox logs are a few DHCP offerings. There is nothing in the /var/log/messages or /var/log/dmesg logs. I'm assuming that whatever is happening is causing such a severe crash that the system is unable to log it.

The host is Gentoo Linux running a 64-bit kernel.

[CrazyCasta]

VirtualBox log file

[CrazyCasta]

P.S. "repeatedly" means 90-95% of the time, every once in a while it will last a day or two.

Also, I am running CST Microwave Studio 2011 every time it crashes because it is what I need the VM for in the first place. I'm not sure why that would be relevant, but I thought I'd mention it anyway.

[CrazyCasta]

This is still an issue with 4.1.4. I have tried updating my kernel. I have tried running WinXP instead of Win7. This is a BREAKING issue!!! Please give me some sort of response. This is unacceptable.

The issue with 4.1.4 has moved to about once every 1.5 days, but that doesn't really help much.

[Michael Thayer]

When a Linux system crashes in one way or another the critical information is often missing in the system log, simply because it doesn't get written to disk immediately and once the crash occurs it is no longer possible to run all the necessary machinery. You may be able to find out more using a mechanism like the serial console, kdump or netconsole.

[Frank Mehnert]

Did you ever test any other guest than Windows 7? Does this also happen if 3D is disabled for that VM?

[CrazyCasta]

michael: One time I got lucky and was sitting in front of it when it happened. The system just instantly restarted. The only warning was the screen froze for 1-2 seconds before the restart. I could probably set something up, I'm just not sure it would help. Sorry, I forgot to mention that part.

I believe I have tested without 3D enabled, I will have to verify that though. It acts the same on WinXP as it does on Win7.

[Oskar Berggren]

I'm seeing the same behavior (sudden total freeze for a few seconds, then turns off completely).

Hardware is Dell Latitude E6520 with Intel Core i7-2720QM (Sandy Bridge, four cores plus hyper threading). 8GB RAM.

Host is Ubuntu 10.10, 2.6.35-30-generic-pae, guest is Win7.

Guest can be up for a few or many hours before this happens. Sometimes I go a full day without a problem.

I will attach the VB log file, though it does not appear to state anything directly related to the crash. I've tried to log kernel messages over serial, but this hasn't revealed anything either.

I had a feeling that the problems started after upgrading to 4.1.4, though this seems to contradict the previous report above. 3D is not enabled.

[Oskar Berggren]

Crash happened several hours after the last message in the log.

[CrazyCasta]

Okay, I can finally (sorry for the delay, been very busy) been able to verify that it does crash without 3d and without 2d. It still crashed in <24 hours. I'm posting my showvminfo to show how I have everything setup. It does very clearly show 3D off and 2D off. Please provide some support for this problem.

[Frank Mehnert]

You could help debugging the crash if you would provide a core dump. If you can provide one, please contact me via frank _dot_ mehnert _at_ oracle _dot_ com.

[CrazyCasta]

I'll try that. You do understand though that I'm getting no messages in any of my logs showing that my machine is restarting, right? I'm suspicious that this is just going to restart without dumping a core.

[CrazyCasta]

P.S. Since I'm sure this will have crashed by the next time I get back, here's what I did to start it: ~ $ mkdir vbox ~ $ cd vbox ~/vbox $ ls ~/vbox $ ulimit unlimited ~/vbox $ sudo su Password: vbox # echo -n 1 > /proc/sys/kernel/core_uses_pid vbox # echo -n 1 > /proc/sys/fs/suid_dumpable vbox # exit exit ~/vbox $ VirtualBox -startvm WinXP

[CrazyCasta]

Hmm, sry, try again:

alex@MtOlympus ~ $ mkdir vbox  
alex@MtOlympus ~ $ cd vbox
alex@MtOlympus ~/vbox $ ls
alex@MtOlympus ~/vbox $ ulimit
unlimited
alex@MtOlympus ~/vbox $ sudo su
Password: 
MtOlympus vbox # echo -n 1 > /proc/sys/kernel/core_uses_pid 
MtOlympus vbox # echo -n 1 > /proc/sys/fs/suid_dumpable 
MtOlympus vbox # exit
exit
alex@MtOlympus ~/vbox $ VirtualBox -startvm WinXP

[Frank Mehnert]

Ok, restart is a different observation than a crash. I would really like to see a VBox.log file of such a VM session when the guest restarted spontaneously.

[Michael Thayer]

Any chance that this could be a hardware issue? E.g. a faulty RAM module?

[CrazyCasta]

I hadn't thought of RAM, I'll have to try that one out. I did think it was over heating related (since it only happened during high activity), but I tested with a triple fork (fork to 8 processes) while(1); and it ran for a few weeks (without me even noticing it, without the VM running ofc). Do you think I need to run the test for a while (like 24-hours) or do you think it's just hitting some bad memory cell randomly and failing immediately?

[CrazyCasta]

Frank: The guest is not restarting, the host is. That is the only reason I marked this critical. It would be a problem, but not a critical one if only the guest crashed and/or restarted. This is a host crash. I can post my VBox.log files if you like, but like oskar, the last log items are a long time before the crash. For my most recent crash the last few lines are:

00:00:30.013 Guest Additions capability report: (0x4) seamless: no, hostWindowMapping: no, graphics: yes
00:00:30.059 Shared clipboard: starting shared clipboard thread
00:00:30.061 Guest Additions capability report: (0x5) seamless: yes, hostWindowMapping: no, graphics: yes
00:00:41.454 PCNet#0: Init: ss32=1 GCRDRA=0x09c2f420[64] GCTDRA=0x09c2f020[64]
00:01:14.845 RTC: period=0x20 (32) 1024 Hz
00:01:27.669 NAT: DHCP offered IP address 10.0.2.15
00:02:23.110 RTC: period=0x200 (512) 64 Hz
00:02:42.626 RTC: period=0x20 (32) 1024 Hz
00:57:56.250 RTC: period=0x200 (512) 64 Hz
00:58:16.283 RTC: period=0x20 (32) 1024 Hz

Which, according to my calculations, are 6-7 hours before it restarted. (Please let me know if the rest of the log file would be useful and I'll attach it).

[Michael Thayer]

I'm no expert in RAM matters, but my understanding is the more passes the better, as errors often don't occur "reliably".

[CrazyCasta]

Ok, I have to extract what data I can from the simulation really quick, but then I'll boot up memtest and let it run. I assume it's not going to reboot if it errors. That is, I assume it's going to report an error and hold there, right?

The other very odd coincidence is it always seems to reboot between 3 and 9ish in the morning, regardless of when I started the vm or the simulation. I'd almost think that someone was hitting reset or something except that it never happens unless I'm running the vm and the screen's locked so it's not like anyone can tell.

[CrazyCasta]

Also, I forgot to mention, as I suspected, no core dump.

[CrazyCasta]

I've been running memtest86 for >24 hours. So far it has not reported a single error. I set it to the "fade test" (I assume it sets some values and waits the 90 minute length of the test before reading them again). When the weekend comes I will use my colleague's computer (we have identical hardware and hard drive cages) to test the hardware angle. If it still crashes on his I'm going to assume it's not a hardware problem.

[CrazyCasta]

The test has run for several days now with no errors. I'm guessing it's not a memory issue :( Would have been glad if it was, because I could have just replaced the RAM. Any new suggestions?

P.S. My colleague suddenly got busy on his computer so I can't test the hardware for the time being.

[Frank Mehnert]

Still relevant with VBox 4.2.10?

[Frank Mehnert]

No response, closing.