Opened 9 years ago

Closed 9 years ago

#6498 closed bug (fixed)

Haiku in Virtualbox freezes after just over 27 hours uptime.

Reported by: jstressman Owned by: nobody
Priority: normal Milestone: R1
Component: - General Version: R1/Development
Keywords: Cc: jstressman@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

After noticing this happen more than once, I started monitoring it closely.

I disabled the screensaver and left the About dialog up so that I could see the exact amount of up-time before it froze. I have repeated this 3 times now since I started closely monitoring it.

1 day 3 hours 4 minutes 42 seconds
1 day 3 hours 4 minutes 39 seconds
1 day 3 hours 4 minutes 51 seconds

This has been over several different gcc4hybrid nightly builds at least between hrev38285 and hrev38311.

This also was with modified kernel config (to change time stamps, enable APM, change syslog buffer and max size values), and a stock install. Same behavior.

This is running under Virtualbox 3.2.8 on Windows 7 64bit.

I have the Haiku virtual machine running with 1GB ram, 128MB vid mem, and a 2GB hd image. ICH AC97 audio, Intel PRO/1000 MT Desktop NIC, no serial ports, no shared folders.

Haiku isn't running out of memory (it's barely using 10% available mem, if that, and doesn't appear to be growing in usage over time), there are no errors on the syslog before it freezes, virtualbox itself seems fine, isn't gobbling memory or cpu, and only the host window is locking up in the sense that when you try to force close the window after Haiku freezes it says it's not responding and you have to force close it. I'm not sure if Virtualbox runs each guest OS window as a separate process so that if it crashes it doesn't take the rest down. So this could be a problem with Virtualbox itself.

I'm going to try running a similar setup in VMWare to see if I can reproduce this behavior in another VM. (QEMU runs horribly and eats up way too much memory on a matching configuration, taking almost 1.4GB RAM just to run Haiku idle, so I'm not keen on having that gobble up my system resources for 27 hours while I wait. Virtualbox used less than 100MB and ran vastly smoother. And the fact that it takes so long to reproduce makes it unappealing to try different configurations.)

Attachments (3)

haiku-lock1crop.png (36.3 KB ) - added by jstressman 9 years ago.
First freeze after I started monitoring closely.
haiku-lock2crop.png (36.4 KB ) - added by jstressman 9 years ago.
Second freeze after I started monitoring closely.
haiku-lock3crop.png (36.5 KB ) - added by jstressman 9 years ago.
Third freeze after I started monitoring closely.

Download all attachments as: .zip

Change History (10)

by jstressman, 9 years ago

Attachment: haiku-lock1crop.png added

First freeze after I started monitoring closely.

by jstressman, 9 years ago

Attachment: haiku-lock2crop.png added

Second freeze after I started monitoring closely.

by jstressman, 9 years ago

Attachment: haiku-lock3crop.png added

Third freeze after I started monitoring closely.

comment:1 by tqh, 9 years ago

To help track this down it would be good if you set the vm to log serial communication to file. Also make sure to set log to serial either in boot options or in the kernel settings file and rebooting.

Qemu logs serial to file with:

qemu -serial file:file_to_log_to.txt haiku.image

comment:2 by jstressman, 9 years ago

Well, my next round of tests has revealed the following...

VMWare is still chugging along past the 27 hour mark by half an hour now... but both virtualbox VMs (gcc2hybrid and gcc4hybrid) locked up at 1 day 3 hours 3 minutes and 19s/18s respectively. Oddly both about a minute and a half earlier than the previous freezes, but still just over 27 hours apiece.

This would lead me to believe that the problem is either Virtualbox itself, or the combination of Virtualbox/Haiku.

I've been trying to find a good tutorial on enabling a virtual serial console on virtualbox to enable virtual debugging.

Perhaps I'll also try some other OS in virtualbox to see if it also suffers a freeze around the same time.

comment:3 by jstressman, 9 years ago

As an update to this, I tried saving the state and restoring it and this circumvents the freeze. This would seem to point the finger at virtualbox as the problem.

I'll have to try running a different OS for 27 hours straight (no save and restore of state) and see if that experiences the same freeze.

comment:4 by jstressman, 9 years ago

I just wanted to update to say that I haven't seen this problem for awhile... at least a week or two, if not more.

My current boot in virtualbox has been running for 49 hours now without a problem. (and without me saving state or anything... just normal running.)

Still on the same version of virtualbox (3.2.8 on Win7 64bit).

I have no idea what changed to "fix" the problem, at least for me with Haiku in vbox.

comment:5 by Coldfirex, 9 years ago

Ok to be closed?

comment:6 by jstressman, 9 years ago

I think so. I haven't seen the problem since then.

Let's go ahead and close it.

comment:7 by korli, 9 years ago

Resolution: fixed
Status: newclosed

Feel free to reopen if needed.

Note: See TracTickets for help on using tickets.