Fix unknown ubsan crash types

[ViniciustCosta]

This should fix the following unknown ubsan crash types (https://screenshot.googleplex.com/C4sGA6UKssV4Gms.png):

• assumption is violated during execution
• upcast of null pointer of type <type>

These two are actually related to golang specific crashes:

• slice bounds out of range [:-1]
• index out of range [-1]
  It should be fixed by checking the golanc specific crash types before the generic UBSan, since if it is a golang crash, it will set the crash_type and it will not enter the generic UBSan block.

Added unit test for the new ubsan types.

b/473559705

[jonathanmetzman]

Can you do a query and check if there are others?

[ViniciustCosta]

Can you do a query and check if there are others?

Sure, here it is (probably not the best way to do it, but it confirms there aren't others): https://cloudlogging.app.goo.gl/Ff7E3wkP3VnrGdt17

[jonathanmetzman]

lgtm

[ViniciustCosta]

Actually, just found another one: Unknown UBSan crash type: upcast of null pointer of type (https://cloudlogging.app.goo.gl/xaZ8UXKAGnV62ofP8)

[ViniciustCosta]

Also, I think the out of range crashes are not actually UBSan, but rather an expected golang specific crash type that is not being correctly treated.

AFAICT all projects reporting these as unknown crash types are go project (jobs: libfuzzer_asan_mtail, libfuzzer_asan_gitea, libfuzzer_asan_openkruise) and even though the constants for these crash types exist (https://github.com/google/clusterfuzz/blob/master/src/clusterfuzz/stacktraces/constants.py#L338), they are reaching the UBSan codepath (probably due to runtime error: being the ubsan expected regex).

[ViniciustCosta]

PTAL. I added the real two new types as non security issues, please let me know if you think otherwise.

[jonathanmetzman]

LGTM

[jonathanmetzman]

I hope this doesn't break anything.

[jonathanmetzman]

Thanks!

[jonathanmetzman]

Actually. I'm not sure what's the right thing to do here.