Home | Search | chromium - Builders
Login

Builder Win ASan Release Media Build 24284 Microsoft Windows

Results:

Success

Trigger Info:

Projectchromium
Revisiondcf09c7b1347f35a690e11fc7f592b678d5532db
Got Revisiondcf09c7b1347f35a690e11fc7f592b678d5532db

Execution:

Steps and Logfiles:

Show:
  1. ( 0 ) Failed to fetch step information from LogDog
    Log stream has no annotation entries

Build Properties:

NameValueSource

Blamelist:

  1. liberato@chromium.org (liberatoohnoyoudont@chromium.org)
  2. Henrique Grandinetti (hgrandinettiohnoyoudont@chromium.org)

Timing:

Create Thursday, 12-Jul-18 21:06:13 UTC
Start Thursday, 12-Jul-18 21:06:18 UTC
End Thursday, 12-Jul-18 21:25:53 UTC
Pending 4 secs
Execution 19 mins 35 secs

All Changes:

  1. Handle MCVD cleanup properly if texture has been destroyed.

    Changed by liberato@chromium.org - liberatoohnoyoudont@chromium.org
    Changed at Thursday, 12-Jul-18 21:05:18 UTC
    Repository https://chromium.googlesource.com/chromium/src
    Branch
    Revision dcf09c7b1347f35a690e11fc7f592b678d5532db

    Comments

    Handle MCVD cleanup properly if texture has been destroyed.
    
    If AbstractTexture drops its reference to the underlying texture,
    then that texture might have been freed.  This happens when the
    gl stub is lost.
    
    Previously, MCVD assumed that the CodecImage attached to the texture
    was valid.  However, if the AbstractTexture has dropped its ref
    to the texture, and there are no other refs, then this assumption
    isn't right.
    
    This CL checks if the AbstractTexture still has a TextureBase before
    referencing the CodecImage.
    
    An alternate approach of holding a scoped_refptr to the CodecImage
    in the callback would also work, but might keep the CodecImage
    around longer than it should when the stub is destroyed.  This can
    hold the MediaCodec open longer if the CodecImage has an unrendered
    codec buffer.
    
    Bug: 863012
    Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
    Change-Id: If83a9eb0c27d6eb8e995424bdf71f7f7bc93590d
    Reviewed-on: https://chromium-review.googlesource.com/1135697
    Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
    Commit-Queue: Frank Liberato <liberato@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#574717}

    Changed files

    • media/gpu/android/texture_pool.cc
    • media/gpu/android/video_frame_factory_impl.cc
  2. Fix wrong calculation of time on UsageTimeLimitProcessor.

    Changed by Henrique Grandinetti - hgrandinettiohnoyoudont@chromium.org
    Changed at Thursday, 12-Jul-18 21:04:17 UTC
    Repository https://chromium.googlesource.com/chromium/src
    Branch
    Revision 4e070c6b548e584a4e7934e88bcfb98a045518b1

    Comments

    Fix wrong calculation of time on UsageTimeLimitProcessor.
    
    The function that calculates wheter the time window limit of the current day is
    active, had a wrong logic.
    
    Bug: 860679
    Change-Id: Iafaaa54e36424033adaf384cdbc9c15d7aa2328e
    Reviewed-on: https://chromium-review.googlesource.com/1133459
    Reviewed-by: Jacob Dufault <jdufault@chromium.org>
    Reviewed-by: Alexander Alekseev <alemate@chromium.org>
    Commit-Queue: Henrique Grandinetti <hgrandinetti@google.com>
    Cr-Commit-Position: refs/heads/master@{#574716}

    Changed files

    • chrome/browser/chromeos/child_accounts/usage_time_limit_processor.cc
    • chrome/browser/chromeos/child_accounts/usage_time_limit_processor_unittest.cc