I'm able to repro this potential memory leak on TotT.


=================================================================
==8131:8131==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 1664 byte(s) in 104 object(s) allocated from:
    #0 0x53b7c3 in __interceptor_malloc (/usr/local/google/home/etienneb/chromium/src/out/clusterfuzz_5515632539074560/stylesheet_contents_fuzzer+0x53b7c3)
    #1 0x7f1ef6126411 in base::PartitionAllocGenericFlags(base::PartitionRootGeneric*, int, unsigned long, char const*) base/allocator/partition_allocator/partition_alloc.h:792:18
    #2 0x7f1ef6125f0d in base::PartitionAllocGeneric(base::PartitionRootGeneric*, unsigned long, char const*) base/allocator/partition_allocator/partition_alloc.h:813:10
    #3 0x7f1ef6125e93 in WTF::Partitions::FastMalloc(unsigned long, char const*) third_party/WebKit/Source/platform/wtf/allocator/Partitions.h:121:12
    #4 0x7f1ef6ed4934 in blink::CSSSelectorList::AdoptSelectorVector(WTF::Vector<std::__1::unique_ptr<blink::CSSParserSelector, std::__1::default_delete<blink::CSSParserSelector> >, 0ul, WTF::PartitionAllocator>&)
 third_party/WebKit/Source/core/css/CSSSelectorList.cpp:70:7
    #5 0x7f1ef73b976e in blink::CSSSelectorParser::ConsumeComplexSelectorList(blink::CSSParserTokenRange&) third_party/WebKit/Source/core/css/parser/CSSSelectorParser.cpp:55:10
    #6 0x7f1ef73b8d65 in blink::CSSSelectorParser::ParseSelector(blink::CSSParserTokenRange, blink::CSSParserContext const*, blink::StyleSheetContents*) third_party/WebKit/Source/core/css/parser/CSSSelectorParser.
cpp:25:35
    #7 0x7f1ef735bca1 in blink::CSSParserImpl::ConsumeStyleRule(blink::CSSParserTokenRange, blink::CSSParserTokenRange) third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp:814:7
    #8 0x7f1ef734ddb5 in blink::CSSParserImpl::ConsumeQualifiedRule(blink::CSSParserTokenRange&, blink::CSSParserImpl::AllowedRulesType) third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp:520:12
    #9 0x7f1ef735065f in bool blink::CSSParserImpl::ConsumeRuleList<blink::CSSParserImpl::ParseStyleSheet(WTF::String const&, blink::CSSParserContext const*, blink::StyleSheetContents*, bool)::$_0>(blink::CSSParse
rTokenRange, blink::CSSParserImpl::RuleListType, blink::CSSParserImpl::ParseStyleSheet(WTF::String const&, blink::CSSParserContext const*, blink::StyleSheetContents*, bool)::$_0) third_party/WebKit/Source/core/css
/parser/CSSParserImpl.cpp:430:16
    #10 0x7f1ef734f144 in blink::CSSParserImpl::ParseStyleSheet(WTF::String const&, blink::CSSParserContext const*, blink::StyleSheetContents*, bool) third_party/WebKit/Source/core/css/parser/CSSParserImpl.cpp:240
:14
    #11 0x7f1ef73232b0 in blink::CSSParser::ParseSheet(blink::CSSParserContext const*, blink::StyleSheetContents*, WTF::String const&, bool) third_party/WebKit/Source/core/css/parser/CSSParser.cpp:70:10
    #12 0x7f1ef725c78a in blink::StyleSheetContents::ParseStringAtPosition(WTF::String const&, WTF::TextPosition const&) third_party/WebKit/Source/core/css/StyleSheetContents.cpp:397:3
    #13 0x7f1ef725c69e in blink::StyleSheetContents::ParseString(WTF::String const&) third_party/WebKit/Source/core/css/StyleSheetContents.cpp:389:3
    #14 0x56951d in LLVMFuzzerTestOneInput third_party/WebKit/Source/core/css/StyleSheetContentsFuzzer.cpp:21:15
    #15 0x57a28f in main third_party/libFuzzer/src/afl/afl_driver.cpp:287:7
    #16 0x7f1eb8173f44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287

I'm adding a call to the Garbage collector at the end of the test and the leak is gone.

  blink::ThreadState* currentThreadState = blink::ThreadState::Current();
  currentThreadState->CollectAllGarbage();

For more details, see comment in: https://chromium-:review.googlesource.com/c/602070/

The attachment shows the difference between reported potential memory leaks without/with the call to GC.

Deleted: calling-gc.png 84.8 KB

	calling-gc.png 84.8 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6018356b662d5a88cd30f906e4f041c68c8c3f6

commit b6018356b662d5a88cd30f906e4f041c68c8c3f6
Author: Etienne Bergeron <etienneb@chromium.org>
Date: Tue Aug 08 18:15:54 2017

Call garbage collector when running with LSAN

LSAN is reporting objects that are allocated with PartitionAlloc
(replaced by Malloc when using LSAN). These object are kept alive
because some Blink (oilpan) objects are retaining them.

In this case, StyleRule is a oilpan garbage collected object but has
a member of type |CSSSelectorList| which is not garbage collected.

  see: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/StyleRule.h?q=StyleRule&sq=package:chromium&dr=CSs&l=146


This CSSSelector is retaining the object reported as a leak:
  see: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/css/CSSSelectorList.h?sq=package:chromium&dr=CSs&l=130


By calling the GC, the StyleRule are freed and it is releasing the memory allocated by PartitionAlloc.

Bug:  743134 
Change-Id: Iea84298e4b087c6007124b436243c08bb381a4a9
Reviewed-on: https://chromium-review.googlesource.com/602070
Reviewed-by: Keishi Hattori <keishi@chromium.org>
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#492701}
[modify] https://crrev.com/b6018356b662d5a88cd30f906e4f041c68c8c3f6/third_party/WebKit/Source/core/css/StyleSheetContentsFuzzer.cpp

ClusterFuzz has detected this issue as fixed in range 492542:492701.

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

Fuzzer: afl_stylesheet_contents_fuzzer
Job Type: afl_chrome_asan
Platform Id: linux

Crash Type: Direct-leak
Crash Address: 
Crash State:
  PartitionAllocGenericFlags
  PartitionAllocGeneric
  FastMalloc
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=afl_chrome_asan&range=415614:415641
Fixed: https://clusterfuzz.com/revisions?job=afl_chrome_asan&range=492542:492701

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


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

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