New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SQLite error when running tests #1986
Comments
We have been encountering this a lot as well, since upgrading to Robolectric 3.0. Seems to happen on both OSX and Ubuntu, but a lot more on Ubuntu, which powers our CI servers. |
Did you find a workaround ? I found myself disabling most of the unit tests build on my CI ... |
Nope, on my lucky day it would be smooth, but sometimes it takes 5-10 retries to make a successful build. |
Also my setup tests against API 18. Pointing it against 19 or 21 seems to resolve the problem, but we got hit with out of memory issues (which is even worse as it just hangs the build), so we decide to just test against 18. |
I am having the SQLite error on API 21 tests Le jeu. 13 août 2015 12:22, Ha Duy Trung notifications@github.com a
|
Are you leaking resources between tests?
|
@jongerrish I suspect that would the case. But the problem only starts to surface since Robolectric 3.0, and unfortunately I couldn't pinpoint the culprit(s). I wish there was a guidelines on cleaning up test resources to avoid/mitigate leaks. For the SQLite problem, I notice this change is where the exception starts to happen. |
This happened to us too. I don't have time to investigate thoroughly, but here is my quick hack of a workaround: @@ -399,7 +399,12 @@ public class ShadowSQLiteConnection {
@Override
public Object call() throws Exception {
SQLiteConnection connection = getConnection(ptr);
- connection.dispose();
+ try {
+ connection.dispose();
+ } catch (java.lang.AssertionError e) { // DB[109] will not dispose from a non-confining thread
+ // Hacky patch for https://github.com/robolectric/robolectric/issues/1986.
+ e.printStackTrace();
+ }
return null;
}
}); (Yup, that's some professional-grade code right there...) I suspect that the issue may be a race condition in the setup / teardown of |
Hi any update/confirmation on this issue? It's getting worse for us now once we upgrade to build tool 1.3.1. Still seems to happening only in Ubuntu. |
Just updated from robolectric 2.4 to 3.0. And it works without any issue on my dev windows machine, but Ubuntu build machine now dies with out of memory exception during execution of tests. |
+1. This has dramatically ramped up our test flakiness since recently introducing SQLite into our app.
I think the static ShadowSQLiteConnection.CONNECTIONS pool is resource that is leaking between tests. I've got some very basic unit tests failing with that stack trace that have nothing to do with SQLite. |
Is there any ideas on this? This error is making testing very difficult for us. It happens on some machines and not on others. |
I'm having the same issue as others since I'm migrating my application over to be built on Ubuntu based servers for CI builds, attempting to build on Centos/Redhat the same doesn't happen. Also building on Mac OS X (yosemite) isn't a problem either just Ubuntu so guessing something low level is the culprit. Anyone find a workaround to this issue or a way to find the cause? |
Same here. The same problem occurs intermittently on CI (Windows machine) but never on dev machines (Mac). No workaround or fix found for it. |
I added the following for all my unit tests and got around the SQLite error for Centos7
Since the connections are the problem this clears / resets the SQLite connections after each and every test. This worked for my use cases and the errors I was seeing. UPDATE: well it worked briefly... or it was just a random build that didn't run into this race condition |
Also, the error that is occurring happens when ShadowSQLiteConnection.reset() is called, so calling it again won't fix it. The error occurs when ShadowSQLiteConnection tries to close all of its connections. |
Any idea what might be happening here and a solution to this issue? |
Hello! Any updates here? This issue is really annoying and as long builds are getting longer to complete the more terrific is getting exception due to the problem in robolectric. |
Running the tests on a higher spec machine hid the problem for me. |
Everyone has the best solution about this problem ? |
Hello! Any updates here ? I got the same problem on robolectric tests with the following exceptions : java.lang.RuntimeException And : |
I can confirm that the workaround I mentioned earlier works: @@ -399,7 +399,12 @@ public class ShadowSQLiteConnection {
@Override
public Object call() throws Exception {
SQLiteConnection connection = getConnection(ptr);
- connection.dispose();
+ try {
+ connection.dispose();
+ } catch (java.lang.AssertionError e) { // DB[109] will not dispose from a non-confining thread
+ // Hacky patch for https://github.com/robolectric/robolectric/issues/1986.
+ e.printStackTrace();
+ }
return null;
}
}); We have a unit test suite of many thousands of tests. We've run it tens of thousands of times since introducing this patch, and I've never noticed any related errors. I'm hesitant to open a PR since this is obviously a hack, and it's unclear to me if there are any undesirable implications. If a Robolectric maintainer wants to incorporate this though, I'm happy to open a PR. |
@ndahlquist how did you manage to incorporate the fix locally? Just built robolectric locally on your own? |
Hello! I was able to resolve the issue with the following steps: `package org.robolectric.shadows; import org.robolectric.annotation.Implements; @implements(ShadowSQLiteConnection.Connections.class) @OverRide `package android.database.sqlite; import com.almworks.sqlite4java.SQLiteConnection; import org.robolectric.annotation.Implements; import java.lang.reflect.Field; @implements(value = SQLiteConnection.class, isInAndroidSdk = false)
}
@config(constants = BuildConfig.class, sdk = 18, shadows = {ShadowApplication.class, MyShadowSqliteConnection.class}) ShadowApplication is optional of course. |
Ah, we built locally, but I like your solution better! Thanks for sharing! |
Hello !
I got the following exception :
I tried with both BuildConfig mentioned previously but it doesn't work .. Thanks :) |
@realumy I used the BuildConfig of my application. I haven't encountered this problem, sorry you have it. |
Hello! If copy-paste this code as is neither MyShadowSqliteConnection or MyShadowSQLiteConnections are never loaded. Maybe I'm not quite understand how shadowing work in robolectric, but my guess is that shadows of classes that used only in shadows (like ShadowSQLiteConnection) never trigger. Further, if try to call MyShadowSqliteConnection constructor explicitly test failed with NoSuchFieldException (because ShadowSQLiteConnection really don't have "" field) I guess it means to reset "CONNECTIONS" field, but it's final so you have to workaround with that. And finally you call connection.dispose() twice and at first attempt is unsafe as it not wrapped into try-catch I'm still find some strange behaviour when CONNECTIONS field are some how reset (my guess it's related to custom classloading in robolectric) but it seems that change this field via reflection in test runner is enough to make it work |
Ok now I tested solution and that one is worked for me package org.robolectric.shadows;
import com.almworks.sqlite4java.SQLiteConnection;
import org.robolectric.util.ReflectionHelpers;
/**
* hack to fix DB[*] will not dispose from a non-confining thread crash
*
* @see <a href="https://github.com/robolectric/robolectric/issues/1986#issuecomment-259374817">base solution on github</a>
*/
public class MyShadowSQLiteConnections extends ShadowSQLiteConnection.Connections {
private final static MyShadowSQLiteConnections CUSTOM_CONNECTIONS_INSTANCE = new MyShadowSQLiteConnections();
@Override
public void close(long ptr) {
execute("close connection", () -> {
SQLiteConnection connection = getConnection(ptr);
try {
connection.dispose();
} catch (AssertionError e) { // DB[*] will not dispose from a non-confining thread
// Hacky patch for #1986.
}
return null;
});
}
public static void resetConnectionsInShadowSQLiteConnection() {
ReflectionHelpers.setStaticField(ShadowSQLiteConnection.class, "CONNECTIONS", CUSTOM_CONNECTIONS_INSTANCE);
}
} call resetConnectionsInShadowSQLiteConnection() in constructor of your TestLifecycleApplication implementation will do the work. (maybe beforeTest is also ok but I haven't checked) |
thanks, @StanisVS, your workaround solved my issue: I saw time-to-time 30% of 200 tests failed; Robolectric 3.0. Now all seems to be ok. |
thanks also, @StanisVS, I added your workaround and called it in the |
@StanisVS thanks for providing a full working solution and sorry for mistakes in my pasted code, I see I really failed to mention CONNECTIONS field. |
I've encountered this problem when running tests on a Linux CI runner, it doesn't happen every time but when it does it causes many tests to fail. Seems to not happen on macOS (using robolecttic 3.4-rc2), or if it does happen then it's extremely rare. Really don't know why this at least seems to behave differently on different OS's, but it looks like the fact the
After looking at the release notes and history of sqlite4java, it seems that no exception should be raised. From the Change Log:
robolectric is using build 282 (the release after build 201) so should have that fix. However, when you look at commit for the fix, this documentation was added to the
And this is the code that was added to
That
would mean no The last commit to this project was in January 2016 so it's not looking too active. A fix for this problem could be just changing that flag, releasing |
After some more investigation, it would seem that this may be a symptom of another problem. This exception gets thrown because
So all the work should be on the same thread. However, the documentation for
So it's probably the case that at some point an unhandled exception is thrown during execution of one of the Should try and find out if it's the case that a new thread is being used for |
I was wrong in my previous 2 comments, I believe this error is the result of a race condition, I've opened a pull request to try and fix it (see pull request #3211 for an explanation of the issue and proposed fix). I've not been able to test my changes with a locally built snapshot of robolectric on my machine, would be great if someone could walk me through how to do it. Thanks! |
@matthewhubblerose try applying #3212 on your local checkout, running
|
Looks like the fix for this was released with 3.4 RC5 |
Hello, I have troubles running my tests suite on Ubuntu (everything is running fine on my OSX environment).
When i execute my full tests suites, the first tests are doing good, but they start to randomly crash with the following error (see below).
Any hint on where this could come from ? Why is it happening only on Ubuntu and not on OSX ?
Thanks
Robolectric 3.0
Shadow support v4 3.0
Gradle Wrapper 2.6
android-gradle 1.3.0
The text was updated successfully, but these errors were encountered: