Desktop crashes upon boot

[rossi]

Revision: hrev46066 Build: Custom hybrid (clean build, both gcc2 / gcc4 generated folders)

The systems start booting, app. 1 sec after the desktops starts to load, directly after Deskbar is shown, the system goes to KDL.

Haiku is running in VirtualBox (USB disabled).

See attachment for details.

[anevilyak]

I don't suppose you'd be able to supply a screenshot in PNG or some other format that's directly viewable in a browser?

[anevilyak]

That's not KDL, that's an app_server crash. Please type 'bt' at the prompt and supply an updated screenshot of the resulting output.

[anevilyak]

Alternatively, assuming you can get at that partition's data in some other way, 'save-report' will save a crash report to /boot/home, which would supply much more useful information.

[rossi]

Sorry for the confusion. I tried again, this time behaviour is slightly different, even though I didn't change anything except restarting VBox.

Screenshot attached (PNG).

[anevilyak]

Interestingly, that crash is different, that time it actually did panic. What revision did this start happening with?

[rossi]

Unfortunately I don't remember the exact previous revision. I updated my installation for the first time in two weeks, i.e. I was previously at a low 46000 revision. Therefore I can't give more precise details to pinpoint the exact revision.

The previous built, probably three to five revisions back exhibited the same behaviour, but for that build I wasn't sure everything was built clean, therefore I didn't investigate and report at that time.

Also at that time it crashed while initialising OHCI, therefore I turned off USB support in VBox since it never worked for me in the first place.

[siarzhuk]

Replying to rossi:

Also at that time it crashed while initialising OHCI, therefore I turned off USB support in VBox since it never worked for me in the first place.

What is your environment: the host system, VBox version, on which system have you build your image, which image type do you use, what have you changed during creating the Haiku virtual machine in VBox? Have you tried to boot using corresponding ​nightly from haiku-os.org?

[rossi]

VBox Version 4.2.18 hrev88780 / Host Mac OX X 10.9 (13A569)

VBox Settings attached for your reference.

I didn't change the VBox settings at all, except for turning off USB, which was previously enabled, but never worked with any of my USB media.

I run Alpha/4.1 perfectly fine with the same settings (here even sound works as a bonus)

I build all my images from source, the build host system is the aforementioned Haiku Alpha 4.1, which also serves as my backup production system in case the current builds exhibit issues like the current one.

[rossi]

I didn't try any of the nightly builds from haiku-os.org, but if it helps I can try to setup another VM tomorrow based on one of the nighlies.

[siarzhuk]

Replying to rossi:

I didn't try any of the nightly builds from haiku-os.org, but if it helps I can try to setup another VM tomorrow based on one of the nighlies.

There are some possible sources of problem: VBox for Mac OS, your buildtools, "non-canonical" image, Haiku itself etc. I just wanted to restrict the search area: in case nightly image will work in the same environment - the problem is in your buildtools or image you have build. In case the nightly build fails - current revision of Haiku is not compatible with Mac OS VBox and should be investigated. So please take some time to try nightly image.

I'm using VBox to run Haiku under Windows for years and observe no big problems all this time. some my fellows are also using it's Linux version for everyday testing without such issues too. So I was just surprised that Haiku can fails on VBox. :)

[rossi]

OK, tested the nightly as requested, which works like a charm. Therefore I guess the issue must be with my build setup, even though I didn't change anything within my build setup except updating the sources (git pull --rebase) before I did the defective build and all prior builds worked like a charm as well.

Anyway, as the nightly works, I would assume this is specific to my setup and the bug can therefore be closed ...

PS: @Siarzhuk: Which audio settings do you use in VBox to get audio working with the current revisions?

[siarzhuk]

Replying to rossi:

PS: @Siarzhuk: Which audio settings do you use in VBox to get audio working with the current revisions?

I'm using VBox only for emergency purposes during time I have no access to Haiku-powered hardware. Frankly speaking I had no idea if audio works in it. ;-) I have just checked my Window 7 based VBox ver 4.2.18 rev88780 and hear no sound at all using ICH AC97 emulation: the device persists in Media server preflet and SoundPlayer behaves as it plays something really - but result is silence. After switching to "Intel HD audio" emulation - no audio hardware is detected at all.

[rossi]

I'm lost ... status is as follows: nightly (gcc2hybrid hrev46066) works, but every build I do locally crashes, either in the app_server or goes to KDL.

In order to check that I didn't mess up my build somehow, I deleted both generated directories, run configure again, did a fresh built and even reformatted the target partition to make sure no stale data or settings are causing the crash. However the crash still appears.

The build host system is based on Haiku Alpha 4.1 with no changes ...

I'm really out of ideas, as to what I'm doing wrong, especially since the exact same setup worked like a charm until two weeks ago, when I did the previous last working build.

[siarzhuk]

Replying to rossi:

The build host system is based on Haiku Alpha 4.1 with no changes ...

Do you bild Haiku on Haiku? There are definitely problem with standard c++ libs in case compiling custom builds on Haiku when the gcc version was upgraded. AFAIR such compilation just installs the libstdc++.so and libsupc++.so directly from the host system. So it may be not compatible with the new c++ libs provided with upgraded compiler. And the app_server is just the first program in the boot sequence linking to c++ stuff - and becomes the first victim of the incompatibility.

I'm really out of ideas, as to what I'm doing wrong, especially since the exact same setup worked like a charm until two weeks ago, when I did the previous last working build.

I'm building hybrid Haikus on Haiku for many years using "two system upgrading each other" scheme. To workaround this c++ libs upgrade case I either build newest Haiku revision by cross-compilation on FreeBSD or just download actual nightly and use it to upgrade both systems to "newest c++ libs". ;-)

So try to recompile your custom build under working nighly that has worked for you in comment:11.

[pulkomandy]

As per original reporter over IRC, problem is now gone.