Bug 165656 – [GTK] UIProcess from WebKitGtk+ 2.15.x SIGSEGVs because of X Error BadDamage in WebKit::AcceleratedBackingStoreX11::update(WebKit::LayerTreeContext const&) () at Source/WebKit2/UIProcess/gtk/AcceleratedBackingStoreX11.cpp:145

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

[Andres Gomez Garcia]

Created attachment 296654 [details]
BT from gdb

I'm using WebKitGtk+ with my own JHBuild setting:
https://github.com/tanty/jhbuild-epiphany/tree/master

Epiphany 3.20.3 and WebKit 2.15.2 with the attached patches for bug 164049, bug 165200, bug 165283 and bug 164052, applied.

I'm running Epiphany with the dconf key:

"process-model" = "shared-secondary-process"

And the env variable:

"export LIBGL_DRI3_DISABLE=1"

The compilation was done with CMake args:

'-DUSE_LD_GOLD=OFF -DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DENABLE_MINIBROWSER=ON -DCMAKE_C_FLAGS_RELEASE="-O0 -g1 -DNDEBUG -DG_DEBUG=fatal-criticals -DG_DISABLE_CAST_CHECKS" -DCMAKE_CXX_FLAGS_RELEASE="-O0 -g1 -DNDEBUG -DG_DEBUG=fatal-criticals -DG_DISABLE_CAST_CHECKS"'

After visiting several pages, eventually, the UIProcess (epiphany) hits a SIGSEV.

This bug is not reproducible in a predictable way.

[Michael Catanzaro]

Looks like bug #164303, but now the crash is in XErrorTrapper itself. :S

[Andres Gomez Garcia]

Created attachment 297082 [details]
Another similar BT from gdb

[Carlos Alberto Lopez Perez]

$ echo '_ZN6WebKit26AcceleratedBackingStoreX116updateERKNS_16LayerTreeContextE ()' | c++filt 

WebKit::AcceleratedBackingStoreX11::update(WebKit::LayerTreeContext const&) ()

[Michael Catanzaro]

The backtraces you attached don't have any local variables or line numbers. Can you do a build with debug info (-DCMAKE_BUILD_TYPE=RelWithDebInfo) and post another backtrace taken with 'bt full'? They're also missing debuginfo from libX11.so which needs to be fixed. I would always insist on this quality level to have a more useful crash report.

[Andres Gomez Garcia]

