Latest Bugs & Tasks
Fixed in hrev50187.
Next time just make more evident there's a patch :-)
Fixed in hrev50187.
Yay, progress! Thanks for reporting!
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
Fixed in hrev50184.
Tried to eject CDROM from terminal command "-eject"
Went immediately into KDL
Photo of KDL output attached
When downloading, the downloads progress window is never fully on the desktop. The right half is always off screen. (see attached screenshot1).
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.
Fixed in hrev50179
Scratch that, fixed in hrev50178
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)
The simple fact of linking -l netapi into an executable, results in 150 entries popping up in leak_check.sh 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 leak_checker.sh 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
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.
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
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.
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.
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.