hrev56301 64 bit
QMPlay2 video fullscreen mode - The hanging application cannot be killed!
If you can tie this down to a revision or range of revisions please open a ticket at https://dev.haiku-os.org
If you cant find a correlation to a haiku revision please open a ticket at haikuports for qmplay2 instead
3 Likes
WebPositive ///
hrev56272 - work fine!!!
hrev56276 - unstable work
PS. system problem - commit 56274 kernel … ??
1 Like
As I wrote above, please open a ticket. the forum wont help your issue getting fixed
@X512 already gave me some details about this. It seems the problems indeed started with my scheduler change, but I can’t diagnose more without a KDL backtrace of the hanging applications.
4 Likes
I updated today to hrev 56301 and performance seems to be degraded, kernel team is eating the cpu.
i looked into this years ago, media kit has a problem with buffer bloat, so when threads are interupted the buffer expands until it devours cou and ram
if you want to see worst case, use a slow usb1 stick with a 1080p vid, be prepared.
there’s a nexus of disk speed, buffering issue, latency and tgread priority that creates this issues.
slow disk speed will highlight it
Welcome to the Haiku shell.
~> listdev
device Bridge (Host bridge) [6|0|0]
vendor 8086: Intel Corporation
device 3ec2: 8th Gen Core Processor Host Bridge/DRAM Registers
device Display controller (VGA compatible controller, VGA controller) [3|0|0]
vendor 8086: Intel Corporation
device 3e92: CoffeeLake-S GT2 [UHD Graphics 630]
device Mass storage controller (Non-Volatile memory controller, NVM Ex [1|8|2]
vendor 15b7: Sandisk Corp
device 5002: WD Black 2018/SN750 / PC SN720 NVMe SSD
was the media on internal storage or a thumb drive ?
I don’t think this has anything to do with storage, it’s just some bug exposed by recent changes.
Again, I need backtraces in KDL of hung threads to diagnose and work on the problem. I’ll try to reproduce it myself, but if I can’t, I really need someone who can to retrieve those…
1 Like
The most recent update for Beta 3 seems to do the same thing. A hung thread when I try to read too big of an SVG file using NanoSVGTranslator and Icon-o-Matic. Once I kill the Icon-o-Matic team, the hung thread releases and goes back to idle. I don’t have debugger information from IOM itself but Debugger let me download the debugger information from eXpat, I think. No actual information showed up in the trace after that was downloaded.
1 Like
It is advisable to cancel changes in 56274 and re-check the presence of an error in the operating system.
You’re not right.
There is no controversial change 56274 in the beta3 development branch.
I suppose you are right. It just occurred to me that the translator I’m using may be single-threaded code and taking too long to execute as a result.
Are there hardware similarities in systems where this has been noticed?
Or could it be that systems where it has been noticed are using same locale and the guilty change 56273 instead?
1 Like
Is there a tutorial for beginners how to do that?
Or some step by step document?
1 Like
Right now, once again, the problem poured 56301 64 bit - after 30-40 minutes, the bug caught, the hanging window, the others programs do not start from the Launchbox completely with the windows, the program will display in the Deskbar, but without a window - the standard shutdown from Deskbar started, but did not work … it depended on … . Only the power button allowed to turn off the computer.
The bug occurs in a random window of any working application. The hovering window cannot be killed with the regular tools of the operating system.
1 Like
FWIW, updated to hrev56309 earlier on 32bit, no issues so far?