(In reply to comment #4)
> The backtraces you attached don't have any local variables or line numbers.
> Can you do a build with debug info (-DCMAKE_BUILD_TYPE=RelWithDebInfo) and
> post another backtrace taken with 'bt full'? They're also missing debuginfo
> from libX11.so which needs to be fixed. I would always insist on this
> quality level to have a more useful crash report.

I'm sorry Michael, but I disagree.

This is not a reasonable request. It is already very hard to use with this debug information. What you request would take me *a lot* of time and effort.

These crash reports already consume a lot of time and are generated through a *real* use. I won't be able to make a normal use with what you request. In addition, the crashes are not easily reproducible.

In other words, I may try what you ask but do not expect I would do it. Not any time soon. Not at all.

[Andres Gomez Garcia]

(In reply to comment #4)
> The backtraces you attached don't have any local variables or line numbers.

Other than that, I don't understand why you say that the line numbers are not included. I see them there.

[Carlos Alberto Lopez Perez]

(In reply to comment #4)
> The backtraces you attached don't have any local variables or line numbers.
> Can you do a build with debug info (-DCMAKE_BUILD_TYPE=RelWithDebInfo) and
> post another backtrace taken with 'bt full'? They're also missing debuginfo
> from libX11.so which needs to be fixed. I would always insist on this
> quality level to have a more useful crash report.

The backtraces have line numbers, why you say that?

They are much more readable if you demangle the symbols. Example:

curl -s 'https://bug-165656-attachments.webkit.org/attachment.cgi?id=297082' | c++filt 


What I see in this backtrace is that the crash happens because some X error not trapped is emitted. This probably means that the fix on bug 164303 is incompleted and more X error than BadDrawable and BadDamage should be trapped.

It will be useful to know which X error caused this.

Did you got printed on the terminal some information about the X error that caused webkit to abort?

[Carlos Alberto Lopez Perez]

(In reply to comment #1)
> Looks like bug #164303, but now the crash is in XErrorTrapper itself. :S

XErrorTrapper is designed to crash for any X Error event not trapped. 

Here the trapper is set only to BadDrawable and BadDamage, so it will crash if any other X Error event happens

[Michael Catanzaro]

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

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

[Michael Catanzaro]

(In reply to comment #9) 
> 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.

Well, admittedly it could likely be optimized out, but at least we'd likely see it from the char* error message that includes the error.

[Andres Gomez Garcia]

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

[Michael Catanzaro]

(In reply to comment #11)
> I've explained the steps to reproduce.

You've explained that it's not reproducible in any predictable way. I have no doubt that this is a problem and that I'll eventually start getting reports of it in Fedora; I guess we'll wait for those to come in to figure out what the X error is here....

(In reply to comment #11)
> -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.

Why do you have to use -g1? Unless you are building in an extremely memory-constrained environment, that should not be necessary.

(In reply to comment #11) 
> > 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.

I can't imagine that has a significant impact on performance...? Are you not able to use distro packages of WebKit at all, because they have cast checking enabled...? No distros use that and it's very much not supported as it changes critical warnings into mysterious crashes.

[Michael Catanzaro]

(In reply to comment #11)
> The distro is completely irrelevant since I'm using jhbuild. Please, read
> the descriptions of the reported bugs.

Did you also build libX11 yourself with jhbuild? If so, you should use -g; if not, you should install your distro's debuginfo package.

[Carlos Alberto Lopez Perez]

XErrorTrapper will print on the terminal the info about the XErrorEvent that caused the crash before crashing.

The program with pid $pid received an X Window System error.
The error was .... [this is the info we need]

^ 

I guess its easier to get the needed info from there than to have to deal with a rebuilds with more debug info, generate a backtrace, etc.

[Andres Gomez Garcia]

The program with pid 8540 received an X Window System error.
The error was 'BadDamage (invalid Damage parameter)'.
  (Details: serial 7784248 error_code 151 request_code 143 minor_code 2)
1   0x7ffff21906c5 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x1e) [0x7ffff21906c5]
2   0x7ffff4c5ddce /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x2189dce) [0x7ffff4c5ddce]
3   0x7ffff4c5dac2 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x2189ac2) [0x7ffff4c5dac2]
4   0x7ffff4c5daee /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x2189aee) [0x7ffff4c5daee]
5   0x7ffff75d746d /usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x11d) [0x7ffff75d746d]
6   0x7ffff75d43a7 /usr/lib/x86_64-linux-gnu/libX11.so.6(+0x423a7) [0x7ffff75d43a7]
7   0x7ffff75d4465 /usr/lib/x86_64-linux-gnu/libX11.so.6(+0x42465) [0x7ffff75d4465]
8   0x7ffff75d5420 /usr/lib/x86_64-linux-gnu/libX11.so.6(_XReply+0x230) [0x7ffff75d5420]
9   0x7ffff75d0cad /usr/lib/x86_64-linux-gnu/libX11.so.6(XSync+0x4d) [0x7ffff75d0cad]
10  0x7ffff3599731 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xac5731) [0x7ffff3599731]
11  0x7ffff3565d47 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xa91d47) [0x7ffff3565d47]
12  0x7ffff350d754 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xa39754) [0x7ffff350d754]
13  0x7ffff31c941b /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x6f541b) [0x7ffff31c941b]
14  0x7ffff3503727 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xa2f727) [0x7ffff3503727]
15  0x7ffff3505e62 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xa31e62) [0x7ffff3505e62]
16  0x7ffff36c6380 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xbf2380) [0x7ffff36c6380]
17  0x7ffff36c60b4 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xbf20b4) [0x7ffff36c60b4]
18  0x7ffff36c5f8d /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xbf1f8d) [0x7ffff36c5f8d]
19  0x7ffff36c58d9 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0xbf18d9) [0x7ffff36c58d9]
20  0x7ffff30d7249 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x603249) [0x7ffff30d7249]
21  0x7ffff3177a13 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x6a3a13) [0x7ffff3177a13]
22  0x7ffff3228c09 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x754c09) [0x7ffff3228c09]
23  0x7ffff30c1480 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x5ed480) [0x7ffff30c1480]
24  0x7ffff30c15ea /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x5ed5ea) [0x7ffff30c15ea]
25  0x7ffff30c17e1 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x5ed7e1) [0x7ffff30c17e1]
26  0x7ffff30c1356 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x5ed356) [0x7ffff30c1356]
27  0x7ffff30c7bf2 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libwebkit2gtk-4.0.so.37(+0x5f3bf2) [0x7ffff30c7bf2]
28  0x7ffff219a987 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libjavascriptcoregtk-4.0.so.18(_ZNK3WTF8FunctionIFvvEEclEv+0x37) [0x7ffff219a987]
29  0x7ffff21ab796 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libjavascriptcoregtk-4.0.so.18(_ZN3WTF7RunLoop11performWorkEv+0xce) [0x7ffff21ab796]
30  0x7ffff21ebe5e /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2488e5e) [0x7ffff21ebe5e]
31  0x7ffff21ebe82 /home/tanty/no-backup/personal/webkit/epiphany/install/lib/libjavascriptcoregtk-4.0.so.18(+0x2488e82) [0x7ffff21ebe82]

