Cancel image loads if decoding failed.

Cancel image loads if decoding failed.

'Cancel' isn't really the right word for what this change does.
In the event of an image decoding failure, ImageResource will
synthesize a call to ResourceLoader::didFinishLoading, killing
the actual network request but reporting it as a successful
completion to the rest of blink. This matches our traditional
behavior of decoding errors looking like a successful
resource load (for the most part).

This requires some plumbing changes to image decoding, because
the decoder selection logic doesn't report why it wasn't able to
create an ImageDecoder. It might be because insufficient data has
been received to sniff the image type, or it may be that we
definitely don't have a valid image type. This change exposes enough
information to tell the difference.

BUG=471272
Committed: https://crrev.com/520519605b961a7d979bc0eaa3c057a973dc26f1
Cr-Commit-Position: refs/heads/master@{#407171}

[Nate Chapin, 2016-07-18 18:01:43]

The CQ bit was checked by japhet@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-18 18:03:39]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-18 19:09:53]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-18 19:09:54]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Nate Chapin, 2016-07-19 18:49:22]

The CQ bit was checked by japhet@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-19 18:52:15]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-19 19:05:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-19 19:05:36]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)
  chromeos_x86-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_x86-ge...)
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_clobber_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-gn/bui...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-gn on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-gn/...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[Nate Chapin, 2016-07-19 19:58:17]

The CQ bit was checked by japhet@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-19 19:58:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-19 21:14:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-19 21:14:11]

Dry run: This issue passed the CQ dry run.

[Nate Chapin, 2016-07-19 21:26:41]

Description was changed from

==========
Cancel image loads if decoding failed.

BUG=471272
==========

to

==========
Cancel image loads if decoding failed.

Cancel isn't really the right word for what this change does. In the event of an
image decoding failure, ImageResource will synthesize a call to
ResourceLoader::didFinishLoading, killing the actual network request but
reporting it as a successful completion to the rest of blink. This matches our
traditional behavior of decoding errors looking like a successful resource load
(for the most part).

This requires some plubming changes to image decoding, because the decoder
selection logic doesn't report why it wasn't able to create an ImageDecoder. It
might be because insufficient data has been received to sniff the image type, or
it may be that we definitely don't have a valid image type. This change exposes
enough information to tell the difference.

BUG=471272
==========

[Nate Chapin, 2016-07-19 21:27:11]

Description was changed from

==========
Cancel image loads if decoding failed.

Cancel isn't really the right word for what this change does. In the event of an
image decoding failure, ImageResource will synthesize a call to
ResourceLoader::didFinishLoading, killing the actual network request but
reporting it as a successful completion to the rest of blink. This matches our
traditional behavior of decoding errors looking like a successful resource load
(for the most part).

This requires some plubming changes to image decoding, because the decoder
selection logic doesn't report why it wasn't able to create an ImageDecoder. It
might be because insufficient data has been received to sniff the image type, or
it may be that we definitely don't have a valid image type. This change exposes
enough information to tell the difference.

BUG=471272
==========

to

==========
Cancel image loads if decoding failed.

'Cancel' isn't really the right word for what this change does. In the event of
an image decoding failure, ImageResource will synthesize a call to
ResourceLoader::didFinishLoading, killing the actual network request but
reporting it as a successful completion to the rest of blink. This matches our
traditional behavior of decoding errors looking like a successful resource load
(for the most part).

This requires some plumbing changes to image decoding, because the decoder
selection logic doesn't report why it wasn't able to create an ImageDecoder. It
might be because insufficient data has been received to sniff the image type, or
it may be that we definitely don't have a valid image type. This change exposes
enough information to tell the difference.

BUG=471272
==========

[Nate Chapin, 2016-07-19 21:29:48]

japhet@chromium.org changed reviewers:
+ pdr@chromium.org

[Nate Chapin, 2016-07-19 21:29:49]

pdr, are you a good reviewer for this?

[pdr., 2016-07-20 20:39:16]

Sorry for the delay, I was out sick yesterday.

