1

Someone testing an Android app submitted a stack trace to us that looks like this:

Thread [<21> Thread-31] (Suspended (exception SQLiteException)) 
FooClass.bar(Foo2Class) line: 198

The line of code it points to is not related to SQLite (it's not an Android class, it's my code). If you want to know, the line of code it points to looks like this: 

if (s_arrayList.contains(foo2))

so the only exception I could imagine happening here is a NullPointer... definitely not a SQLite exception.

My main question is: What does the "Suspended (exception X)" really mean? If the exception happened on a different thread, why is Android reporting this stack trace?

Update:

I think this issue has to do with Eclipse, which suspended the thread when it detected an exception. This still leaves the question unanswered for me, which is why Eclipse suspded the thread at precisely this place. I found a related question, which discusses this quirk of Eclipse. You can read more about it here:

Eclipse Android Debugger - Where in my code did I cause the exception?

Community
  • 1
  • 1
Otto
  • 1,675
  • 2
  • 19
  • 30
  • maybe the type of s_arrayList does not match the type of foo2? – bbedward Mar 07 '12 at 21:17
  • Can the user have different version of the app? – Sergey Glotov Mar 07 '12 at 21:56
  • the type is right, and I'm pretty sure the version of app is the same. The real puzzle is why I'm seeing a SQLiteException, when this line of code has nothing to do with SQL. – Otto Mar 08 '12 at 17:10
  • 2
    can you post the full stacktrace?? – dhaval Mar 12 '12 at 14:59
  • ok, here's the full stack trace: Thread [<21> Thread-31] (Suspended (exception SQLiteException)) AdReport2.add(AdService2) line: 198 AdReport2.requestCompleted(AdService2) line: 314 AdMaxPosition.fetchAd(NexageContext, Activity, boolean) line: 131 NexageAdFetcher$FetchThread.run() line: 456 – Otto Mar 15 '12 at 20:02
  • Is it safe to assume, s_arrayList is a ArrayList and foo2 is a string? – Zaid Daghestani Mar 16 '12 at 19:13

2 Answers2

1

I could imagine much more cases. In order to track it down more code would be helpful. However, very little time is left

Check whether the stack trace really fit to your code version.

Check of which type s_arraylist really is. It might be some special code doing late binding on sqllite. However, I don't think this is very likely but it is better to verify

Check of which type foo2 really is. May be its hashcode or equals method is using directly or indirectly SqlLite. This is my favorite.

stefan bachert
  • 9,413
  • 4
  • 33
  • 40
  • Stefan, thanks for these ideas. I'm pretty sure that the stack trace fits my code, and that I don't think that either the arraylist or foo2 types are using SQLite. I think rather that this issue is due to Eclipse suspending a thread right before the exception gets thrown, but I'm still not clear on how/why Eclipse is doing this. – Otto Mar 19 '12 at 21:08
1

When your thread throwing an suspension - exception (just like in your stack trace), it does not mean that you had a null pointer it means that some one from other thread called to Thread.suspend().

Ilya Gazman
  • 31,250
  • 24
  • 137
  • 216
  • This seems plausible. I think the issue is an artifact of how Eclipse handles exceptions when you're in debug mode, apparently it suspends the thread and displays this stack trace which is not necessarily the root cause. I'm still fuzzy on why Eclipse does this and how it decides to suspend the thread at that point. – Otto Mar 19 '12 at 21:08
  • 1
    Some times is better working with log then debug, you can always print **new Exception** and see all it's stack trace – Ilya Gazman Mar 19 '12 at 21:28