Latest Bugs & Tasks

Syndicate content Haiku
Trac Timeline
Updated: 1 hour 39 min ago

Ticket #12373 (Can't "su" to non-superuser : Permission denied) closed

Tue, 2016-04-05 22:44

Fixed in hrev50187.

Next time just make more evident there's a patch :-)

Categories: Development

Ticket #5823 (can(t retrieve e-mails via gmails imap) closed

Tue, 2016-04-05 18:46

Yay, progress! Thanks for reporting!

Categories: Development

Ticket #12706 (BParameterGroup::Unflatten() leaks fName) created

Tue, 2016-04-05 12:48

This sequence..

creates a new BParameterGroup and immediately calls Unflatten() on it.. But Unflatten() is not a well behaved citizen

This means the original fName ("unnamed") is leaked, losing 8 bytes whenever the playback volume is queried or set

Categories: Development

Ticket #12705 (mount_server crash ejecting CDROM) created

Sun, 2016-04-03 17:44

hrev50180 x86_64
Tried to eject CDROM from terminal command "-eject"
Went immediately into KDL
Photo of KDL output attached

Categories: Development

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