Excellent change description but please wrap it to 72 characters.

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/ImageSource.cpp (right):

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/ImageSource.cpp:65: // If enough
data has been received to know that we won't have a valid decoded, bail.
nit: valid decoded -> valid decode

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/ImageSource.cpp:66: return
data.size() < ImageDecoder::longestSignatureLength();
This signature length check is now in two places, but that shouldn't be
required. Also.. can we reach this line and return anything but false?

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/ImageSource.h (right):

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/ImageSource.h:73: bool
setData(SharedBuffer& data, bool allDataReceived);
It's not clear to me at the callsites that false means decode error. It's also
confusing that Image::setData's return value is different from
ImageSource::setData's. Can you add an enum return value here instead of using a
bool?

[Nate Chapin, 2016-07-20 20:46:58]

Description was changed from

==========
Cancel image loads if decoding failed.

'Cancel' isn't really the right word for what this change does. In the event of
an image decoding failure, ImageResource will synthesize a call to
ResourceLoader::didFinishLoading, killing the actual network request but
reporting it as a successful completion to the rest of blink. This matches our
traditional behavior of decoding errors looking like a successful resource load
(for the most part).

This requires some plumbing changes to image decoding, because the decoder
selection logic doesn't report why it wasn't able to create an ImageDecoder. It
might be because insufficient data has been received to sniff the image type, or
it may be that we definitely don't have a valid image type. This change exposes
enough information to tell the difference.

BUG=471272
==========

to

==========
Cancel image loads if decoding failed.

'Cancel' isn't really the right word for what this change does.
In the event of an image decoding failure, ImageResource will
synthesize a call to ResourceLoader::didFinishLoading, killing
the actual network request but reporting it as a successful
completion to the rest of blink. This matches our traditional
behavior of decoding errors looking like a successful
resource load (for the most part).

This requires some plumbing changes to image decoding, because
the decoder selection logic doesn't report why it wasn't able to
create an ImageDecoder. It might be because insufficient data has
been received to sniff the image type, or it may be that we
definitely don't have a valid image type. This change exposes enough
information to tell the difference.

BUG=471272
==========

[Nate Chapin, 2016-07-20 22:47:11]

The CQ bit was checked by japhet@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-20 22:47:47]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Nate Chapin, 2016-07-20 22:50:00]

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/ImageSource.cpp (right):

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/ImageSource.cpp:65: // If enough
data has been received to know that we won't have a valid decoded, bail.
On 2016/07/20 20:39:16, pdr. wrote:
> nit: valid decoded -> valid decode

Done.

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/ImageSource.cpp:66: return
data.size() < ImageDecoder::longestSignatureLength();
On 2016/07/20 20:39:16, pdr. wrote:
> This signature length check is now in two places, but that shouldn't be
> required. Also.. can we reach this line and return anything but false?

The failure to create a decoder could be because we have only a few bytes and
therefore might later be able to identify an image type from sniffing
(admittedly a rare case), or it might be that we are absolutely certain that we
don't have a type match. So it's almost always false, but not absolutely
guaranteed. I've updated to use the enum, which is more code churn, but is
probably cleaner overall. WDYT?

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/ImageSource.h (right):

https://codereview.chromium.org/2108033003/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/ImageSource.h:73: bool
setData(SharedBuffer& data, bool allDataReceived);
On 2016/07/20 20:39:16, pdr. wrote:
> It's not clear to me at the callsites that false means decode error. It's also
> confusing that Image::setData's return value is different from
> ImageSource::setData's. Can you add an enum return value here instead of using
a
> bool?

Done.

[commit-bot: I haz the power, 2016-07-21 00:01:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-21 00:01:02]

Dry run: This issue passed the CQ dry run.

[pdr., 2016-07-21 04:39:06]

Much easier to follow with your cleanup! LGTM with or without two further
suggestions.

https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/BitmapImage.cpp (right):

https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/BitmapImage.cpp:201: // If setData()
returns InvalidData, we know that this is a decode error.
Nit: "If ImageSource::setData returns Invalid, we know that this is a decode
error."

https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/BitmapImage.cpp:207: return
dataChanged(allDataReceived);
Not your fault, but would you mind changing the return value of this function
and dataChanged to be an enum too? Maybe just:
enum class ImageSizeAvailable {
    SizeAvailable,
    SizeUnavailable
}

