+hzl -- possibly related to why we're having trouble symbolizing crashes elsewhere?

Looks like we stopped getting the libchrome.so file on 4/15/16 between these two builds on April 15

asan-android-release-l-325843.zip 2.06 GB application/zip   4/15/16, 8:37 AM		 
asan-android-release-l-325844.zip 149.33 MB application/zip 4/15/16, 11:20AM

And it looks like they've returned as of 9am today.
asan-android-release-l-329253.zip 149.68 MB application/zip 5/2/16, 2:43 PM		
asan-android-release-l-329308.zip 548.36 MB application/zip 5/3/16, 9:11 AM

Looks like this CL might have added the libchrome.so back? Looks like it was a temporary GN issue?

https://chromereviews.googleplex.com/415377014

Not sure whether this bug is related to the following bug: https://bugs.chromium.org/p/chromium/issues/detail?id=607814. Does clusterfuzz send reports to chrome crash?

Make sense that the CL in #4 would fix this. I don't think it's related to bug #607814 though, since dev build symbols are uploaded by a official_buildbot.sh and not by the recipes referenced by #4.

Thanks Andrew for fixing this. Looks like latest builds do have libchrome.so now. 

Manu, Anantha - Can you please check why this was not caught in the android triage process for 2 weeks. A lot of crash reports were showing up with crash state like 
libchrome.so
libchrome.so
libchrome.so, so this weirdness should be caught earlier.

Hi Abhishek, We have noticed this failure however the stack trace looks clueless since TE doesn't know the back ground. We will make sure to file these kind of issues going forward.

Thank you!

Yes Manu, if you start seeing weird looking stacks suddenly example with library names, definitely ping us for more information or analysis.

sure Abhishek, Thank you!