XPI files from update checks are not removed from /data/data/org.mozilla.firefox_beta/app_tmpdir
Categories
(Toolkit :: Add-ons Manager, defect, P2)
Tracking
()
People
(Reporter: robwu, Assigned: robwu)
References
(Depends on 1 open bug)
Details
The data directory on my phone is almost 3GB, with the vast majority consumed by .xpi files in /data/data/org.mozilla.firefox_beta/app_tmpdir. It used to be once a day (on Fennec), but on Fenix it seems like it can happen multiple times a day, often multiple within a few minutes.
The xpi file looks like it belongs to uBlock Origin. I'm pretty sure that those XPI files were created as part of an update check, because the timestamps coincide with the period that I didn't update uBlock Origin (because I wanted to test bug 1630413). Based on this, the STR would be:
- Upload an add-on to AMO.
- Install add-on in Fenix. Currently only Nightly supports the installation of arbitrary add-ons, so use https://blog.mozilla.org/addons/2020/09/29/expanded-extension-support-in-firefox-for-android-nightly/
- Upload a new version of the add-on to AMO, with a new permission that requires approval from the user.
- Wait a few days.
- Look for xpi files in
/data/data/org.mozilla.fenix/app_tmpdir. In particular, look at the timestamps.
As long as this bug is active, multiple XPI files will be created every day
There is another report of a similar issue at bug 1532446, but the file name is different. The file seems to be generated by generateTemporaryFile, and DownloadAddonInstall is supposedly responsible for removing the file. I guess that it doesn't happen.
We should:
- Figure out why these files are not removed.
- Figure out why the xpi files are downloaded multiple times within a few minutes.
- Delete old xpi files at some point, to free up some space. Even without this bug, we should still occasionally check for stale files because the app could be killed before it had a chance to remove the file.
Here is some relevant output from ADB (retrieved via a root shell in recovery mode).
# du -cm /data/data/org.mozilla.firefox_beta/app_tmpdir/*.xpi | tail -n1
2937 total
# ls -l /data/data/org.mozilla.firefox_beta/app_tmpdir/*.xpi | wc -l
1102
# ls -lt /data/data/org.mozilla.firefox_beta/app_tmpdir/*.xpi | head -n20 | awk '{print $5, $6, $7, $8}'
2796945 2020-10-07 23:19 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-ytz.xpi
2774487 2020-09-29 23:12 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-bb5.xpi
2805136 2020-08-25 14:31 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-4bi.xpi
2805136 2020-08-25 09:31 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-rwt.xpi
2805136 2020-08-25 04:31 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-q4i.xpi
2805136 2020-08-24 23:29 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-mrq.xpi
2805136 2020-08-24 18:29 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-uy6.xpi
2805136 2020-08-24 13:29 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-qd3.xpi
2805136 2020-08-24 08:25 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-5q7.xpi
2805136 2020-08-24 03:24 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-m0e.xpi
2805136 2020-08-23 22:23 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-ci5.xpi
2805136 2020-08-23 17:23 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-xpe.xpi
2805136 2020-08-23 12:23 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-zzh.xpi
2805136 2020-08-23 08:07 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-lwc.xpi
2805136 2020-08-23 05:48 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-vac.xpi
2805136 2020-08-23 04:20 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-4q2.xpi
2805136 2020-08-23 03:31 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-9x3.xpi
2805136 2020-08-23 03:10 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-3ad.xpi
2805136 2020-08-23 03:02 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-9eo.xpi
2805136 2020-08-23 02:57 /data/data/org.mozilla.firefox_beta/app_tmpdir/tmp-brg.xpi
|
||
Comment 2•4 years ago
|
||
Hey Agi, can you please look into what's going on here?
|
||
Comment 3•4 years ago
|
||
I wonder if this is somehow a regression from Bug 1629952. Looking.
|
|
||
Comment 4•4 years ago
|
||
|
||
Comment 5•4 years ago
|
||
I'm still trying to reproduce the issue on the ac side, which ever are the results, I will keep you posted. We still need a fix on the GV side for pruning the stale files as on AC we don't have control over them.
|
Assignee | |
Updated•4 years ago
|
|
|
||
Comment 6•4 years ago
|
||
We found the source of the issue on the AC side you can find all the details on the patch here.
|
|
Assignee | |
Comment 7•4 years ago
|
||
Thanks Arturo for the quick fix.
Now it's our turn, to clean up stale temp files if any. Although I will probably not get to it soon, I'll assign it to myself to keep track of it.
|
|
||
Comment 8•4 years ago
|
||
👍
|
||
Comment 9•3 years ago
|
||
Does this issue need to be open? Anything else to do here? I think the cleanup was included as part of bug 1685556.
|
|
Assignee | |
Comment 10•3 years ago
|
||
Step 1 and 2 have been fixed by https://github.com/mozilla-mobile/android-components/pull/8708
The last step was done by bug 1685556.
It would be nice to verify the fix, but in the worst case the user can still free up space by clearing the caches, so I'm not that concerned.
|
|
Assignee | |
Comment 11•2 years ago
|
||
(In reply to Rob Wu [:robwu] from comment #0)
We should:
- Figure out why these files are not removed.
While the A-C fix does resolve the issue of having many tmpaddon files, there are still some cases of tmpaddon files that are not getting deleted. I have explained how that happens in bug 1753110.
Description
•