New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database tool hanging #488

Closed
danielling23 opened this Issue Sep 9, 2016 · 3 comments

Comments

2 participants
@danielling23

danielling23 commented Sep 9, 2016

As reported on XDA, SD Maid is getting stuck after optimizing the databases in the comparing stage. The display shows that it is stuck in comparing "contact_manager_kv.db" which is a file from the Dropbox app. However when I tried to do the file manually, there's no problems optimizing the file which is less than 1k in size.

I have encountered the same issue in the past 4 releases of Android update

6.0.1
MTC19F
MTC19X
MTC20F

7.0
NRC90M
NRD90U

Attached is the debug file generated as requested on XDA.

sdmaid_logfile_1473392659641.log.gz

@d4rken d4rken changed the title from SD Maid issue reported on XDA to Database tool hanging Sep 9, 2016

@d4rken d4rken added this to the v4.3.2 milestone Sep 9, 2016

@d4rken

This comment has been minimized.

Owner

d4rken commented Sep 9, 2016

Version

F: VERSIONNAME:4.3.1; VERSIONCODE:40301
P: VERSIONNAME:4.0.7; VERSIONCODE:40007

Device

ro.build.id=NRD90U
ro.build.display.id=NRD90U
ro.build.version.incremental=3155372
ro.build.version.sdk=24
ro.build.version.preview_sdk=0
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=7.0
ro.build.version.security_patch=2016-09-06
ro.build.version.base_os=
ro.build.date=Wed Aug 17 23:11:29 UTC 2016
ro.build.date.utc=1471475489
ro.build.type=user
ro.build.user=android-build
ro.build.host=vpak29.mtv.corp.google.com
ro.build.tags=release-keys
ro.build.flavor=angler-user
ro.product.model=Nexus 6P
ro.product.brand=google
ro.product.name=angler
ro.product.device=angler
ro.product.board=angler
ro.product.cpu.abi=arm64-v8a
ro.product.cpu.abilist=arm64-v8a,armeabi-v7a,armeabi
ro.product.cpu.abilist32=armeabi-v7a,armeabi
ro.product.cpu.abilist64=arm64-v8a
ro.product.manufacturer=Huawei
ro.product.locale=en-US
ro.build.product=angler
ro.build.description=angler-user 7.0 NRD90U 3155372 release-keys
ro.build.fingerprint=google/angler/angler:7.0/NRD90U/3155372:user/release-keys
ro.build.characteristics=nosdcard
ro.build.expect.bootloader=angler-03.58
ro.build.expect.baseband=angler-03.72
@d4rken

This comment has been minimized.

Owner

d4rken commented Sep 9, 2016

I think I found the issue.

In contrast to the initial size checking and the vacuum operation, the 'post vacuum' size checking was all done in one task.
This likely got the shell stuck (input buffer running full?), which is at least what the log looks like (see end of log).

Not sure why this is a rather rare occurence, maybe your database count (~880) is unusually high?

Should be fixed with v4.3.2, otherwise, please reopen.

Good reports!

@d4rken d4rken closed this Sep 9, 2016

@danielling23

This comment has been minimized.

danielling23 commented Sep 9, 2016

Thanks Matthias. Yeah, buffer running full could cause it. Look forward to the fixed version. There are many apps with more than 5 database files each. Thanks for the quick diagnosis.

Regards,

Daniel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment