[Webkit-unassigned] [Bug 165656] [GTK] UIProcess from WebKitGtk+ 2.15.2 SIGSEGVs in WebKit::AcceleratedBackingStoreX11::update(WebKit::LayerTreeContext const&) () at Source/WebKit2/UIProcess/gtk/AcceleratedBackingStoreX11.cpp:145

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Dec 14 08:27:01 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=165656

--- Comment #11 from Andres Gomez Garcia <agomez at igalia.com> ---
(In reply to comment #9)
> (In reply to comment #5)
> > I'm sorry Michael, but I disagree.
> > 
> > This is not a reasonable request.
> 
> It's not? If you try to report a crash report with an incomplete backtrace
> it should be closed as incomplete/invalid. Why should we waste time with
> this when (almost) everyone else is reporting bugs with good quality
> backtraces...? In this case we need to see the local variables in
> XErrorTrapper::errorEvent to figure out what the XError was, your backtrace
> doesn't have them, the backtraces we've come to expect would.

I've explained the steps to reproduce.

> If you were a Fedora or openSUSE user, I would say to run the
> debuginfo-install command given to you by gdb and then take the backtrace
> again. It takes all of two minutes and is not unreasonable at all. Since
> you're using Debian, you've got to do it manually and I know that takes
> longer, but that's a distro problem and doesn't mean it's optional. In fact,

The distro is completely irrelevant since I'm using jhbuild. Please, read the descriptions of the reported bugs.

> since you built WebKit yourself, you'd already have the debuginfo for the
> frames we need had you used -g instead of -g1. So using -g is the minimal
> change I would make next time you build WebKit. (I also think it's a really

-g1 is the difference between having an usable and debuggable ephy or not having it at all. These flags are not there by mistake but, actually by advice from you, developers.

> bad idea to use G_DISABLE_CAST_CHECKS. That's going to make lots of bugs
> much harder to solve, but that's not likely an issue here.)

Same than above.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161214/104d8f81/attachment.html>


More information about the webkit-unassigned mailing list