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

  1. Log the cause exception to distinguish lock failure vs corrupted info file.
  2. Ensure the patch info directory is fully written (rewritePatchInfoFileWithLock) before reading, and that only one process loads patches.
  3. If the info file is corrupted, clean the app's tinker directory (or reinstall) so patch state is rebuilt.
  4. Free up storage and check file permissions on the info directory.
  5. 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

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


AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14). Data as JSON: /api/errors/4f0e72c47cfc0be1. Report an issue: GitHub.