Opened 4 years ago
Closed 4 years ago
#16246 closed bug (duplicate)
app_server crash when playing YouTube in Web+ on baremetall install
| Reported by: | Forza | Owned by: | axeld |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | Servers/app_server | Version: | R1/beta2 |
| Keywords: | Cc: | ||
| Blocked By: | #15728 | Blocking: | #16250 |
| Platform: | All |
Description
Hi!
I am running R1Beta2 on a USB drive on the following hardware: AMD Ryzen 2700X CPU 16 threads AMD Radeon RX 590 GPU 16GiB RAM Asus TUF B450-PLUS Motherboard
I have a relatively clean install of Beta2 on a USB stick. Booted it and open WebPositive to play a youtube video. After some seconds it crashed.
Web+ with YouTube seems to create a lot of memory usage, and Haiku is swapping a lot, even though lots of RAM is free. The swapping on a USB stick is very slow. Could this be contributing to the crash?
I've attached the crash report.
Attachments (4)
Change History (15)
by , 4 years ago
| Attachment: | app_server-958-debug-11-06-2020-17-32-59.report.txt added |
|---|
by , 4 years ago
| Attachment: | app_server-959-debug-12-06-2020-08-45-49.report added |
|---|
comment:1 by , 4 years ago
I disabled swap and rebooted. WebPositive worked for longer this time. Still ended up crashing. I attached the second report from this instance.
comment:2 by , 4 years ago
| Component: | - General → Servers/app_server |
|---|---|
| Owner: | changed from to |
A number of users have reported this. Looks like a memory management problem in AlphaMask. X512's patches may be relevant.
The high number of used semaphores that have never been acquired also looks suspicious, we may want to do something about that.
comment:3 by , 4 years ago
The high number of used semaphores that have never been acquired also looks suspicious, we may want to do something about that.
Is it possible to use implementation based on https://git.haiku-os.org/haiku/tree/src/system/libroot/os/locks/mutex.cpp?
comment:4 by , 4 years ago
Yes, the MultiLocker already uses rw_lock. But there are a lot of BLockers in app_server and refactoring all of them may not be a good idea (semaphores have a different kind of overhead to futexes; but the futexes will always win of course when the sems are never acquired/released.) So we should try to find which ones are being used so often and just replace those to start with.
comment:5 by , 4 years ago
It would help as a first step to give a name to the BLockers (possible from the constructor IIRC), then we will more easily identify them.
comment:6 by , 4 years ago
Dup potentially here? #16250 I've seen it as well. Reddit has seen it as well: https://www.reddit.com/r/haikuOS/comments/h0rrks/apparently_youtube_is_too_strong_for_haiku_what/
comment:7 by , 4 years ago
| Blocking: | 16250 added |
|---|
by , 4 years ago
| Attachment: | app_server_crash.jpg added |
|---|
comment:9 by , 4 years ago
app_server_crash.jpg
Stack trace seems to be from wrong thread. I sometimes experience that debugged thread is different from crashed thread when Debugger is started.
comment:10 by , 4 years ago
The thousands of BLocker semaphores were indeed the AlphaMask lock, so I changed that in hrev54353~1 to use a recursive_lock.
Also in hrev54353 I imported the Referenceable part of the X512's AlphaMask changes, which may help with this, but I am not quite sure, as I could only reproduce this crash intermittently.
comment:11 by , 4 years ago
| Blocked By: | 15728 added |
|---|---|
| Resolution: | → duplicate |
| Status: | new → closed |
Actually this is a dupe of #15728.
Crash-report when running with disabled swap.