[Nate Chapin, 2016-07-21 20:55:58]

The CQ bit was checked by japhet@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-21 20:56:25]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Nate Chapin, 2016-07-21 20:59:05]

https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/platform/graphics/BitmapImage.cpp (right):

https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/BitmapImage.cpp:201: // If setData()
returns InvalidData, we know that this is a decode error.
On 2016/07/21 04:39:06, pdr. wrote:
> Nit: "If ImageSource::setData returns Invalid, we know that this is a decode
> error."

Done.

https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/platform/graphics/BitmapImage.cpp:207: return
dataChanged(allDataReceived);
On 2016/07/21 04:39:06, pdr. wrote:
> Not your fault, but would you mind changing the return value of this function
> and dataChanged to be an enum too? Maybe just:
> enum class ImageSizeAvailable {
>     SizeAvailable,
>     SizeUnavailable
> }

Went with 'enum SizeAvailability' inside the Image namespace, instead of 'enum
class ImageSizeAvailable', because it looked more readable and less redundant to
me. Any objections?

[pdr., 2016-07-21 21:41:15]

On 2016/07/21 at 20:59:05, japhet wrote:
>
https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
> File third_party/WebKit/Source/platform/graphics/BitmapImage.cpp (right):
> 
>
https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
> third_party/WebKit/Source/platform/graphics/BitmapImage.cpp:201: // If
setData() returns InvalidData, we know that this is a decode error.
> On 2016/07/21 04:39:06, pdr. wrote:
> > Nit: "If ImageSource::setData returns Invalid, we know that this is a decode
> > error."
> 
> Done.
> 
>
https://codereview.chromium.org/2108033003/diff/120001/third_party/WebKit/Sou...
> third_party/WebKit/Source/platform/graphics/BitmapImage.cpp:207: return
dataChanged(allDataReceived);
> On 2016/07/21 04:39:06, pdr. wrote:
> > Not your fault, but would you mind changing the return value of this
function
> > and dataChanged to be an enum too? Maybe just:
> > enum class ImageSizeAvailable {
> >     SizeAvailable,
> >     SizeUnavailable
> > }
> 
> Went with 'enum SizeAvailability' inside the Image namespace, instead of 'enum
class ImageSizeAvailable', because it looked more readable and less redundant to
me. Any objections?

No objections, looks great. LGTM

[commit-bot: I haz the power, 2016-07-21 22:21:20]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-21 22:21:21]

Dry run: This issue passed the CQ dry run.

[Nate Chapin, 2016-07-21 22:23:48]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2016-07-21 22:24:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-21 22:33:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-21 22:33:10]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[Nate Chapin, 2016-07-21 22:42:07]

japhet@chromium.org changed reviewers:
+ peter@chromium.org

[Nate Chapin, 2016-07-21 22:42:08]

peter@, would you mind reviewing the 1-line change to
modules/notifications/NotificationImageLoader.cpp ?

[Peter Beverloo, 2016-07-22 10:53:32]

Certainly - lgtm

Feel free to TBR this class of changes.

[Nate Chapin, 2016-07-22 16:20:03]

The CQ bit was checked by japhet@chromium.org

[commit-bot: I haz the power, 2016-07-22 16:20:21]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-22 16:24:59]

Description was changed from

==========
Cancel image loads if decoding failed.

'Cancel' isn't really the right word for what this change does.
In the event of an image decoding failure, ImageResource will
synthesize a call to ResourceLoader::didFinishLoading, killing
the actual network request but reporting it as a successful
completion to the rest of blink. This matches our traditional
behavior of decoding errors looking like a successful
resource load (for the most part).

This requires some plumbing changes to image decoding, because
the decoder selection logic doesn't report why it wasn't able to
create an ImageDecoder. It might be because insufficient data has
been received to sniff the image type, or it may be that we
definitely don't have a valid image type. This change exposes enough
information to tell the difference.

BUG=471272
==========

to

==========
Cancel image loads if decoding failed.

