Opened 9 years ago
Closed 9 years ago
#12423 closed bug (fixed)
W+ reproducibly locks up when (un)zooming a picture
Reported by: | ttcoder | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/WebPositive | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Occurs easily if the picture is much more large/tall than the W+ window, so resize your W+ window down before doing the below:
Steps:
- click e.g. this link
- left-click (zoom)
- left-click (unzoom)
W+ should be locked up; if not, try a long series of fast clicks, and try to resize down the window.
Not a highly prominent problem, but posting in case it helps diagnose some other bug(s) that are less easy to reproduce
Attachments (1)
Change History (4)
by , 9 years ago
Attachment: | WebPositive-5821-debug-16-10-2015-17-07-37.report added |
---|
comment:1 by , 9 years ago
ps -as
mentions 3 active semaphores (?):
Team Id #Threads Gid Uid /boot/system/apps/WebPositive 5821 8 0 0 Thread Id State Prio UTime KTime WebPositive 5821 wait 15 871 240 WebPositive(291808) pthread func 5826 wait 10 4 1 w>Downloads 5828 wait 15 11 13 w>Settings 5830 wait 15 26 25 w>WebPositive: Save 5834 wait 15 31 28 timer thread 5836 wait 20 16 14 timer thread control(291836) w>command_center_large.png - We 5838 wait 15 202 78 offscreen bitmap(292660) team 5821 debug task 6333 wait 10 0 36
FWIW
comment:2 by , 9 years ago
Can no longer lock-up W+ in hrev49814 with that test case and a couple others. Been browsing for an hour or so and only experienced one crash (well known ticket IIRC) and a presumed lock-up, so there's the possibility that "lock-up" tickets are improved or fixed. There's also the youtube regression (no more playback: black video, and garbled audio) but pulkomandy and jua probably know about it already. Congrats on all involved for the improvements :-)
Edit: forgot to mention the memory leak (which I thought was just) associated with the HTML5/youtube regression: it seems that it is not specific to video rendering, because even if just browsing web pages there is an app_server memory leak, which is not returned to system after quitting Web+; maybe the recent app_server improvements allocate extra memory ? I'll collect more data and create a new ticket if no one beats me to it
comment:3 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Sounds like some of your problems deserve separate tickets :)
- Regarding the "leak": I have noticed high memory use in app_server, I don't know if there is an actual leak or just more memory used (we do a lot of things on app_server side that used to be on the application side before)
- Regarding the video problems: it is probably because of ffmpeg update. It is working fine for video here, but I have no soundcard driver so I don't know about sound. On jua's laptop we get working video, and broken sound. We can revert to ffmpeg 0.11 (or some version that still works in between) until the problem is identified and fixed; binary searching ffmpeg versions to see when the problem appeared would be useful.
The BWindow is possibly blocked waiting for the offscreen bitmap lock