Bug 125558 - wk2-gtk does not display anything
Summary: wk2-gtk does not display anything
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Gtk (show other bugs)
Version: 528+ (Nightly build)
Hardware: All Other
: P2 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-11 01:10 PST by Antoine Jacoutot
Modified: 2014-04-11 09:01 PDT (History)
8 users (show)

See Also:


Attachments
MiniBrowser scrot (10.50 KB, image/png)
2013-12-11 01:10 PST, Antoine Jacoutot
no flags Details
config.log (163.60 KB, text/plain)
2013-12-11 05:39 PST, Antoine Jacoutot
no flags Details
Patch (2.36 KB, patch)
2014-04-11 06:01 PDT, Carlos Garcia Campos
mrobinson: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Jacoutot 2013-12-11 01:10:31 PST
Created attachment 218939 [details]
MiniBrowser scrot

Hi.

I am seeing a reproducible issue with Webkit2 (GTK, 2.2.3) under at least FreeBSD and OpenBSD.
The display window is not rendered at all for some reason (tried devhelp and MiniBrowser).
I have no clue as to where to start looking to try and debug this and would appreciate any hint you guys could give me...
Thank you.
(attached is a screenshot of MiniBrowser running OpenBSD that illustrate the issue)
Comment 1 Zan Dobersek 2013-12-11 05:10:02 PST
Could you check that while a single MiniBrowser is launched, there is also a WebKitWebProcess running in parallel? Its absence would mean that it has very likely unexpectedly crashed.

If the process is there, could you please attach the config.log file of your build to this bug?
Comment 2 Antoine Jacoutot 2013-12-11 05:38:35 PST
(In reply to comment #1)
> Could you check that while a single MiniBrowser is launched, there is also a WebKitWebProcess running in parallel? Its absence would mean that it has very likely unexpectedly crashed.

Hi Zan.

Yeah the process is there:
ajacoutot  4281 42.0  0.5 41664 43120 p6  S+     2:31PM    0:00.45 /usr/local/libexec/WebKitWebProcess 18


> If the process is there, could you please attach the config.log file of your build to this bug?

Attached.
Thank you very much for your follow up.
Comment 3 Antoine Jacoutot 2013-12-11 05:39:04 PST
Created attachment 218952 [details]
config.log
Comment 4 Antoine Jacoutot 2013-12-11 05:57:45 PST
Oh another relevant thing that I totally forgot to mention. If I use the mouse to select/copy blindly within the empty display window and paste it into an editor, I can see the text that was supposed to be displayed...
Comment 5 Antoine Jacoutot 2014-01-02 05:49:44 PST
Hi and happy New Year ;-)
Would anyone have a clue as to where this issue could come from. As far as webkit2 is concerned, it looks like it only works on Linux... (did not try OS X though).
Thanks.
Comment 6 Koop Mast 2014-03-27 14:15:20 PDT
This problem with epiphany/MiniBrowser also happens with webkitgtk 2.4.0 on FreeBSD 10/amd64. The place where the content of the website should be shown stays gray but if I move the mouse round the window, <a href> links do show up in the status bar. So this seems to be a display issue only.

Like Antoine I don't have a idea what to do here, I do know that enabling/disabling EGL during build doesn't matter.

I'm happy to try out patches/guesses or ways of debugging this.
Comment 7 Zan Dobersek 2014-04-01 00:28:27 PDT
This might be an issue with accelerated compositing under X, or perhaps with the version of Cairo that's used.

On what pages does this occur?
What version of Cairo are you compiling against?
Can you try disabling accelerated compositing at build-time (via --disable-accelerated-compositing) or by changing webkitWebViewBaseUpdatePreferences() to disable it unconditionally?
Comment 8 Koop Mast 2014-04-01 14:44:49 PDT
This happens on every page with the MiniBrowser.
I'm using cairo-1.12.16
Disabling accelerated compositing doesn't change the end result.
Comment 9 Raphael Kubo da Costa (:rakuco) 2014-04-07 14:39:36 PDT
Hi all,

Several attempts and a dozen patches later I finally got trunk to build on FreeBSD in debug mode.

