Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

I can confirm that this is caused by my recent https://crrev.com/c/1409457.
I will work on fixing this.

And because running msan is a little complicated due to the use of docker, I am glad this can be reproduced in other configurations (asan debug in my case) with lowering the memory limit using -rss_limit_mb=

I spoke too soon. On asan (as opposed to msan), the memory consumed after my CL is actually lower. Will investigate further.

It seems that the parser actually changed the behaviour quite significantly. On the fuzzer's input, before the CL it produced about 30 thousands of records, after the CL it was over 500 thousand (!). The input contains a lot of line breaks, which seems to match this. I'm investigating what exactly happens, how to fix it and what regression test to add.

== Reason of breakage ==

The input starts with the first row followed by a lot of '\r' (CR) characters and then a '\n' (LF).

The old parser would understand the '\r's as part of the string value, while the new one would just treat '\r' the same as '\n' -- end of line.

The RFC 4180 seems to only specify the line break as "\r\n", so actually neither of the parsers follows it properly (both accept single "\n" as line breaks). But for good portability and because the line break is represented differently on Win (CRLF), Mac (CR) and Linux (LF), it seems more desirable to accept just about any combination of CR and LF as a line break.

Following that idea, the second parser is correct not to regard the CRs as part of the field value. However, adding "empty" records, i.e., records where there is only one field, with an empty string as a value, is useless (remember: this should be used for importing passwords, which are always non-empty).

== Plan ==

I'll keep the parsing of the new parser, but make it skip "empty" records.

For the record, after implementing the plan from #6, the number of records extracted from the fuzzer's input dropped to about 1 thousand.

CL in https://crrev.com/c/1424302

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

commit fac4c96fb07f09b54011efc9a7fc0ab61be1d1de
Author: Vaclav Brozek <vabr@chromium.org>
Date: Mon Jan 21 08:26:29 2019

Skip empty lines in CSV parser

If the input to the CSV parser contains a sequence of characters from
the set {'\r', '\n'}, the parser sees a lot of empty rows.
Transforming those into the structured output creates a lot of
single-element maps with the empty string as the value. Those are not
useful for the task the parser is used for (importing passwords) but
adding them costs memory and performance.

Therefore this CL starts skipping empty rows.

Bug:  923700 
Change-Id: I1ec5ec10c2425d497c4c611167240469e38ede2f
Reviewed-on: https://chromium-review.googlesource.com/c/1424302
Reviewed-by: Jan Wilken Dörrie <jdoerrie@chromium.org>
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#624531}
[modify] https://crrev.com/fac4c96fb07f09b54011efc9a7fc0ab61be1d1de/components/password_manager/core/browser/import/csv_reader.cc
[modify] https://crrev.com/fac4c96fb07f09b54011efc9a7fc0ab61be1d1de/components/password_manager/core/browser/import/csv_reader_unittest.cc

On my machine I could confirm that r624531 above fixed the issue on msan.

Re #c6: Mac switched to LF endings with Mac OS X, released in 2001 [1]. Because of this, I think we should restore the old parser's behavior, and only treat '\r\n' and '\n' as new lines. Implementation wise this should be straight forward, as it's effectively splitting on '\n', and removing a single trailing '\r' if present.

[1] https://superuser.com/q/439440

Thanks for pointing this out, Jan! Not sure where I picked up the CR myth, I'm pretty sure I have not even seen a Mac before 2001. :)

I filed bug 923811 and am writing on my virtual blackboard: "I will check my assumptions" 100 times. :)