Latest Bugs & Tasks

Syndicate content Haiku
Trac Timeline
Updated: 9 min 57 sec ago

Ticket #12704 (Download Window only partially on desktop) created

Sun, 2016-04-03 16:09

When downloading, the downloads progress window is never fully on the desktop. The right half is always off screen. (see attached screenshot1).

Categories: Development

Ticket #12703 (Anomalous/incorrect behavior of get_team_info() in conjunction with ...) created

Sun, 2016-04-03 02:38

In order to monitor teams being created/destroyed as part of some Debugger-related refactoring, I set up some code that uses the private start/stop_watching_system() APIs to be notified of those events, as be_roster only covers BApplications, and cannot be relied upon in the CLI case anyways.

However, something appears to be not entirely correct here, as there seems to be a relatively reliably reproducible case where the notifications arrives that a new team was created, and then turning around to retrieve the corresponding team's info succeeds, but the team_info struct in question only has the team_id itself filled in. The args are empty, image and thread count are 0 (though argc is surprisingly 1), and as such it's impossible to determine from said info what the launched app actually was. Waiting for a bit and requesting the info succeeds though, so it seems there's some race here on the kernel side. Attached a testcase that can relatively easily reproduce the problem. It can be compiled from the root of the Haiku tree using:

g++ -g testcase.cpp -Iheaders/private/system -Iheaders/private/kernel -o testcase -lroot

Running the program and then simply creating new Terminals repeatedly using the cmd+n Terminal shortcut will relatively reliably trigger it within 3-4 new Terminals here, and the code in question is set up to trigger a debugger call when the issue is detected. Interestingly, the actual team that exhibits the problem is quite reliably the one belonging to the newly created Terminal app itself, none of the bash, etc. subprocesses appear to wind up being affected.

Categories: Development

Ticket #9488 (Recognizes tooltips as "active window") closed

Thu, 2016-03-31 22:18

Scratch that, fixed in hrev50178

Categories: Development

Ticket #12702 (Networked Printer: IPP -> No printer found!) created

Wed, 2016-03-30 18:52

hrev50173 x86_gcc2
Printer: Epson XP-820
Connection: Wired ethernet network

Printer is connected to router using CAT5 ethernet cable. When adding printer
the IPP address is not found (see screenshot1)
I am able to access the printer configuration with Webpositive using the network address of the printer. (see screenshots 2, 3, 4 for current configuration)

Categories: Development

Ticket #12701 (Leak checking "noise" caused by created

Tue, 2016-03-29 15:35

The simple fact of linking -l netapi into an executable, results in 150 entries popping up in even if just doing a launch-and-close of the program without actually using any network code , presumably due to some static variables in that library

These appear to be one-time "leaks", not recurrent ones, if so they wouldn't matter in term of memory usage.

What this ticket is about though, is this: they make it harder to hunt for leaks, as you have to wade through 150 additional entries
(if I'm wrong about this, let's change component to kit/netkit)

To solve this, we don't necessarily have to "fix" the leaks per se, but instead could enrich the exception-list within to take those into account, much like it currently takes into account some other special cases in the support kit, ICU lib and so on

Categories: Development

Ticket #12700 (Media Addon Server crash) created

Sun, 2016-03-27 11:52

As soon as Haiku starts playing some music or video, the media addon server crashes. This happens even on the latest nightly to date (2016/03/27) which is 50167.
I'm running the hybrid x86 with gcc2 version on real hardware, the specifications are as follow: Pentium 4 HT 3 Ghz, Intel Extreme Graphics 2, Audio by Realtek (cannot really tell the specific model right now), 1 GB RAM.

Categories: Development

Ticket #12699 (Various crashes in BHttpRequest's crypto) created

Fri, 2016-03-25 14:45

This sometimes occurs in our Updater GUI (fortunately when it does happen, it is during tear-down, after the update has been performed). We get various backtraces, all involving "crypto" something, sometimes hinting at BHttpRequest. Will post a few backtraces as examples.

Seems to have started after the switch from libresolv(?). This is a bit of a "heisenbug" as this occurs mainly for Dane, not really for me. There might be a possibility that this is due to apps being linked against an older hrev (with a diff. libresolv?) being run in a more recent hrev, as the builds I send to Dane are compiled in 49662 whereas he runs hrev49856

Categories: Development

Ticket #12698 (Strange checkfs behavior) created

Thu, 2016-03-24 17:46

This is hrev50152.

When running checkfs -c sometimes I get inconsistent results such as different count of checked nodes, blocks that could be freed and others. Also sometimes checkfs reports that some random files that "could not be opened". List of files that could not be opened is different after each call of checkfs -c and sometimes empty. In theory checkfs -c should not change anything, but check results of consecutive checkfs -c calls are different. When checkfs returns inconsistent results, consecutive calls are not fast as usual (for example usually second call of checkfs can be done for about 3 seconds while first was about 10 minutes, node count is about 300000). Running checkfs from boot usb immidiately after boot don't cause this issue.

This is probably caused by error in disk block caching for reading.

