this thread is to collect my first experiences in beta1. This is also to collect crashes and (un)confirmed bugs before putting them in more formal fashion on Trac (still trying to get the debugging tools to work). I encourage other testers to add their contrib below but this must be considered a working place: when finalized, confirmed bugs (and only confirmed bugs) must be filed on trac
First of all, a personal note: i’m so damned proud to read Haiku speaking my language and i’m equally so damned proud to have contributed translating it
I’m testing using VirtualBox 5.2.18 r124319 (Qt5.6.2) with these specs:
- 4096MB RAM
- 2 CPU, PAE Enabled
- VT-x/Hyper-V enabled
- 32MB VRAM
- 32GB Virtual HDD under SATA controller
- beta1 iso in IDE CDROM
Bridged Network Realtek PCIe GBE Family Controller
- Intel Pro/1000 MT Server
- AC97 Audio
- USB2.0 Controller
I’m noticing that there’re some untranslated strings. These are probably strings not yet accounted in catkeys file, as the translation is marked as completed on Pottle.
I’ve see around 20 of them so far, increasing
Where have i to report them? I don’t think that opening a ticket on trac is the best place to report it.
Slow boot time
For some reason, boot times of the rc seems to be a bit slower than usual (I’ve tested some nightly before). Is there a way to show a more verbose boot instead of icons? To better understand why it’s slower, now.
Also the deskbar gets much more time to show (before was almost instant, now it takes around 10secs)
Network stucks on “Configuration”
This happens very often: network doesn’t complete the configuration steps (see the screenshot below). This never happened with nightly before (althoug it’s the first time I connect as a bridge in Vbox i must admit). Again, where I can get a more verbose debug output to help understand what’s going wrong?
This is due to PICe network adapter not working properly on Haiku. Even if it’s virtualized. Switching to Intel-based adapter solves the issue.
Debugger kill button has apparently no effect
I’m new to debugger so this is perhaps a false positive: kill button has no effect. Altough I ask to kill Haiku3d (or any other team i’ve attached), the windows stays open. There’s no way to close those windows (and so, the Debugger itself).
Additionally, the Debugger icon stays on the Deskbar even if there’re no application windows open. “Close application” has no effect, then, even from task manager
Finally. if the debugger needs a package which I cannot install (see the network malfunction above), after a couple of “skips”, the debugger crashes.
The Debugger was started from the core dump you can see on the desktop
Debugger Attach app_server freeze the entire OS
This is probably not caused by the debugger itself, but it’s probably related to the graphical subsystem (well, it used to be under the BeOS days afaik). But I’ve tested just the debugger atm so until i’ve more clues, I file under it. Trying to attach a team to the app_server crashes the OS. Even the mouse pointer stops to respond. See the screenshot below. Apparently, this happens only with the app_server
This is not a bug, it’s just that trying to debug the process which is responsible to draw the UI obviously stops the updating of the UI itself. Perhaps, a warning box should popup to warn users about continuing when you’re going to debug those key system process.