The problem seems to come from a call to fcntl(2) that fails with EOPNOTSUPP. From Source/WebKit2/Platform/unix/SharedMemoryUnix.cpp:

    while (fcntl(duplicatedHandle, F_SETFD, FD_CLOEXEC) == -1 || fcntl(duplicatedHandle, F_SETFL, accessModeFile(protection)) == -1) {

The second fcntl() call fails and nothing is displayed (in debug mode WebProcess crashes because of the ASSERT_NOT_REACHED() below those calls).
Comment 10 Carlos Garcia Campos 2014-04-11 05:09:27 PDT
(In reply to comment #9)
> Hi all,
> 
> Several attempts and a dozen patches later I finally got trunk to build on FreeBSD in debug mode.
> 
> The problem seems to come from a call to fcntl(2) that fails with EOPNOTSUPP. From Source/WebKit2/Platform/unix/SharedMemoryUnix.cpp:
> 
>     while (fcntl(duplicatedHandle, F_SETFD, FD_CLOEXEC) == -1 || fcntl(duplicatedHandle, F_SETFL, accessModeFile(protection)) == -1) {
> 
> The second fcntl() call fails and nothing is displayed (in debug mode WebProcess crashes because of the ASSERT_NOT_REACHED() below those calls).

Thanks for debugging this. It seems that call is also wrong in linux, according to the fcntl man page the only flags allowed are O_APPEND, O_NONBLOCK, O_ASYNC and O_DIRECT, but I guess in linux it ignores the open flags instead of failing. In any case, a file descriptor duplicated with dup has the same flags of the original file descriptor except the CLOEXEC, so I think we don't even need the second fcntl.
Comment 11 Carlos Garcia Campos 2014-04-11 05:28:59 PDT
(In reply to comment #10)
> (In reply to comment #9)
> > Hi all,
> > 
> > Several attempts and a dozen patches later I finally got trunk to build on FreeBSD in debug mode.
> > 
> > The problem seems to come from a call to fcntl(2) that fails with EOPNOTSUPP. From Source/WebKit2/Platform/unix/SharedMemoryUnix.cpp:
> > 
> >     while (fcntl(duplicatedHandle, F_SETFD, FD_CLOEXEC) == -1 || fcntl(duplicatedHandle, F_SETFL, accessModeFile(protection)) == -1) {
> > 
> > The second fcntl() call fails and nothing is displayed (in debug mode WebProcess crashes because of the ASSERT_NOT_REACHED() below those calls).
> 
> Thanks for debugging this. It seems that call is also wrong in linux, according to the fcntl man page the only flags allowed are O_APPEND, O_NONBLOCK, O_ASYNC and O_DIRECT, but I guess in linux it ignores the open flags instead of failing. In any case, a file descriptor duplicated with dup has the same flags of the original file descriptor except the CLOEXEC, so I think we don't even need the second fcntl.

Actually, I guess in case of receiving a different protection, we need to shm_open with the appropriate flags instead of using dup.
Comment 12 Carlos Garcia Campos 2014-04-11 06:01:52 PDT
Created attachment 229129 [details]
Patch

The current code doesn't have any effect in Linux and seems to cause failures in FreeBSD, so remove it for now. We should handle the case of ReadOnly passed to createHandle.
Comment 13 Koop Mast 2014-04-11 06:11:30 PDT
I didn't test the patch in #(In reply to comment #12)
> Created an attachment (id=229129) [details]
> Patch
> 
> The current code doesn't have any effect in Linux and seems to cause failures in FreeBSD, so remove it for now. We should handle the case of ReadOnly passed to createHandle.

Didn't test this patch but the one by rakuco in #9 worked for me on FreeBSD.
Comment 14 Martin Robinson 2014-04-11 08:36:02 PDT
Comment on attachment 229129 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=229129&action=review

> Source/WebKit2/Platform/unix/SharedMemoryUnix.cpp:187
> +    // FIXME: Handle the case where the passed Protection is ReadOnly.

I guess we need a bug for this?
Comment 15 Carlos Garcia Campos 2014-04-11 09:01:20 PDT
Committed r167128: <http://trac.webkit.org/changeset/167128>