That would not be all that helpful.
At the very least:
FileLogger log = Database.log.getFile()
log.setLevel(LogLevel.DEBUG); // SET THE LOG LEVEL TO DEBUG!!!
log.setDomain(LogDomain.ALL_DOMAINS); // LOG ALL DOMAINS.
The problem with this is that it logs only CBL stuff. It would be very useful to see what else is going on. Your problem is, as I have said, quite bizarre in that I do not see any way that 2.8 code can cause it. It would be much better if you would do something like this:
ConsoleLogger log = Database.log.getConsole()
log.setLevel(LogLevel.DEBUG); // SET THE LOG LEVEL TO DEBUG!!!
log.setDomain(LogDomain.ALL_DOMAINS); // LOG ALL DOMAINS.
… and then verify that the CBL logs are appearing in the Catalina console log.
I would like that log, for a period of time 1min either side of the failure.
@blake.meike, how can I send you zipped log files? I can’t upload these log files into gist
another question I should have mentioned that we have one cblite database with multiple processes to access it, but only one process to do CRUD, and other processes do read only, does this cause the issue?
uhhh… yes. Thanks for mentioning that. That might, very well, be significant. I am not sure that we support that. Let me check.
I have created https://issues.couchbase.com/browse/CBL-1517 to track this. You should be able to put your log files there.
Ok, I have confirmation. The basic database transactions should work ok. Things like LiveQuery and DatabaseChange notifications will not work. None of that, though, should be relevant to this particular issue…
@blake.meike I can’t find upload tool on this page, do I need to login to upload file on https://issues.couchbase.com/browse/CBL-1517 ? But I don’t have couchbase account.
Damm even I am having a similar kind of issue, I have searched all over the internet and even have posted on number of threads on different forum, no solution seems to work. I am really frustrated, can anyone of you here help me resolve this issue, I am very much tired now.
@blake.meike attached please find logs
logs.zip (248.6 KB)
@shubharora734: You’ve come to the right place.
I’m not going to be able to make much progress on your issue with only the information you’ve provided, though. I suggest you start a new thread describing your issue, telling which platform and version you are using, including some logs and referencing this issue so that I know that you think it is related.
@Brad_Johnson got it. Thanks. I didn’t realize that our JIRA only allowed uploads from certain users. Sorry about that.
@Brad_Johnson: There are two sets of logs there… what are they?
I’ve looked at them and both seem to me to be logs of relatively normal queries. There is no indication of anything going wrong.
Any chance of getting my hands on the console log?
@blake.meike we use standalone JVM for java application, it’s not web or mobile based application, so we can’t provide you with console logs
Ok. I have to say that I’m completely stuck, here. The code looks to me as if it cannot create the problem you are seen (at least, since 2.8.1), and the logs that I have look like completely normal queries.
Can you help me to reproduce it? A minimal case or something? I’ve really got next to nothing to go on, so far.
@blake.meike just FYI, we run CE2.7.1 before CE 2.8.1.1, we haven’t run into this crash except the memory issue at the top of this message train. At beginning, CE 2.8.1 didn’t package correctly, and then repackage it as 2.8.1.1, would you make sure all linux sys libs were packaged into CE2.8.1.1 correctly and tested on your side completely?
Can we use EE.28.1 to do this test? But I am not sure of EE licensing
You can easily check, yourself, to verify that the system libraries are present. The jar file should contain:
libs/
libs/linux/
libs/linux/x86_64/
libs/linux/x86_64/libLiteCoreJNI.so.MD5
libs/linux/x86_64/libLiteCore.so
libs/linux/x86_64/libLiteCore.so.MD5
libs/linux/x86_64/libLiteCoreJNI.so
libs/macos/
libs/macos/x86_64/
libs/macos/x86_64/libLiteCore.dylib.MD5
libs/macos/x86_64/libLiteCoreJNI.dylib
libs/macos/x86_64/libLiteCoreJNI.dylib.MD5
libs/macos/x86_64/libLiteCore.dylib
libs/windows/
libs/windows/x86_64/
libs/windows/x86_64/LiteCore.dll.MD5
libs/windows/x86_64/LiteCoreJNI.dll.MD5
libs/windows/x86_64/LiteCore.dll
libs/windows/x86_64/LiteCoreJNI.dll
… and if you are running on Centos, you may need the following files, packaged in the .zip distribution. Put them on the LD_LIBRARY_PATH, as described here: https://docs.couchbase.com/couchbase-lite/current/java/start/java-gs-install.html#additional-steps-for-linux
support
support/linux
support/linux/x86_64
support/linux/x86_64/libc++
support/linux/x86_64/libc++/libstdc++.so.6
support/linux/x86_64/libc++/libstdc++.so
support/linux/x86_64/libc++/libgcc_s.so
support/linux/x86_64/libz
support/linux/x86_64/libz/libz.so.1
support/linux/x86_64/libz/libz.so
support/linux/x86_64/libz/libz.so.1.2.11
support/linux/x86_64/libicu
support/linux/x86_64/libicu/libicuio.so.54
support/linux/x86_64/libicu/libicudata.so.54
support/linux/x86_64/libicu/libicuuc.so
support/linux/x86_64/libicu/libicui18n.so.54.1
support/linux/x86_64/libicu/libicuio.so
support/linux/x86_64/libicu/libicutu.so
support/linux/x86_64/libicu/libicuuc.so.54
support/linux/x86_64/libicu/libicutu.so.54.1
support/linux/x86_64/libicu/libicui18n.so.54
support/linux/x86_64/libicu/libicutu.so.54
support/linux/x86_64/libicu/libicudata.so
support/linux/x86_64/libicu/libicuio.so.54.1
support/linux/x86_64/libicu/libicuuc.so.54.1
support/linux/x86_64/libicu/libicudata.so.54.1
support/linux/x86_64/libicu/libicui18n.so
@blake.meike, yes, all of these libs are in our support folder for linux,. please let us know what you need from us,. I am not sure if you can duplicate it on linux with the workaround of multiple processes to access the same cblite database.
Yeah. This is a toughy. If I can’t see it, I really don’t have anything to go on.
Can you tell me more about when and how often it happens. I suspect that multi-process access to the db doesn’t have anything to do with it. As I said, looking at the core dump, it appears that there is a null (0) pointer being handed to the C code, in the JNI call.
If this is happening a lot, a few more dumps would be helpful. Anything that will give us a clue to what is going on…
@blake.meike its been happening very often and we have been very frustrated since upgrading from CE 2.7.1 to CE2.8.1.1. I will send you more dump files.
Got it. I can imagine the frustration…
The more information you can give me on how and when it happens, the better chance I have of cornering it.
This is not something that has come up elsewhere: you are the only source of information I have about this issue.