'Cancel' isn't really the right word for what this change does.
In the event of an image decoding failure, ImageResource will
synthesize a call to ResourceLoader::didFinishLoading, killing
the actual network request but reporting it as a successful
completion to the rest of blink. This matches our traditional
behavior of decoding errors looking like a successful
resource load (for the most part).

This requires some plumbing changes to image decoding, because
the decoder selection logic doesn't report why it wasn't able to
create an ImageDecoder. It might be because insufficient data has
been received to sniff the image type, or it may be that we
definitely don't have a valid image type. This change exposes enough
information to tell the difference.

BUG=471272
==========

[commit-bot: I haz the power, 2016-07-22 16:25:00]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-07-22 16:26:55]

Description was changed from

==========
Cancel image loads if decoding failed.

'Cancel' isn't really the right word for what this change does.
In the event of an image decoding failure, ImageResource will
synthesize a call to ResourceLoader::didFinishLoading, killing
the actual network request but reporting it as a successful
completion to the rest of blink. This matches our traditional
behavior of decoding errors looking like a successful
resource load (for the most part).

This requires some plumbing changes to image decoding, because
the decoder selection logic doesn't report why it wasn't able to
create an ImageDecoder. It might be because insufficient data has
been received to sniff the image type, or it may be that we
definitely don't have a valid image type. This change exposes enough
information to tell the difference.

BUG=471272
==========

to

==========
Cancel image loads if decoding failed.

'Cancel' isn't really the right word for what this change does.
In the event of an image decoding failure, ImageResource will
synthesize a call to ResourceLoader::didFinishLoading, killing
the actual network request but reporting it as a successful
completion to the rest of blink. This matches our traditional
behavior of decoding errors looking like a successful
resource load (for the most part).

This requires some plumbing changes to image decoding, because
the decoder selection logic doesn't report why it wasn't able to
create an ImageDecoder. It might be because insufficient data has
been received to sniff the image type, or it may be that we
definitely don't have a valid image type. This change exposes enough
information to tell the difference.

BUG=471272

Committed: https://crrev.com/520519605b961a7d979bc0eaa3c057a973dc26f1
Cr-Commit-Position: refs/heads/master@{#407171}
==========

[commit-bot: I haz the power, 2016-07-22 16:26:57]

Patchset 8 (id:??) landed as
https://crrev.com/520519605b961a7d979bc0eaa3c057a973dc26f1
Cr-Commit-Position: refs/heads/master@{#407171}

[Mark P, 2016-07-22 19:16:53]

A revert of this CL (patchset #8 id:140001) has been created in
https://codereview.chromium.org/2173603003/ by mpearson@chromium.org.

The reason for reverting is: 
Likely cause of failures:

webkit_tests webkit_tests:
http/tests/images/restyle-decode-error.html

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Mac10.11%20%28...

---
10:19:32.937 5109 worker/0 http/tests/images/restyle-decode-error.html started
10:19:32.953 5111 worker/2 accessibility/animation-policy.html passed
10:19:32.955 5111 worker/2
accessibility/anonymous-render-block-in-continuation-causes-crash.html started
10:19:32.999 5109 renderer crash, pid = None, error_line = #CRASHED - renderer
10:19:33.000 5109 killed pid 5357
10:19:33.000 5109 worker/0 http/tests/images/restyle-decode-error.html crashed,
(stderr lines):
10:19:33.000 5109   Received signal 11 <unknown> 000000000000
10:19:33.000 5109    [0x0001196ef23e]
...
10:19:33.002 5109   [end of stack trace]
10:19:33.002 5109  
[5358:13319:0722/101932:598964195783:ERROR:node_controller.cc(1099)] Could not
be introduced to peer C9E4F59A639F0E59.C2F8E762ADA8C89E
10:19:33.006 5084 [4832/40217] http/tests/images/restyle-decode-error.html
failed unexpectedly (renderer crashed)
10:19:33.003 5109 worker/0 killing primary driver
10:19:33.004 5109 worker/0 killing secondary driver
10:19:33.004 5109 worker/0 http/tests/images/restyle-decode-error.html failed:
10:19:33.004 5109 worker/0  renderer crashed
---

Also same failure on other bots such as
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Leak/b...

(ignore other webkit failures on this bot; those all have a known cause with a
fix incoming)
.