Thread 1 "epiphany" received signal SIGSEGV, Segmentation fault.
0x00007ffff21906ca in WTFCrash () at /home/tanty/no-backup/personal/webkit/epiphany/jhbuild-checkout/webkitgtk-2.15.2/Source/WTF/wtf/Assertions.cpp:323
323         *(int *)(uintptr_t)0xbbadbeef = 0;
(gdb)

[Andres Gomez Garcia]

Created attachment 297318 [details]
Yet another similar BT from gdb

This one also includes the information for:

$ info proc mappings

[Carlos Alberto Lopez Perez]

(In reply to comment #15)
> The program with pid 8540 received an X Window System error.
> The error was 'BadDamage (invalid Damage parameter)'.

This has already been fixed in https://trac.webkit.org/changeset/209063

But that fix is not included in 2.15.2 that is what you are using.

Please cherry-pick that patch or wait for 2.15.3

*** This bug has been marked as a duplicate of bug 164303 ***

[Carlos Alberto Lopez Perez]

I might be wrong. Not sure if is the same issue looking at the line numbers.

Its still odd that BadDrawable caused this. It should be trapping the error.

Can you try to set the trapper for the whole function to check if that makes a difference?


--- Source/WebKit2/UIProcess/gtk/AcceleratedBackingStoreX11.cpp.org	2016-12-16 18:49:08.888809630 +0100
+++ Source/WebKit2/UIProcess/gtk/AcceleratedBackingStoreX11.cpp	2016-12-16 18:49:45.432835561 +0100
@@ -136,9 +136,9 @@
         return;
 
     Display* display = downcast<PlatformDisplayX11>(PlatformDisplay::sharedDisplay()).native();
+    XErrorTrapper trapper(display, XErrorTrapper::Policy::Crash, { BadDrawable, BadDamage });
 
     if (m_surface) {
-        XErrorTrapper trapper(display, XErrorTrapper::Policy::Crash, { BadDrawable, BadDamage });
         if (m_damage) {
             XDamageNotifier::singleton().remove(m_damage.get());
             m_damage.reset();

[Andres Gomez Garcia]

Created attachment 299346 [details]
Yet another similar BT from gdb

Also with WKGTK+ 2.15.3 and Ephy 3.20.6

[Miguel Gomez]

Curiously enough, I'm able to reproduce this same crash when running the layout tests with a patch I'm testing. The patch itself is not relevant, but the fact that the crash is reproducible even with the XErrorTrapper is curious. BTW, the crash is only reproducible when running several parallel tests. Running the failing tests alone they don't crash.

17:00:27.204 41276   The program with pid 37321 received an X Window System error.
17:00:27.204 41276   The error was 'BadDamage (invalid Damage parameter)'.
17:00:27.204 41276     (Details: serial 288 error_code 145 request_code 140 minor_code 2)
17:00:27.204 41276   1   0x7f53a286e837 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x17) [0x7f53a286e837]
17:00:27.204 41276   2   0x7f53a08bb9fe /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(+0x250f9fe) [0x7f53a08bb9fe]
17:00:27.204 41276   3   0x7f53a08bba72 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(+0x250fa72) [0x7f53a08bba72]
17:00:27.204 41276   4   0x7f53945ca45d /usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x11d) [0x7f53945ca45d]
17:00:27.204 41276   5   0x7f53945c73c7 /usr/lib/x86_64-linux-gnu/libX11.so.6(+0x423c7) [0x7f53945c73c7]
17:00:27.204 41276   6   0x7f53945c7485 /usr/lib/x86_64-linux-gnu/libX11.so.6(+0x42485) [0x7f53945c7485]
17:00:27.204 41276   7   0x7f53945c8430 /usr/lib/x86_64-linux-gnu/libX11.so.6(_XReply+0x230) [0x7f53945c8430]
17:00:27.204 41276   8   0x7f53945c3ced /usr/lib/x86_64-linux-gnu/libX11.so.6(XSync+0x4d) [0x7f53945c3ced]
17:00:27.204 41276   9   0x7f539f7fc015 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_ZN6WebKit26AcceleratedBackingStoreX116updateERKNS_16LayerTreeContextE+0x4c5) [0x7f539f7fc015]
17:00:27.204 41276   10  0x7f539f7e50f1 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_Z47webkitWebViewBaseExitAcceleratedCompositingModeP18_WebKitWebViewBase+0x51) [0x7f539f7e50f1]
17:00:27.204 41276   11  0x7f539f7a09bb /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_ZN6WebKit27AcceleratedDrawingAreaProxy30exitAcceleratedCompositingModeEv+0x2b) [0x7f539f7a09bb]
17:00:27.204 41276   12  0x7f539f7a1c01 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_ZN6WebKit20DrawingAreaProxyImpl30exitAcceleratedCompositingModeEmRKNS_10UpdateInfoE+0x21) [0x7f539f7a1c01]
17:00:27.204 41276   13  0x7f539f8fd91a /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_ZN6WebKit16DrawingAreaProxy17didReceiveMessageERN3IPC10ConnectionERNS1_7DecoderE+0x13a) [0x7f539f8fd91a]
17:00:27.204 41276   14  0x7f539f529e1f /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_ZN3IPC18MessageReceiverMap15dispatchMessageERNS_10ConnectionERNS_7DecoderE+0xef) [0x7f539f529e1f]
17:00:27.204 41276   15  0x7f539f5f6ea2 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_ZN6WebKit15WebProcessProxy17didReceiveMessageERN3IPC10ConnectionERNS1_7DecoderE+0x12) [0x7f539f5f6ea2]
17:00:27.204 41276   16  0x7f539f525bdb /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_ZN3IPC10Connection15dispatchMessageESt10unique_ptrINS_7DecoderESt14default_deleteIS2_EE+0x6b) [0x7f539f525bdb]
17:00:27.204 41276   17  0x7f539f5268d8 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37(_ZN3IPC10Connection18dispatchOneMessageEv+0xe8) [0x7f539f5268d8]
17:00:27.204 41276   18  0x7f53a28814b1 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18(_ZN3WTF7RunLoop11performWorkEv+0xd1) [0x7f53a28814b1]
17:00:27.204 41276   19  0x7f53a28b9a89 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18(+0xdc7a89) [0x7f53a28b9a89]
17:00:27.204 41276   20  0x7f539c180a8d /home/igalia/magomez/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libglib-2.0.so.0(g_main_context_dispatch+0x13d) [0x7f539c180a8d]
17:00:27.205 41276   21  0x7f539c180e28 /home/igalia/magomez/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libglib-2.0.so.0(+0x48e28) [0x7f539c180e28]
17:00:27.205 41276   22  0x7f539c181142 /home/igalia/magomez/WebKit/WebKitBuild/DependenciesGTK/Root/lib/libglib-2.0.so.0(g_main_loop_run+0xc2) [0x7f539c181142]
17:00:27.205 41276   23  0x7f53a28ba340 /home/igalia/magomez/WebKit/WebKitBuild/Release/lib/libjavascriptcoregtk-4.0.so.18(_ZN3WTF7RunLoop3runEv+0x120) [0x7f53a28ba340]
17:00:27.205 41276   24  0x42b1e2 /home/igalia/magomez/WebKit/WebKitBuild/Release/bin/WebKitTestRunner(_ZN3WTR14TestInvocation6invokeEv+0x4d2) [0x42b1e2]
17:00:27.205 41276   25  0x41de00 /home/igalia/magomez/WebKit/WebKitBuild/Release/bin/WebKitTestRunner(_ZN3WTR14TestController7runTestEPKc+0x140) [0x41de00]
17:00:27.205 41276   26  0x41e02b /home/igalia/magomez/WebKit/WebKitBuild/Release/bin/WebKitTestRunner(_ZN3WTR14TestController20runTestingServerLoopEv+0x5b) [0x41e02b]
17:00:27.205 41276   27  0x420b98 /home/igalia/magomez/WebKit/WebKitBuild/Release/bin/WebKitTestRunner(_ZN3WTR14TestControllerC1EiPPKc+0x268) [0x420b98]
17:00:27.205 41276   28  0x417b26 /home/igalia/magomez/WebKit/WebKitBuild/Release/bin/WebKitTestRunner(main+0x56) [0x417b26]
17:00:27.205 41276   29  0x7f5392926b45 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f5392926b45]
17:00:27.205 41276   30  0x417b6c /home/igalia/magomez/WebKit/WebKitBuild/Release/bin/WebKitTestRunner() [0x417b6c]
17:00:27.208 36275 [28730/42202] imported/w3c/web-platform-tests/media-source/mediasource-addsourcebuffer-mode.html failed unexpectedly (WebKitTestRunner crashed [pid=37321])

[Miguel Gomez]

(In reply to comment #20)
> Curiously enough, I'm able to reproduce this same crash when running the
> layout tests with a patch I'm testing. The patch itself is not relevant, but
> the fact that the crash is reproducible even with the XErrorTrapper is
> curious. BTW, the crash is only reproducible when running several parallel
> tests. Running the failing tests alone they don't crash.

Forgot to mention that I'm using ToT.

[Carlos Garcia Campos]

Created attachment 299698 [details]
Patch

We never fixed this :-( We were always passing the wrong value to the XErrorTrapper.

[Carlos Garcia Campos]

Created attachment 299699 [details]
Patch

[Carlos Garcia Campos]

Committed r211145: <http://trac.webkit.org/changeset/211145>