Opened 9 years ago

Closed 9 years ago

#12420 closed bug (fixed)

WebPositive hangup when scrolling page

Reported by: ronald-scheckelhoff-trac Owned by: pulkomandy
Priority: normal Milestone: Unscheduled
Component: Applications/WebPositive Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #11879
Platform: All

Description

When visiting www.google.com, WebPositive became unresponsive to all input. After attaching to it with the debugger, the debug report was grabbed (see attachment).

Attachments (1)

WebPositive-554-debug-14-10-2015-19-14-02-Z.report (46.5 KB ) - added by ronald-scheckelhoff-trac 9 years ago.
Debugger report file

Download all attachments as: .zip

Change History (10)

by ronald-scheckelhoff-trac, 9 years ago

Debugger report file

comment:1 by ronald-scheckelhoff-trac, 9 years ago

This happened while using hrev 49682

comment:2 by ronald-scheckelhoff-trac, 9 years ago

The exact same thing happened today, going to https://www.github.com/haikuports/haikuports. The debug report looks almost identical. So - it's randomly repeatable.

comment:3 by ronald-scheckelhoff-trac, 9 years ago

This ticket should be changed to have the Webpositive component attribute. Have to get in the habit. Sorry.

comment:4 by humdinger, 9 years ago

Component: - GeneralApplications/WebPositive
Owner: changed from nobody to pulkomandy

comment:5 by pulkomandy, 9 years ago

Summary: WebPositive hangupWebPositive hangup when scrolling page

I noticed this too, it will happen randomly when scrolling the page. The code for this is not very good as there are things done both in the main and in the window thread; however I could not understand the exact problem (I think it is a lock order inversion, involving the main looper lock, the window looper lock, and the offscreen bitmap lock). Maybe rewriting the code so all the scrolling happens in the view thread, and the main thread just forwards the scroll request, would work. But all the drawing should still happen in the main thread because WebKit is designed that way...

comment:6 by ttcoder, 9 years ago

@pulkomandy (I'm posting the following distinct issue just in case it sheds light on this -- or other -- issue here, otherwise ignore it):

For a couple months of hrevs now, there is a new, deterministic bug in W+ (or maybe it's a different aspect of an existing bug ?). To replicate:

  • simply open a big image's URL (NOT an html page that contains images in it, but a direct URL directly to the image). A good example is the KDL screenshots that sometimes get posted to Trac here.
  • hover the mouse pointer: it turns into a "magnifgying glass" pointer; left-click to "zoom in" on any part of the image: the zoomed image shows up, but W+ won't respond any more after that. Web+ never fails to lock up there.

Not sure if that deserves its own ticket.. I understand the haiku project is VERY busy since my two-line fix for runtime_loader permissions still has not been applied even though dsuden is kicking my ass due to the fallout problems for it ;-)

Last edited 9 years ago by ttcoder (previous) (diff)

comment:7 by pulkomandy, 9 years ago

Please open a new ticket, if the backtrace is similar we can always close it as duplicate.

comment:8 by pulkomandy, 9 years ago

Blocking: 11879 added

(In #11879) Without a bugreport, I assume this is a duplicate of #12420.

comment:9 by pulkomandy, 9 years ago

Resolution: fixed
Status: newclosed

Haven't seen this one happen in a while, I think it's fixed now.

Note: See TracTickets for help on using tickets.