Timestamp: 2022-10-25 12:05:51+0100
pid: 411, tid: 600, name: fvp_respond  >>> /vendor/bin/hw/server <<<
uid: 0
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x3d3a4eb0
vm_pid:2526
    r0  ec37ac90, PFN: 669044  r1  00000000, PFN:--------  r2  3d3a4eb0, PFN:--------  r3  eacfb7e8, PFN: 818440
    r4  2a205444, PFN:--------  r5  ec37ac90, PFN: 669044  r6  f3200b90, PFN: 814695  r7  f3880c70, PFN: 1050054
    r8  0000001a, PFN:--------  r9  eacfbcb0, PFN: 818440  r10 eacfb7ec, PFN: 818440  r11 00000001, PFN:--------
    ip  eacfb788, PFN: 818440  sp  eacfb658, PFN: 818440  lr  efd0103d, PFN:--------  pc  efd1fa9c, PFN:--------

backtrace:
      #00 pc 00073a9c  /apex/com.android.vndk.v30/lib/libsqlite.so (sqlite3IdListAppend+188) (BuildId: bdf2643e43be9ddeb6d9cf7068cd3684)
      #01 pc 00055039  /apex/com.android.vndk.v30/lib/libsqlite.so (yy_reduce+5200) (BuildId: bdf2643e43be9ddeb6d9cf7068cd3684)
      #02 pc 00020f4f  /apex/com.android.vndk.v30/lib/libsqlite.so (sqlite3RunParser+694) (BuildId: bdf2643e43be9ddeb6d9cf7068cd3684)
      #03 pc 0001fab7  /apex/com.android.vndk.v30/lib/libsqlite.so (sqlite3LockAndPrepare+770) (BuildId: bdf2643e43be9ddeb6d9cf7068cd3684)
      #04 pc 0001f459  /apex/com.android.vndk.v30/lib/libsqlite.so (sqlite3_prepare_v2+16) (BuildId: bdf2643e43be9ddeb6d9cf7068cd3684)
      #05 pc 003b7104  /vendor/bin/hw/server (db_add_service_info+268) (BuildId: 7dc5f6f995fce3027422845ab52e1196)
      #06 pc 003ce668  /vendor/bin/hw/tserver (SaveLinkedListToDB+812) (BuildId: 7dc5f6f995fce3027422845ab52e1196)
      #07 pc 003cf070  /vendor/bin/hw/server (ParserXMLStart+1140) (BuildId: 7dc5f6f995fce3027422845ab52e1196)
      #08 pc 003c9f00  /vendor/bin/hw/server (RespondTask+308) (BuildId: 7dc5f6f995fce3027422845ab52e1196)
      #09 pc 000808b3  /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+40) (BuildId: 7bc8508bdbcc8163b9a5fbf3443efa72)
      #10 pc 00039d23  /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30) (BuildId: 7bc8508bdbcc8163b9a5fbf3443efa72)


I don't know why, this phenomenon is probabilistic on android 11.

Stack review:
arm-linux-androideabi-addr2line -fe libsqlite.so 00055039
yy_reduce
external/sqlite/dist/sqlite3.c:152045

arm-linux-androideabi-addr2line -fe libsqlite.so 00073a9c
_ZL6memsetPvU17pass_object_size0ij
out/soong/.intermediates/bionic/libc/libc.llndk/android_vendor.30_arm_armv8-2a_cortex-a55_shared/gen/include/bits/fortify/string.h:138

arm-linux-c++filt _ZL6memsetPvU17pass_object_size0ij
memset(void*, int pass_object_size0, unsigned int)

Sqlite3.c source code stack:
SQLITE_PRIVATE void *sqlite3DbMallocZero(sqlite3 *db, u64 n){
  void *p;
  testcase( db==0 );
  p = sqlite3DbMallocRaw(db, n);
  if( p ) memset(p, 0, (size_t)n); ---------Maybe this line
  return p;
}

The most probable cause of such errors is your own code clobbering memory used by SQLite. They can be detected by using valgrind or an equivalent tool.

You provide no information on how to reproduce the "phenomenon".

SQLite version? Did you build it yourself?
Database schema?
Text of the statement?
Is it reproducible using the SQLite shell?

Is there a particular reason that you are "converting" the SQL string to a string and then passing that conversion to prepare()? The impression your code snippet gives is that sql_str is unnecessary.

QA:
At the beginning, there was no CreateSQLString, and const char sql[] was used directly, but there are still problems, I don't think this is the root case.
Thanks

Note that the shell does support parameters if they have names instead of numbers. See section 16 of https://sqlite.org/cli.html

Also, the SEGV occurs in the prepare phase, which would be prior to binding parameters.

Consider running your code on a linux distribution that supports valgrind to check for improper memory access.

Edit: How often do you call sqlite3_prepare_v2()? If more than once, do you properly finalize the statement?

Edit: How often do you call sqlite3_prepare_v2()? If more than once, do you properly finalize the statement?

QA:
We call sqlite3_prepare_v2 very frequently,we inalize the statement.
But there are two situations that need to be confirmed:
1.  rc = sqlite3_prepare_v2(DB, sql, -1, &stmt, NULL);
    if (rc != SQLITE_OK)
    {
       DBG("%s", sqlite3_errmsg(db));
       return FAILURE;
    }
Whether sqlite3_prepare_v2 returns SQLITE_OK or not, do you need to call sqlite3_finalize?

2.An API calls sqlite3_prepare_v2 multiple times, does it need to call sqlite3_finalize the same number of times?
ex:
    rc = sqlite3_prepare_v2(db, sql, -1, &stmt, NULL);
    if (rc != SQLITE_OK)
    {
        FVP_DB_DBG("%s", sqlite3_errmsg(gDBHandle));
    }

    //2.step
    rc = sqlite3_step(stmt);
    .....
    //3.prepare
    rc = sqlite3_prepare_v2(DB, sql, -1, &stmt, NULL);
    
    //4.step
    rc = sqlite3_step(stmt);
    .....
    //5.finalize one time is ok?
    sqlite3_finalize(stmt);

You are leaking memory. You must (eventually) finalize each and every statement that you have sucessfully prepared. This is quite clear from the documentation https://sqlite.org/c3ref/prepare.html

"If there is an error, *ppStmt is set to NULL"

"The calling procedure is responsible for deleting the compiled SQL statement using sqlite3_finalize() after it has finished with it."