检查失败:写入本地存储时接收方 != nullptr 虚拟 (SIGABRT)

Check failed: receiver != nullptr virtual (SIGABRT) when writing to local storage

我有一个方法

   fun generateIdentity(deviceId:String, environment: String) {

     val identity= Identity()

     identity.deviceId = deviceId
     identity.environment = environment

    AppLog.i(TAG, "generateIdentity()")

    if (!configDirectory.exists()) {
        configDirectory.mkdirs()
    }

    val identityFile = File("$configDirectory/identity.json")

    if (identityFile.exists()) {
        identityFile.delete()
    }

    identityFile.createNewFile()

    val jsonIdentity = GsonBuilder().setPrettyPrinting().create().toJson(identity)

    try {
        val buf = BufferedWriter(FileWriter(identityFile, true))
        buf.append(jsonIdentity)
        buf.newLine()
        buf.close()
    } catch (e: IOException) {
        AppLog.e(TAG, e.printStackTrace().toString())
    }
}

写入序列化对象

 class Identity{

@Expose
@SerializedName("device-id")
var deviceId: String = ""

@Expose
@SerializedName("environment")
var environment: String =""
}

作为 JSON 文件保存到本地存储。

在Gson构建过程中对identity对象调用.toJson()时,native层发生crash,提供了以

开头的很长的日志列表
03-09 14:20:08.416 7468-7468/ A/art: art/runtime/entrypoints/quick/quick_trampoline_entrypoints.cc:801] Check failed: receiver != nullptr virtual 

并以

结尾
03-09 14:20:08.799 7468-7468/? A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 7468 ()

没有生成墓碑。这是过去有效的一段看似微不足道的代码,不确定是什么变化导致这种情况开始发生。我该如何调查造成这种情况的原因?

我把整个序列化和写文件的过程放到一个协程里是这样的:

val jsonCoversionResult: Deferred<String> = GlobalScope.async {
         GsonBuilder()
             .setPrettyPrinting()
             .create()
             .toJson(
                 identity)
     }

     runBlocking {
         val jsonIdentity = jsonCoversionResult.await()

         try {
             val buf = BufferedWriter(FileWriter(identityFile, true))
             buf.append(jsonIdentity)
             buf.newLine()
             buf.close()
         } catch (e: IOException) {
             AppLog.e(TAG, e.printStackTrace().toString())
         }
     }

我正在为具有专有硬件的 AOSP 版本编写代码,内存管理有时会因为我不明白的原因而变得古怪,但这确实有效。