Could someone take a look? Seems like a critical issue for users O_O

Attach symbolized stack trace here

Deleted: symbolized_stack_trace.txt 227 KB

symbolized_stack_trace.txt 227 KB View Download

I would have the storage team take a look at this. I'm going to be pretty useless for a while, I'm currently on vacation and then traveling to Mountain View, but I probably won't be productive on Android for a while.

Furthermore, the crash looks unrelated to my code (although I doubt the stack is correct) but even so, if it fails to delete data then the storage team should take a look -- my code is just calling an API I think they own.

Daniel, do you know who would be a good candidate?

Is this only happening on Android? 

The stacktrace looks like the crash is caused by the destructor of CookieTreeMediaLicensesNode. Media licenses have recently been added on Android.

xhwang, you worked on medialicenses for Android, could you take a look?

Thank you guys for replying. I only tested this on Android so far. I have found two similar crbug:
https://bugs.chromium.org/p/chromium/issues/detail?id=765011
https://bugs.chromium.org/p/chromium/issues/detail?id=765144

I think the crash is not the first issue the users would face. The first issue the users would face is that they cannot clear site storage successfully sometimes

Clearing "Media Licenses" is only added in M62. However, CookieTreeMediaLicenseNode was added last year, which should only be used on desktop Chrome.

jrummell: Could you please take a look how we could trigger CookieTreeMediaLicenseNode to crash on Android in M61?

I attached a screenshot here. You can see the storage size is already cleared, but user can still see the sites in the UI page.

Deleted: 1.png 98.5 KB

	1.png 98.5 KB View Download

If all data is removed, this is probably related to a bug with localstorage  https://crbug.com/679344 .
The actual data is deleted but it needs some time until we can cleanup the database. 
I will look into this to check if something else is left after clearing storage.

By looking at go/crashes, only a super small percentage of crashes related to SiteDataDeleteHelper has CookieTreeMediaLicenseNode in the callstack. So we doubt it's actually caused by CookieTreeMediaLicenseNode. Given the crash is in a deep destructor chain, it might be memory related, e.g. we are destructing an already deleted SiteDataDeleteHelper object.

jrummell@ will confirm that CookieTreeMediaLicenseNode should not do anything on Android. Then we should use #if/def to disable CookieTreeMediaLicenseNode on Android altogether.

I want to call out here. The crash only happens when user finds clicking on"clear site storage" is not working and keeps clicking on it. So, I think it could be "we are destructing an already deleted SiteDataDeleteHelper object".

But the main issue here I think is not the crash, it's why clearing site storage is not working, because if it's working the users wouldn't keep clicking it.

That makes sense. Then there seems to be two bugs:
1. clearing doesn't work
2. crash when user keeps clicking "clear site storage"

Neither seems to be directly related to CookieTreeMediaLicenseNode jrummell@ owns. I'll remove jrummell@ from the Owner and please find a proper owner for this issue.

We found the root cause of this bug. It's a mojo-local-storage. After adding a flag "--disable-mojo-local-storage", the bug is solved.

Relevant code:
https://cs.chromium.org/chromium/src/content/browser/dom_storage/dom_storage_context_wrapper.cc?type=cs&l=153

It's the code added in M61

As mentioned in #9, this sounds like the same issue as 679344. In other words, storage is cleared correctly, but sometimes sites without any storage are still shown in the UI anyway.

Even though this is resolved as a duplicate of  issue 679344 , adding comments in case others have similar issues.

As for the crash, it appears that the references to CookieTreeMediaLicensesNode are due to code folding. CookieTreeMediaLicensesNode : CookieTreeNode, and there appear to be 25 other implementations. All the destructors for those 26 classes are simply {}, so I'm assuming that CookieTreeMediaLicensesNode just happens to be the shared instance kept by the linker (it's the last one defined in the file). The other clue is that CookieTreeMediaLicensesNode appears twice in the callstack. If I remember correctly, CookieTreeMediaLicensesNode should hold CookieTreeMediaLicenseNode (no 's' on License).

Unfortunately there's nothing else in the stack trace to indicate what object is messed up. Each TreeNode has member std::vector<std::unique_ptr<NodeType>> children_, and it's being destructed. Looks like code folding has picked std::vector<std::unique_ptr<SpdyBufferProducer>> as the common code, and nothing in CookieTreeNode has any reference to Spdy objects.

However, after some discussion, the question of why CookieTreeMediaLicensesNode show up on Android came up. Opened issue 767574 to track investigating that. However, it is independent of this issue.