Closed ddelapaz closed 4 years ago
Tracking this in https://issues.couchbase.com/browse/CBL-346
Are you able to drive this in a debugger?
I believe that the error takes place in the method C4Document.update near line 160. I suspect that _handle
is 0 because the Document has been freed. If you can get confirmation, that would be fantastic.
Are you able to drive this in a debugger? I believe that the error takes place in the method C4Document.update near line 160. I suspect that
_handle
is 0 because the Document has been freed. If you can get confirmation, that would be fantastic.
Perfect, let me check into it and will let you know in a few. Thanks!
@ddelapaz : Also, if you have code that you can give me, that will repro the problem It would be a big help.
@ddelapaz : I have code that attempts to repro this bug. It fails to do so in 1000 iterations running the code you show above. Happy to share it with you, if it will help you to drive the bug. I need to be able to reproduce this to do anything about it.
Sorry for the delay, It would be great if you share that code you have, I can pair it with real data i have on my end to try and help you reproduce this. I'm also going to see if i can give you the most recent DB file i have that causes the problem.
Thank you
Code is here: https://github.com/bmeike/CBL346
I'm working on a db file you can use on your end , as well as some code from my end to try to isolate the problem better. I went over the code you have there; shouldn't
Blob outOfStockJsonBlob = new Blob("application/json", new byte[0]);
be
Blob outOfStockJsonBlob = new Blob("application/json", outOfStockJson.getBytes(Data.UTF8_CHARSET));
.
In the live example I have, this is where it crashes, on the OutOfStock
section after x amount of tries, OutOfStock
is always an empty array.
In regards to what you previously asked:
I believe that the error takes place in the method C4Document.update near line 160. I suspect that _handle is 0 because the Document has been freed. If you can get confirmation, that would be fantastic.
I stepped thru debugger and this is the data i gathered right before it crashed.
I couldn't step in any further:
static native long create2(long db, String docID, long body, int flags) throws LiteCoreException;
A couple of things.
1) the issue that you cite immediately above is different than the one that you originally posted. The original issue is a failure in update2
:
at com.couchbase.litecore.C4Document.update2(Native Method) ~[na:0.0]
2) You said:
t happens when attempting to save the outofstock [...] outofstock is an empty array [].
We haven't seen this happen elsewhere. If you can reproduce it in either the framework that I sent over, or some other code that you can share, we'll be able to fix it for you.
I was able to reproduce: https://github.com/ddelapaz/CBL346_BugTest
What I found weird is that the error doesn't take place in android emulators OS v6, 7 or 8.. Works fine there. Also works fine on physical android devices v7, 8 but not on 6...
On a physical device with OS v 6.0.1 I get the error above 999 iterations.
Using the code I posted, this is after 999 iterations:
09-17 15:23:22.158 11130-11318/cb.dbbugreproduce D/DBHelper: DBHelper: OK, Saving 'outofstock' 09-17 15:23:22.204 11130-11318/cb.dbbugreproduce E/CouchbaseLite/DATABASE: Assertion failed: docID && revID && sequence > _lastSequence (/home/couchbase/jenkins/workspace/couchbase-lite-android-edition-build/couchbase-lite-android-ee/libs/couchbase-lite-android/libs/couchbase-lite-core/LiteCore/Database/SequenceTracker.cc:113, in documentChanged)/data/app/cb.dbbugreproduce-2/lib/arm64/libLiteCoreJNI.so litecore::SequenceTracker::documentChanged(fleece::alloc_slice const&, fleece::alloc_slice const&, unsigned long, unsigned long)/data/app/cb.dbbugreproduce-2/lib/arm64/libLiteCoreJNI.so c4Internal::Database::documentSaved(c4Internal::Document*)/data/app/cb.dbbugreproduce-2/lib/arm64/libLiteCoreJNI.so c4Internal::TreeDocument::save(unsigned int)/data/app/cb.dbbugreproduce-2/lib/arm64/libLiteCoreJNI.so c4Internal::TreeDocument::saveNewRev(C4DocPutRequest const&, litecore::Rev const*, bool)/data/app/cb.dbbugreproduce-2/lib/arm64/libLiteCoreJNI.so c4Internal::TreeDocument::putNewRevision(C4DocPutRequest const&)/data/app/cb.dbbugreproduce-2/lib/arm64/libLiteCoreJNI.so c4doc_put/data/app/cb.dbbugreproduce-2/lib/arm64/libLiteCoreJNI.so c4doc_update/data/app/cb.dbbugreproduce-2/lib/arm64/libLiteCoreJNI.so Java_com_couchbase_litecore_C4Document_update2/data/app/cb.dbbugreproduce-2/oat/arm64/base.odex oatexec/data/app/cb.dbbugreproduce-2/oat/arm64/base.odex oatexec/data/app/cb.dbbugreproduce-2/oat/arm64/base.odex oatexec/data/app/cb.dbbugreproduce-2/oat/arm64/base.odex oatexec/data/app/cb.dbbugreproduce-2/oat/arm64/base.odex oatexec/data/app/cb.dbbugreproduce-2/oat/arm64/base.odex oatexec/data/app/cb.dbbugreproduce-2/oat/arm64/base.odex oatexec/data/app/cb.dbbugreproduce-2/oat/arm64/base.odex oatexec??? /system/lib64/libart.so art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)/system/lib64/libart.so artInterpreterToCompiledCodeBridge/system/lib64/libart.so bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)??? /system/lib64/libart.so art::JValue
art::interprete
Tomorrow I'm going to test it in a different hardware running 6.0.1 to see if its hardware related.
Hope this helps you.
Nice work, @ddelapaz ! Will attempt to chase this down later this week. Many thanks for the help!
Nice work, @ddelapaz ! Will attempt to chase this down later this week. Many thanks for the help!
Not a problem, thank you for being on top of it! I will update once if i get more details tomorrow. Have a good one.
Quick update, the physical device that previously had this error running OSv6.0.1 now works properly after flashing OSv7.1.2. I'm trying to find a device that is not the Zebra TC75X to see if that makes a difference.
So currently the bug is only reproducible on a v6.0.1 Physical Device.
Thanks for the info. That's weird!
I was able to further confirm this issue on another Zebra TC75X physical device running OS 6.0.1.
I can't get my hands on a normal 6.0.1 device that is not Zebra, would you guys be able to test this on your end?
I'm afraid that the only devices I have are a 5.1.1 and a 9. Emulator?
I'm starting to think this is Zebra firmware specific issue and not related to the general Android releases. It doesn't happen on your 5.1.1?
@ddelapaz : No... I have not been able to reproduce it anywhere...
@ddelapaz : Do you have suggestions for what to do with this? I have yet to reproduce it anywhere and it seems hardware specific. If it is evidence of a bug others just haven't driven yet, I'd like to find it and fix it. At this point, though, there's just nothing to go on...
I've been trying to get my hands on a device running OSv6.0.1 which is not Zebra specific but no luck. I want to find one of those devices to ensure that this is not just Zebra platform related.
I'm going to close this. It's not that I don't believe that there is a bug, it is that I can't do much about it without more information.
If you come up with anything else, by all means, re-open this ticket or refer to it in a new one.
I'm just going through the release notes of Couchbase Lite 2.7 and saw this report. I have a Nexus 5 running Android 6.0.1 - which @ddelapaz was looking for. I grabbed https://github.com/ddelapaz/CBL346_BugTest, ran the loop 10,000 times and there were no issues/crashes/exception logs.
Thank you @benjaminglatzeder !
I'm using
com.couchbase.lite:couchbase-lite-android:2.5.3
on Android OS v 6.0.1My current implementation is a bit different because I have so many changes I would need to make in order to utilize the query system in Couchbase Lite, so for now I'm simply serializing and deserializing data and saving to database.
The exception appears to take place while saving constantly after each label scan. My device is used by drivers to scan cases with barcodes, after every scan I do the following:
I notice the exception posted above happens after 70+ items scanned, I scan quickly one after the other. I ran android profiler and memory is properly clearing and cpu usage is low even when scanning constantly.
Note that I'm able to still read the database after the above errors take place, it just appears to be missing one of the models that i'm saving. I'm still debugging to see if i can gather more information.
Not sure if this is a bug on your end? Thanks!
UPDATE
I did a bit more testing on my end. It happens when attempting to save the
outofstock
json blob after x amount of saves. This particular lineData.database.save(outofstock);
.outofstock
is an empty array[]
.Here is where exception took place: