First experiences in beta1: collecting unexpected behaviours

Development OS
1

Good morning,

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

Testing Box

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

Unexpected Behaviour

Untranslated strings

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

debug-kill-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.

2

Please file a ticket about that and attach debug report to it.

Does switching bridge to NAT fixes networking? Maybe slow boot time is also related to it?

3

Apparently not. NAT networking shows the same behaviour: sometimes it works, sometimes (more often) it doesn’t

4

This seems to slow down when in the “disk” icon at boot sequence (still, it would be better to have a more verbose output instead of “icons” :))

5

Debugger being a graphical debugger, as soon as the app_server, which handle the GUI on the system side, is paused to debug it, all graphical apps will become unresponsive, waiting on app_server services.

The whole OS is not frozen, non-graphical programs still run fine, but visually nothing works anymore indeed.
And as you can’t trigger “Run” button clic event without app_server help, it’s dead.
Trying to attach to Debugger from Debugger app will also ends in Debugger freeze, for instance.

Question is: do we allow to attach to well-known system servers or shall we forbid it (or at least show a big warning notice) ?

6

Well, if you pause the process that draws the UI, then it will stop drawing the UI. :slight_smile:

7

It make sense but…even the mouse pointer? O_o

and my wo cents: do it make sense to attack process to debugger which are going to make anything irreversively unusable?

8

I had that problem with Workstation. It turned out it was binding the virtual machine’s Ethernet adapter to one of Windows virtual adapters (like BlueTooth or whatever) that weren’t being used.

I don’t remember if VirtualBox has a way of forcing it to a specific adapter, but you might want to check that.

9

You can hold Shift key to enter the bootloader and enable onscreen debug output.

10

Yes, even the mouse pointer. It’s a software cursor, not hardware one, and even hardware ones needs being updated by the UI subsystem to move on screen.

I guess a big warning before attaching to a system process would make sens yes, but a Debugger purpose is to be able to debug a process, so making it impossible for some of them doesn’t make sense. It’s up to user, usually a developper, to know what he’s doing. A reminder won’t hurt, but forbidding it could.

1 Like
11

Seems reasonable, if people want to shoot at their feet let them it’s a learning process :smiley:

12

Did it. Everything seems to go well…until suddenly i landed into the wasteland of the KDL…need to learn how to send the entire log to VirtualBox virtual serial port and have it dumped to a text file…i’ll be back :slight_smile:

13

Still a lot of troubles with network, trying to investigate further.

  • When stucked in “Configuration”, I disabled ipv4 from the pane and suddenly I get a notification saying “Ready” (ofc this is not a working condition, without ipv4)

  • Then, re-enabling ipv4 I go into “Configuration” again.

  • Finally, trying to re-open the preference pane all things mess-up (screenshot below)

This behaviour is damned non-deterministic so I’m getting insane trying to reproduce and dump a debug. In the meantime, I save here for a confrontation

network-issues

EDIT: Here’s a pastebin of a boot when the network services ends to stuck on “Configuration”: https://pastebin.com/TEK91efG

no errors or something suspect, there, as far as i can see…

1 Like
14

Which virtual adapter type do you have in your VM? The AMD Pcnet adapter doesn’t work correctly with Haiku. You have to use one of the Intel pro 1000 ones, I always use the MT server one (something like that, I’m not at my computer right now). NAT or bridged makes no difference, both work on my systems (Linux, Windows and OSX)

15

You are using PCnet network card in VM which is known to be problematic under Haiku. Switch to Intel Pro 1000, that should fix it.

16

I tried NAT using the defaults for r1beta1-rc the same I tried for hrev52346 and it didn’t work. Switched to bridged and it connected instantly. Not sure why, haven’t tried to figure it out.

17

It definitively works. Tnx for help. I think the VirtualBox help page could better explain this compatibility issue (i didn’t noticed at first)

18

In that case, “kill” makes no sense. This button is used to terminate the application being debugged, but if you work from a core file, there is no running application to kill. The dialog should not be shown at all (bugreport please), but in the meantime, I think the “resume” button should be ok.

19

This was just an example. I’ve aldo tried to attach a working application, like Terminal. When you click “Kill” application usually stops working but the orphaned window stays lying around. I think it’s the expected behaviour, but the point is that there’s no way to kill that window, then.

BUT this seems to happen ONLY when the Debugger is installing a package in the background (need more testing)

20

No, this is not expected. Kill should kill the app and exit debugger.
It’s quite possible that it breaks when there is an in progress download indeed (and there already is a bugreport about that, as it gets in the way of using debugger in the webkit testsuite)