So, the issue is the bad crash state due to unavailable stack frames.

Kostya, any idea why this assert failure on libfuzzer debug builds is not giving any stack frames other than the gsignal frame (from c assert macro, see crash line - 
https://cs.chromium.org/chromium/src/third_party/icu/source/i18n/regexcmp.cpp?rcl=0&l=2298
https://cs.chromium.org/chromium/src/third_party/icu/source/common/uassert.h?rcl=1477251372&l=13

See also example from https://github.com/google/oss-fuzz/issues/50.

ASAN_OPTIONS=fast_unwind_on_fatal=0 helps: 


ASAN_OPTIONS=fast_unwind_on_fatal=0   ./out/libfuzzer/icu_uregex_open_fuzzer  ~/Downloads/fuzz-3-icu_uregex_open_fuzzer 
INFO: Seed: 3702750872
INFO: Loaded 0 modules (0 guards): 
./out/libfuzzer/icu_uregex_open_fuzzer: Running 1 inputs 1 time(s) each.
Running: /usr/local/google/home/kcc/Downloads/fuzz-3-icu_uregex_open_fuzzer
icu_uregex_open_fuzzer: ../../third_party/icu/source/i18n/regexcmp.cpp:2298: void icu_56::RegexCompile::handleCloseParen(): Assertion `minML <= maxML' failed.
==664== ERROR: libFuzzer: deadly signal
    #0 0x4cbe50 in __sanitizer_print_stack_trace (/usr/local/google/home/kcc/chromium/src/out/libfuzzer/icu_uregex_open_fuzzer+0x4cbe50)
    #1 0x54e8a2 in fuzzer::Fuzzer::CrashCallback() third_party/libFuzzer/src/FuzzerLoop.cpp:228:5
    #2 0x54e7b6 in fuzzer::Fuzzer::StaticCrashSignalCallback() third_party/libFuzzer/src/FuzzerLoop.cpp:217:6
    #3 0x5af557 in fuzzer::CrashHandler(int, siginfo*, void*) third_party/libFuzzer/src/FuzzerUtil.cpp:80:3
    #4 0x7f410206e32f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1032f)
    #5 0x7f4101ab9c36 in gsignal /build/eglibc-oGUzwX/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56
    #6 0x7f4101abd027 in abort /build/eglibc-oGUzwX/eglibc-2.19/stdlib/abort.c:89
    #7 0x7f4101ab2bf5 in __assert_fail_base /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:92
    #8 0x7f4101ab2ca1 in __assert_fail /build/eglibc-oGUzwX/eglibc-2.19/assert/assert.c:101
    #9 0x7f410447a50d in icu_56::RegexCompile::handleCloseParen() third_party/icu/source/i18n/regexcmp.cpp:2298:13
    #10 0x7f4104467cba in icu_56::RegexCompile::doParseActions(int) third_party/icu/source/i18n/regexcmp.cpp:738:9
    #11 0x7f4104460454 in icu_56::RegexCompile::compile(UText*, UParseError&, UErrorCode&) third_party/icu/source/i18n/regexcmp.cpp:235:13
    #12 0x7f410452975b in icu_56::RegexPattern::compile(UText*, unsigned int, UParseError&, UErrorCode&) third_party/icu/source/i18n/repattrn.cpp:389:14
    #13 0x7f41046bb821 in uregex_open_56 third_party/icu/source/i18n/uregex.cpp:155:20
    #14 0x4f28df in LLVMFuzzerTestOneInput third_party/icu/fuzzers/icu_uregex_open_fuzzer.cc:14:28

I frankly don't remember exactly why this is not default. 
(There were some stability problems with the system unwinder os some such). 

Thanks Kostya, that fixes it. Crash state is now there on https://cluster-fuzz.appspot.com/v2/testcase-detail/6489461087272960 (just added some exclusions for __assert_ unneeded frames).

Since this is only seeing in libfuzzer debug builds, i have enabled this in libfuzzer's debug job type only. fast_unwind_on_fatal was set to 1 long time back for clusterfuzz, i think it helped in better crash stacks in v8, see https://codereview.chromium.org/668343002.

Kostya, do you need to track any bug on libFuzzer/sanitizer side for this issue. Otherwise, workaround works and we can mark this as Fixed. 

I don't see this problem anywhere else for now, so let's mark as fixed.