Tencent/tinker · error · TinkerRuntimeException
readAndCheckPropertyWithLock fail
Error message
readAndCheckPropertyWithLock fail
What it means
SharePatchInfo.readAndCheckPropertyWithLock acquires a file lock and then reads/validates the patch info file (pathInfoFile). Any exception during lock acquisition, file read, or field checking is wrapped in TinkerRuntimeException("readAndCheckPropertyWithLock fail", e). The cause identifies whether it was locking, IO, or content validation.
Source
Thrown at tinker-android/tinker-android-loader/src/main/java/com/tencent/tinker/loader/shareutil/SharePatchInfo.java:92
this.isRemoveInterpretOATDir = isRemoveInterpretOATDir;
}
public static SharePatchInfo readAndCheckPropertyWithLock(File pathInfoFile, File lockFile) {
if (pathInfoFile == null || lockFile == null) {
return null;
}
File lockParentFile = lockFile.getParentFile();
if (!lockParentFile.exists()) {
lockParentFile.mkdirs();
}
SharePatchInfo patchInfo;
ShareFileLockHelper fileLock = null;
try {
fileLock = ShareFileLockHelper.getFileLock(lockFile);
patchInfo = readAndCheckProperty(pathInfoFile);
} catch (Exception e) {
throw new TinkerRuntimeException("readAndCheckPropertyWithLock fail", e);
} finally {
try {
if (fileLock != null) {
fileLock.close();
}
} catch (IOException e) {
ShareTinkerLog.w(TAG, "releaseInfoLock error", e);
}
}
return patchInfo;
}
public static boolean rewritePatchInfoFileWithLock(File pathInfoFile, SharePatchInfo info, File lockFile) {
if (pathInfoFile == null || info == null || lockFile == null) {
return false;
}
File lockParentFile = lockFile.getParentFile();View on GitHub (pinned to 1b7ea02c23)
Solutions
- Log the cause exception to distinguish lock failure vs corrupted info file.
- Ensure the patch info directory is fully written (rewritePatchInfoFileWithLock) before reading, and that only one process loads patches.
- If the info file is corrupted, clean the app's tinker directory (or reinstall) so patch state is rebuilt.
- Free up storage and check file permissions on the info directory.
- Catch TinkerRuntimeException around patch-load APIs and mark the patch as failed rather than crashing.
Example fix
// before
patchInfo = SharePatchInfo.readAndCheckPropertyWithLock(infoFile, lockFile);
// after
try {
patchInfo = SharePatchInfo.readAndCheckPropertyWithLock(infoFile, lockFile);
} catch (TinkerRuntimeException e) {
ShareTinkerLog.e(TAG, "patch info unreadable, clean state", e);
patchInfo = null;
} Defensive patterns
Strategy: try-catch
Validate before calling
if (!infoFile.exists() || infoFile.length() == 0) {
// no patch info yet: nothing to read, skip the locked read
} Try / catch
try {
patchInfo = SharePatchInfo.readAndCheckPropertyWithLock(infoFile, lockFile);
} catch (TinkerRuntimeException e) {
Throwable cause = e.getCause(); // lock vs IO vs validation
patchInfo = null; // treat as 'no valid patch state'
} Prevention
- Write patch info before reading it (correct apply ordering).
- Single-process patch loading to avoid lock contention.
- Free storage and ensure tinker directory writability before patch ops.
When it happens
Trigger: Calling readAndCheckPropertyWithLock when the lock file cannot be locked (see FileLockHelper failure), the info file is missing/corrupted, or its fields (version strings, paths) fail validation.
Common situations: First patch load where /tinker/info is incomplete; concurrent access by two processes; corrupted info file after a crash mid-write; disk-full during read; stale lock from a previous run.
Related errors
- rewritePatchInfoFileWithLock fail
- Tinker Exception:FileLockHelper lock file failed: {}
- Tinker Exception:FileLockHelper lock file failed: {}
- patch ${type} extract failed (${message}).
- patch %s extract failed (%s).
AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14).
Data as JSON: /api/errors/4f0e72c47cfc0be1.
Report an issue: GitHub.