Bug 125558 – wk2-gtk does not display anything

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Antoine Jacoutot]

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)

[Zan Dobersek]

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?

[Antoine Jacoutot]

(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.

[Antoine Jacoutot]

Created attachment 218952 [details]
config.log

[Antoine Jacoutot]

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...

[Antoine Jacoutot]

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.

[Koop Mast]

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.

[Zan Dobersek]

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?

[Koop Mast]

This happens on every page with the MiniBrowser.
I'm using cairo-1.12.16
Disabling accelerated compositing doesn't change the end result.

[Raphael Kubo da Costa (:rakuco)]

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).

[Carlos Garcia Campos]

(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.

[Carlos Garcia Campos]

(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.

[Carlos Garcia Campos]

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.

[Koop Mast]

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.

[Martin Robinson]

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?

[Carlos Garcia Campos]

Committed r167128: <http://trac.webkit.org/changeset/167128>