This happens when the gtk-doc scanner is linked against webkit2gtk:
gtkdoc-scangobj $scanobj_options --module=libyelp
(process:14998): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
** (process:14998): WARNING **: Unable to connect to dbus: Cannot autolaunch D-Bus without X11 $DISPLAY
The segfault comes from webkitgtk:
#0 XCloseDisplay (dpy=0x0) at ../../src/ClDisplay.c:51
#1 0x00007ffff4eab831 in WebCore::PlatformDisplayX11::~PlatformDisplayX11 (this=0x7fffe2dfc028, __in_chrg=<optimized out>)
The problem seems to be that m_display is initialized in the constructor of PlatformDisplayX11, but it's assumed not to be NULL.
Created attachment 277239 [details]
Comment on attachment 277239 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=277239&action=review
> - if (m_ownedDisplay)
> + if (m_ownedDisplay && m_display)
what about initializing m_ownedDisplay to false if display is NULL? we can't own a display that doesn't exist.
Created attachment 277247 [details]
Ok, I chose to initialize m_ownedDisplay in the body of the constructor to make sure that m_display is set first. Otherwise we'd have to rely on the order in which m_display and m_ownedDisplay are declared in the class definition.
(In reply to comment #3)
> Created attachment 277247 [details]
> Ok, I chose to initialize m_ownedDisplay in the body of the constructor to
> make sure that m_display is set first. Otherwise we'd have to rely on the
> order in which m_display and m_ownedDisplay are declared in the class
Isn't the order ensured by the compiler? why do we have a warning when the order in the list doesn't match the one in the declaration, then?
Comment on attachment 277247 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=277247&action=review
> + m_ownedDisplay = m_display != nullptr;
We don't explicitly check nullptr, m_ownedDisplay = m_display; should just work, I think.
(In reply to comment #4)
> Isn't the order ensured by the compiler? why do we have a warning when the
> order in the list doesn't match the one in the declaration, then?
Member variables are always initialized in the order they are declared in the class, NOT the order they are listed in the initializer list. Putting them out of order in the initializer list is thus very confusing, and worth warning about. We should never do that in WebKit.
Since relying on the order of declarations is risky -- someone could easily swap those in a "cleanup" and not notice the warning -- I agree with Berto that it's a good idea to do the assignment in the body of the constructor.
Committed r200046: <http://trac.webkit.org/changeset/200046>