Opened 6 years ago

Closed 6 years ago

#9963 closed bug (invalid)

Desktop crashes upon boot

Reported by: rossi Owned by: axeld
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (3)

hrev46066.tiff (573.3 KB) - added by rossi 6 years ago.
130916_002.png (709.3 KB) - added by rossi 6 years ago.
Haiku R1_Exp.vbox (17.4 KB) - added by rossi 6 years ago.

Download all attachments as: .zip

Change History (18)

Changed 6 years ago by rossi

Attachment: hrev46066.tiff added

comment:1 Changed 6 years ago by 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?

comment:2 Changed 6 years ago by anevilyak

Component: - GeneralServers/app_server
Owner: changed from nobody to axeld

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.

comment:3 Changed 6 years ago by 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.

Changed 6 years ago by rossi

Attachment: 130916_002.png added

comment:4 Changed 6 years ago by 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).

comment:5 Changed 6 years ago by anevilyak

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

comment:6 Changed 6 years ago by 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.

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

comment:7 in reply to:  6 Changed 6 years ago by 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?

comment:8 Changed 6 years ago by 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.

Changed 6 years ago by rossi

Attachment: Haiku R1_Exp.vbox added

comment:9 Changed 6 years ago by 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.

comment:10 in reply to:  9 Changed 6 years ago by 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. :)

comment:11 Changed 6 years ago by 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?

comment:12 in reply to:  11 Changed 6 years ago by 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.

comment:13 Changed 6 years ago by 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.

comment:14 in reply to:  13 Changed 6 years ago by 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.

comment:15 Changed 6 years ago by pulkomandy

Resolution: invalid
Status: newclosed

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

Note: See TracTickets for help on using tickets.