This issue looks similar to Bug ID - 709942, so assigning to the concern owner.
@mmoroz -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

Looks like the regression list does not have any of my changes? And sorry I am not quite familiar with template_url_data.cc. 
@pkasting, do you have any idea what could be the problem of it or who could help with it?

 Issue 709942  has been merged into this issue.

I think this was introduced in https://codereview.chromium.org/1135163002 .  I didn't look deeply, but at a glance, it looks as if the parsing code allowed empty short names but caught them later, whereas now there's a DCHECK at the time the short name is parsed (and the later checks don't make sense).

It's not instantly obvious what the right fix is; either the logic checks in the parser need to move earlier, or this DCHECK is wrong.

ClusterFuzz has detected this issue as fixed in range 465929:466779.

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

Fuzzer: libfuzzer_template_url_parser_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !short_name.empty() in template_url_data.cc
  TemplateURLData::SetShortName
  TemplateURLParsingContext::EndElementImpl
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=465905:465929
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=465929:466779

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


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.

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

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

Out of laziness, I'm going to trust clusterfuzz (as opposed to investigating the original test case) and leave this bug closed.

I'm sure this is not fixed, as nothing has changed in the code.  This just plain looks wrong on inspection.

pkasting@ is right; this does appear to be a real issue.

I think the problem can be fixed by adding another test around here:
https://chromium.googlesource.com/chromium/src.git/+/HEAD/components/search_engines/template_url_fetcher.cc#164

Downgrading priority because this is a DCHECK, not a CHECK.

I cannot repro this issue using the fuzzer at top of tree, not even in debug mode.  Nonetheless, I'll prep some code that I think will fix it.

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

commit ee5a39ceca0897f43f63059d44635da6f02d0a50
Author: mpearson <mpearson@chromium.org>
Date: Thu Jun 01 01:14:22 2017

Omnibox - Open Search - Handle Lack of Short Name Smartly

BUG= 714081 

Review-Url: https://codereview.chromium.org/2902043004
Cr-Commit-Position: refs/heads/master@{#476125}

[modify] https://crrev.com/ee5a39ceca0897f43f63059d44635da6f02d0a50/chrome/browser/search_engines/template_url_fetcher_unittest.cc
[add] https://crrev.com/ee5a39ceca0897f43f63059d44635da6f02d0a50/chrome/test/data/simple_open_search_no_name.xml
[modify] https://crrev.com/ee5a39ceca0897f43f63059d44635da6f02d0a50/components/search_engines/template_url_data.cc
[modify] https://crrev.com/ee5a39ceca0897f43f63059d44635da6f02d0a50/components/search_engines/template_url_parser.cc
[add] https://crrev.com/ee5a39ceca0897f43f63059d44635da6f02d0a50/components/test/data/search_engines/simple_open_search_no_name.xml

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.