SIGBUS(BUS_ADRERR)

[glenhsi]

SIGBUS(BUS_ADRERR)

"#00 pc 000000000016d4b4 /data/app/~~afVcFjLWvTopTa72WSmNuQ==/com.hpbr.directhires-KcVU6q_tyOzXZ9cshVYV3w==/lib/arm64/libobjectbox-jni.so [arm64-v8a::569a5af434485b23546e7efcfe241e7d]
#01 pc 0000000000085cf8 /data/app/~~afVcFjLWvTopTa72WSmNuQ==/com.hpbr.directhires-KcVU6q_tyOzXZ9cshVYV3w==/lib/arm64/libobjectbox-jni.so (Java_io_objectbox_query_Query_nativeFind+516) [arm64-v8a::569a5af434485b23546e7efcfe241e7d]
#02 pc 0000000000246fbc /data/app/~~afVcFjLWvTopTa72WSmNuQ==/com.hpbr.directhires-KcVU6q_tyOzXZ9cshVYV3w==/oat/arm64/base.odex [arm64-v8a::a4e5fc145a364cc960984ea5588133bc]
java:
io.objectbox.query.Query.c(SourceFile:241)
io.objectbox.query.Query.lambda$Wb8j3GHtHw5Skg-9s5vdRAY7vJQ(Unknown Source:0)
io.objectbox.query.-$$Lambda$Query$Wb8j3GHtHw5Skg-9s5vdRAY7vJQ.call(Unknown Source:6)
io.objectbox.BoxStore.a(SourceFile:937)
io.objectbox.BoxStore.a(SourceFile:883)
io.objectbox.query.Query.a(SourceFile:305)

objectbox version:3.2.0
device:HONOR||ALA-AN70
version:12

when invoke "query.find(0, 1)", the exception is occured.

[greenrobot-team]

Thanks for reporting!

Can you reproduce this with the latest version (3.5.1 as of 2023-01-31) as well?

Can you share an example project or enough details that would allow us to reproduce this?

[glenhsi]

Thanks for reporting!

Can you reproduce this with the latest version (3.5.1 as of 2023-01-31) as well?

Can you share an example project or enough details that would allow us to reproduce this?

I have upgrade to 3.5.1, and I can not reproduce this because this is user data, when the issue hanpens, the db always can not open until reinstall app.

[greenrobot-team]

We can try to reproduce if you can get us the database file. You e.g. can ask users to send it.

Other than that, looking at typical causes of SIGBUS BUS_ADRERR online:

• two processes interfere, e.g. are you using multiple processes in the app?
• the device is low on storage.

[greenrobot-team]

@glenhsi Forgot this: are you sure the stack trace you have given is from version 3.2.0? When I symbolize I get functions that don't make sense (for us: objectbox::AsyncBox::remove). Do you maybe have other stack traces (starting at the line with *** *** ***)?

[glenhsi]

@glenhsi Forgot this: are you sure the stack trace you have given is from version 3.2.0? When I symbolize I get functions that don't make sense (for us: objectbox::AsyncBox::remove). Do you maybe have other stack traces (starting at the line with *** *** ***)?

yeah, the stack trace is from 3.2.0. when the issue happens, I upgrade my version to 3.5.1 and the issue also happened.
this is the latest trace:

#00 pc 0000000000177ecc /data/app/~~2jCV9fh3DPWjhRR1lqTIIQ==/package-O9rnmPS7yJ72FqNjyRRCGA==/lib/arm64/libobjectbox-jni.so [arm64-v8a::d4fa89ac0163e42c4ce53eb8481047da]
#1 pc 0000000000183ab8 /data/app/~~2jCV9fh3DPWjhRR1lqTIIQ==/package-O9rnmPS7yJ72FqNjyRRCGA==/lib/arm64/libobjectbox-jni.so [arm64-v8a::d4fa89ac0163e42c4ce53eb8481047da]
#2 pc 0000000000088e48 /data/app/~~2jCV9fh3DPWjhRR1lqTIIQ==/package-O9rnmPS7yJ72FqNjyRRCGA==/lib/arm64/libobjectbox-jni.so (Java_io_objectbox_query_Query_nativeFind+552) [arm64-v8a::d4fa89ac0163e42c4ce53eb8481047da]
#3 pc 00000000000ec10c /data/app/~~2jCV9fh3DPWjhRR1lqTIIQ==/package-O9rnmPS7yJ72FqNjyRRCGA==/oat/arm64/base.odex [arm64-v8a::c4de2d51c01df5454b78d26952b82c35]
java:
io.objectbox.query.Query.c(SourceFile:278)
io.objectbox.query.Query.lambda$Wb8j3GHtHw5Skg-9s5vdRAY7vJQ(Unknown Source:0)
io.objectbox.query.-$$Lambda$Query$Wb8j3GHtHw5Skg-9s5vdRAY7vJQ.call(Unknown Source:6)
io.objectbox.BoxStore.a(SourceFile:940)
io.objectbox.BoxStore.a(SourceFile:886)
io.objectbox.query.Query.a(SourceFile:368)
io.objectbox.query.Query.a(SourceFile:277)
.e.a.getLastMessageIdExcludeTimeStamp(SourceFile:437)
b.b.b.d(SourceFile:87)
b.b.b.c(SourceFile:58)
b.a.-$$Lambda$L_rCf2I7YL5eIhsgR-70eV8g18w.run(Unknown Source:0)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
java.lang.Thread.run(Thread.java:923)

[greenrobot-team]

Thanks! Again, when I try to symbolize this trace with the 3.5.1 symbols it starts at [Transaction](objectbox::Transaction::commit) in Transaction.cpp which doesn't make any sense (should start at QueryJniBinding.cpp).

Does your build process apply any sort of obfuscation to binary/native libraries that might produce obfuscated tombstones?

[glenhsi]

Thanks! Again, when I try to symbolize this trace with the 3.5.1 symbols it starts at [Transaction](objectbox::Transaction::commit) in Transaction.cpp which doesn't make any sense (should start at QueryJniBinding.cpp).

Does your build process apply any sort of obfuscation to binary/native libraries that might produce obfuscated tombstones?

no, I have no any sort of obfuscation to binary/native libraries,I just query some data from db

[greenrobot-team]

I mentioned some other potential causes in my previous comment. I guess these do not apply?

[glenhsi]

I mentioned some other potential causes in my previous comment. I guess these do not apply?

my app is using single process and the rest of storage is enough. do you have other ideas? or other infos you need

[greenrobot-team]

Sorry, not at this time. As implied, if you can get a proper tombstone/stack trace (similar to here, e.g. Play Store or Firebase Crashlytics are known to produce valid ones) or a database file that can be used to reproduce this we can try to find the cause.

[glenhsi]

Sorry, not at this time. As implied, if you can get a proper tombstone/stack trace (similar to here, e.g. Play Store or Firebase Crashlytics are known to produce valid ones) or a database file that can be used to reproduce this we can try to find the cause.

ok. got this

[github-actions]

Without additional information, we are unfortunately not sure how to resolve this issue. Therefore this issue has been automatically closed. Feel free to comment with additional details and we can re-open this issue.