Predator and CL could not provide any possible suspects.
Using the code search for the file, “pickle.cc” assigning to concern owner from GIT blame.
Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/0d89f9222889a53af3ce028f6c6078e38921ddce
@dcheng  -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes.
Thank You.

There's really not much to be done here. realloc failed; probably because we're writing a giant string.

(One thing I'm slightly surprised about is the fact that realloc failure didn't terminate the process; CCing random people who know things about this sort of stuff)

At this point in time it is possible for any odd failure to be VS 2017 related since we switched just seven days ago. Maybe the trapping of realloc failures got broken? I can test.

I added this code to one of base_unittests:

  printf("_MSC_VER = %d.\n", _MSC_VER);
  for (;;) {
    if (!malloc(500000000)) {
      printf("Failed?\n");
      break;
    }
    printf("Next try...\n");
  }

I then built and ran it with VS 2015 and VS 2017 (don't forget to do a "gclient runhooks and gn clean" after setting GYP_MSVS_VERSION, and some VS 2017-requiring code may need commenting out). The results I got are shown below (1900 == VS 2015, 1911 == VS 2017). These are from a 32-bit release non-component build:

_MSC_VER = 1911.
Next try...
Next try...
Next try...
Next try...
Next try...
Next try...
Failed?

_MSC_VER = 1900.
Next try...
Next try...
Next try...
Next try...
Next try...
Next try...
Failed?

So, this hasn't been working for a while? But I thought it was supposed to. Adding another expert...

I'm not sure why base::EnableTerminationOnOutOfMemory() isn't kicking in here. https://cs.chromium.org/chromium/src/base/process/memory_win.cc?type=cs&q=enableterminationon&sq=package:chromium&l=61

According to https://msdn.microsoft.com/en-us/library/xbebcx7d.aspx, realloc uses malloc to observe _set_new_mode(1).

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

wfh@ - can you comment on what the expectations are? Should base_unittests abort on OOM, or is that only for other binaries?

ClusterFuzz has detected this issue as fixed in range 510178:510722.

Detailed report: https://clusterfuzz.com/testcase?key=5503366385106944

Fuzzer: jsbell_serviceworker
Job Type: windows_asan_chrome_no_sandbox
Platform Id: windows

Crash Type: CHECK failure
Crash Address: 
Crash State:
  p in pickle.cc
  base::Pickle::Resize
  base::Pickle::WriteString16
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=480776:480824
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=510178:510722

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5503366385106944

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5503366385106944 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.