3d apps for example GLTeapot, Haiku3d and GLife Screen Saver crash in Live environment on VMWare only

[jscipione]

3d apps for example GLTeapot, Haiku3d and GLife Screen Saver crash on 64-bit in Live environment only, they work fine in the regular environment, but crash on the live. I'm not sure how long this has been happening but for a while now.

To reproduce, load up Haiku in the live environment in VMWare, for example the latest nightly. Try it out. Run a 3d app, for example GLTeapot.

Will crash on launch.

This crash only happens in the live environment in VMWare.

[cocobean]

No GL issues on R1B5 (57937+36) and 57968 x86 Live DVD environments. Will look at x64.

[andreibosco]

No issues on R1B5 (57937÷36) x86_64 live USB. The screensaver preview did fail to clean the screen, but it happened with any screensaver, not just GLife.

[jscipione]

You are sure that you’re in the live environment, not installed, and 64-bit? If so then maybe this got fixed somehow but I doubt it but I’ve seen the bug before and somebody else on IRC just reported it… although I haven’t tested on the r1b5 branch yet…

The screensaver redraw thing is normal, you’d see the crash right away so that’s a different bug.

It’s possible we’re missing a package on the nightlies but it’s there on release build, or actually now that I think about it it could actually be a memory limit issue since we both may have had only 256MB of RAM due to VMWare giving that by default on Other > Other 64-bit option.

[jscipione]

The crash is not memory related, I tested again with different virtual memory and processor configurations and I was able to reproduce crash on nightly 64-bit live environment on hrev57966. I have not yet tested this on a r1b5 test build but 3d apps definitely crash on latest nightly still.

[pulkomandy]

I'm not sure what you mean exactly by "the live environment", since there is nothing really special about it.

The differences I can think of:

• Read only filesystem (only if you boot it from a CD/DVD and not an USB drive)
• Some packages are not activated (they are in the _packages_ directory at the root of the filesystem, and moved to /system/packages by Installer)
• Partition is smaller (maybe you just run out of disk space or have no swap file because of this)

So, which one of these is causing a problem?

Also I am confused because your debug reports include icu 66 being loaded, if you use a current version, shouldn't this be icu 74? I don't think ICU is directly related to the problem, but at least it shows that this test was not made on the current version of Haiku.

[EDIT]: ok, actually the last report doesn't.

[andreibosco]

Just to confirm, yes, I was running in a live environment from a USB drive. Regarding memory, my computer has 64gb of ram, not sure if it has any influence with the issue.

Replying to jscipione:

You are sure that you’re in the live environment, not installed, and 64-bit? If so then maybe this got fixed somehow but I doubt it but I’ve seen the bug before and somebody else on IRC just reported it… although I haven’t tested on the r1b5 branch yet…

The screensaver redraw thing is normal, you’d see the crash right away so that’s a different bug.

It’s possible we’re missing a package on the nightlies but it’s there on release build, or actually now that I think about it it could actually be a memory limit issue since we both may have had only 256MB of RAM due to VMWare giving that by default on Other > Other 64-bit option.

[jscipione]

Previous reports were from hrev57439 (a while back) new report is from hrev57966, the latest nightly as of reporting, both show the same bug but the ICU version is different since that got updated in the meantime. Like I said this bug has been happening for a while now, although r1b4 does not experience the bug.

The bug only appears in the live environment i.e. when you push the "Try it out" button, I have no idea why this is the case. Low memory issue is a red herring, of course you weren't testing with 256MB but I tested that in VMWare and it doesn't make a difference. Tested with 1, 2 and 4 virtual CPUs, no difference.

Maybe this is a VMWare issue? I haven't seen it on live hardware, only virtual.

I just checked and there's no crash on my real hardware (Lenovo X220) in hrev57966 live environment so this is indeed a VMWare thing. I'll update the description and lower the priority.