IllegalStateException : Couldn't read row 0, col 0 from CursorWindow

[yigit]

From @AndroidDeveloperLB on February 17, 2015 15:21

I got this weird exception, which I can't even find its cause because the library got obfuscated:

java.lang.IllegalStateException: Couldn't read row 0, col 0 from CursorWindow. Make sure the Cursor is initialized correctly before accessing data from it.
at android.database.CursorWindow.nativeGetLong(CursorWindow.java)
at android.database.CursorWindow.getLong(CursorWindow.java:511)
at android.database.AbstractWindowedCursor.getLong(AbstractWindowedCursor.java:75)
at android.database.AbstractCursor.moveToPosition(AbstractCursor.java:220)
at android.database.AbstractCursor.moveToNext(AbstractCursor.java:245)
at com.path.android.jobqueue.h.a.d.b(SqliteJobQueue.java:201)
at com.path.android.jobqueue.a.a.b(CachedJobQueue.java:68)
at com.path.android.jobqueue.f.d(JobManager.java:273)
at com.path.android.jobqueue.f.c(JobManager.java:25)
at com.path.android.jobqueue.h.a(JobManager.java:412)
at com.path.android.jobqueue.d.a$b.run(JobConsumerExecutor.java:198)
at java.lang.Thread.run(Thread.java:841)

Any way to find why it occurs, and how to fix it?

Copied from original issue: path/android-priority-jobqueue#95

[yigit]

From @LOG-TAG on March 3, 2015 7:44

may be this is the issue https://github.com/path/android-priority-jobqueue/issues/55

[yigit]

From @AndroidDeveloperLB on March 3, 2015 8:6

I don't see this exception there. Are you sure it can be it?

[yigit]

Hmm, weird. Is this something you can reproduce?

Also, there is no reason to obfuscate the library since it is open source anyways. You can also resolve it using the obfuscation output of proguard.

[AndroidDeveloperLB]

I will check it out in the coming month, I hope. Please don't close it.
Also, what happened to the original repository? Why was it copied here? You are the creator of both of them, no?

[yigit]

yes I'm the original author of this library but I no more work for Path and there were some problems me committing there. So I forked it and continuing development here.

see for details:
https://github.com/path/android-priority-jobqueue/issues/96

[AndroidDeveloperLB]

ok, thank you. You can also check my repos if you wish. :)

[lxalln]

I am getting this issue as well

java.lang.IllegalStateException: Couldn't read row 0, col 0 from CursorWindow. Make sure the Cursor is initialized correctly before accessing data from it.
at android.database.CursorWindow.nativeGetLong(Native Method)
at android.database.CursorWindow.getLong(CursorWindow.java)
at android.database.AbstractWindowedCursor.getLong(AbstractWindowedCursor.java)
at android.database.AbstractCursor.moveToPosition(AbstractCursor.java)
at android.database.AbstractCursor.moveToNext(AbstractCursor.java)
at com.path.android.jobqueue.persistentQueue.sqlite.SqliteJobQueue.nextJobAndIncRunCount(SqliteJobQueue.java:201)
at com.path.android.jobqueue.cachedQueue.CachedJobQueue.nextJobAndIncRunCount(CachedJobQueue.java:68)
at com.path.android.jobqueue.JobManager.getNextJob(JobManager.java:273)
at com.path.android.jobqueue.JobManager.access$400(JobManager.java:25)
at com.path.android.jobqueue.JobManager$2.getNextJob(JobManager.java:423)
at com.path.android.jobqueue.executor.JobConsumerExecutor$JobConsumer.run(JobConsumerExecutor.java:198)
at java.lang.Thread.run(Thread.java:818)

Without forking the project and attempting a fix (not sure where to begin), is there any way to work around this? I'm not sure if there is even somewhere I can catch the exception to stop it crashing my application.

I'm unsure why the cursor wouldn't be initialized correctly, but maybe it's worth handling this scenario a little easier?

It seems to be happening in this method any ideas?

[yigit]

@lxalln is it something you can reproduce?
The problem is happening when we try to move the cursor to the first item, after receiving it.

Google'ing the exception shows this:
http://stackoverflow.com/questions/21432556/android-java-lang-illegalstateexception-couldnt-read-row-0-col-0-from-cursorw

By any chance, do you have a huge job causing this? e.g. are you trying to serialize a bitmap inside a job?

[AndroidDeveloperLB]

I don't think I got this exception ever since I've used this repo.

[yigit]

@AndroidDeveloperLB , I didn't really fix anything related to this (unless it is fixed by chance, which i don't think so). The SO link makes a lot of sense though :). Maybe your jobs got smaller ?

[AndroidDeveloperLB]

I have no idea. I work more on the frontend, and less on the backend of the
app, but I do handle bugs there from time to time.

On Mon, Jun 8, 2015 at 2:00 AM, Yigit Boyar notifications@github.com
wrote:

@AndroidDeveloperLB https://github.com/AndroidDeveloperLB , I didn't
really fix anything related to this (unless it is fixed by chance, which i
don't think so). The SO link makes a lot of sense though :). Maybe your
jobs got smaller ?

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[lxalln]

@yigit unfortunately I haven't been able to reproduce it, I'm just getting crash reports from our Android app. I doubt it'd be job size, we don't have much more than a few strings, certainly nothing as large as a bitmap. I'll double check just to be sure.

[TheLester]

@lxalln Have you solved your problem? I have the same issue, my job contains byte array ,it may be large, but i store this byte array as blob in my own sqlite db , and it querying normal...

[yigit]

@lxalln Keep in mind that there is additional payload when the whole job is serialized so you may as well be close to the limit and this extra data maybe pushing you above the threshold. This is a platform limitation, nothing much JobManager can do unless we create a new API for extra payloads managed in filesystem. Which, actually sounds like a good idea :).

[lxalln]

@TheLester @yigit We solved the problem, but only by disabling persistence on all jobs, which isn't too bad for our app, not ideal, but not the end of the world. I double checked the jobs, there was certainly no large jobs.