Sample checkfs result:

> checkfs -c /boot
haiku_unsupported-nightly-hrev50163-x86_hybrid-raw (inode = 6815673), could not be opened
        259418 nodes checked,
        0 blocks not allocated,
        0 blocks already set,
        307218 blocks could be freed
        files           235130
        directories     23178
        attributes      704
        attr. dirs      366
        indices         40
        direct block runs               255611 (40.90 GiB)
        indirect block runs             809 (in 44 array blocks, 15.78 GiB)
        double indirect block runs      0 (in 0 array blocks, 0 バイト)

checkfs result from live USB:

> checkfs -c /Haiku1
        259416 nodes checked,
        0 blocks not allocated,
        0 blocks already set,
        7 blocks could be freed
        files           235128
        directories     23178
        attributes      704
        attr. dirs      366
        indices         40
        direct block runs               255600 (41.38 GiB)
        indirect block runs             798 (in 41 array blocks, 15.30 GiB)
        double indirect block runs      0 (in 0 array blocks, 0 バイト)

Note "blocks could be freed" value.

Categories: Development

Ticket #12697 ([Screenshot] add Open with menu) created

Thu, 2016-03-24 14:47

KSnapshot from KDE4 has an Open with menu (next to Save as...) which is very convenient as you don't have to save the screenshot, then locate it and finally open. You don't even have to save the file and go straight to editing. Would be nice to have it.

Categories: Development

Ticket #12696 (MediaPlayer doesn't support VP9 and Opus codecs) created

Thu, 2016-03-24 08:30

This is hrev50152.

MediaPlayer shows "General system error" when trying to open webm video with VP9 video and Opus audio codecs. WebPositive plays this file, but with lags.

MediaPlayer writes following in Terminal:

[matroska,webm @ 0x18399cb8] Unknown entry 0x56AA
[matroska,webm @ 0x18399cb8] Unknown entry 0x56BB
[matroska,webm @ 0x18399cb8] Unknown/unsupported CodecID V_VP9.
[matroska,webm @ 0x18399cb8] Unknown/unsupported CodecID A_OPUS.
[matroska,webm @ 0x18399cb8] max_analyze_duration 5000000 reached at 5005000
[matroska,webm @ 0x18399cb8] decoding for stream 0 failed
[matroska,webm @ 0x18399cb8] Could not find codec parameters (Video: none, 1920x1080)
[matroska,webm @ 0x18399cb8] decoding for stream 1 failed
[matroska,webm @ 0x18399cb8] Could not find codec parameters (Audio: none, 48000 Hz, 2 channels)
Controller::SetTo: InitCheck failed

As I understand Haiku uses ffmpeg so enabling these codecs should be not difficult.

Categories: Development

Ticket #12687 (Implement a sort of type-ahead filtering for the Desktop) closed

Mon, 2016-03-21 12:37

Alright, then you are just using it wrong :-)

You assume that it would work just like it does on Windows. I had a hard time to understand how it works in Windows when I first learned about it. In Haiku, every character you enter counts. If you enter 'T' twice, only files that contain 'tt' will be selected. You can reset that by pressing ESCAPE.

However, whatever you enter will only take you to the first matching entry. You can then use the TAB key to walk the entries in alphabetical order (or press SHIFT+TAB to walk it backwards).
Furthermore, in icon mode, you can also use the cursor keys to switch to the next icons nearby.

Personally, I would prefer if using TAB/SHIFT+TAB would only walk within files that match to the characters you entered, but even as it is now, it's already more powerful than what Windows delivers. Just different to use.

Categories: Development

Ticket #12695 ([AboutSystem] identifies Core i3 as Core i5) created

Sun, 2016-03-20 17:16

In a Dell 11z, with a Intel Core i3 CPU, AboutSystem identifies as "Core i5".
The same applies for the Pulse app.


Categories: Development

Ticket #12686 (printf's converted to TRACE in SoundPlayNode.cpp) closed

Sun, 2016-03-20 17:15

Applied in hrev50162, thanks!

Categories: Development

Ticket #12694 (HaikuDepot - Listed application not found) closed

Sun, 2016-03-20 16:14

Fixed with hrev50161. Thanks for reporting!

Categories: Development

Ticket #12694 (HaikuDepot - Listed application not found) created

Sun, 2016-03-20 15:45

hrev50160 x86_gcc2
HaikuDepot shows gphoto2 as available for installation
Clicking install button brings up error message:
"Fatal error occurred while installing package gphoto2_x86: failed to find a match for "gphoto2_x86"()" (see attached screenshot1)
Attempting to install from terminal also brings up error message:
"* failed to find a match for "gphoto2_x86": Name not found" (see attached screenshot2)

Another issue is that gphoto2 should also install libgphoto2_x86 as a dependency, since gphoto2_x86 is only a CLI front end for libgphoto2_x86.

Categories: Development

Ticket #12692 (pkgman update stalls out on x86_64 nightlies) closed

Sat, 2016-03-19 21:49

Thanks for checking, closing as duplicate.

Categories: Development