-
-
Notifications
You must be signed in to change notification settings - Fork 439
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: "Error binding parameter 0 - probably unsupported type" (PyPy related?) #1010
Comments
FYI: I can handle this error by sleeping and re-executing sql.
|
@taolluo |
@taolluo without that except clause, how often does this happen? |
Yes, this error is very elusive, probably only once per hundreds and thousands of insertion. This error raises here in my code when running with PyPy, https://github.com/taolluo/desmod/blob/261b17abe7b9611e9f9cd43ceeae60b65e14fa92/docs/examples/DP_allocation/DP_simulator.py#L1480 |
For what it's worth we are seeing this maybe once in ten urllib3 PyPy tests, see https://github.com/urllib3/urllib3/pull/2086/checks?check_run_id=1446391457 for an example. Not sure how to get a traceback or reproducing it. |
@pquentin can you enable COVERAGE_DEBUG=sql environment variable for your coverage run? It will write all the SQL access to stderr, or you can define COVERAGE_DEBUG_FILE to be the file to write to. The last statement executed before the exception might give us a clue. |
I can also put in the sleep/retry that @taolluo suggested, though it's a little distasteful. |
I'm happy to help find the root cause, I agree that the sleep sounds like the wrong fix |
You can see a few failures here: https://github.com/pquentin/urllib3/runs/1449097388?check_suite_focus=true (there are multiple PyPy runs on the left, you may have to scroll a bit) |
Thanks, though the output is not encouraging. Here is one snippet:
Notice the first query here succeeded, and the last was the same query, with the same parameter types, but it failed. |
@pquentin Thanks so much for the repo, it's a great test case.
An immediate retry, with no sleep. It seems like there's a race condition somewhere in PyPy's SQLite support? |
@nedbat Thank you for this! We'll use that branch and report the bug to PyPy to see if they can do something with it. Is this involving threads? |
I don't see at the moment how threads are involved, but they could be. That branch will not exist for long. I can add this code to a real release soon. |
I've reported a PyPy issue: https://foss.heptapod.net/pypy/pypy/-/issues/3351 |
Would you be open to include the distateful fix in coverage? We're unlikely to see a PyPy fix soon and the bug continues to affect us. |
Yes, I intend to do that. I got distracted by completely re-vamping the CI for this repo :) |
PyPy seems prone to intermittent SQLite failures. An immediate retry avoids them. Not great, but it works.
PyPy seems prone to intermittent SQLite failures. An immediate retry avoids them. Not great, but it works.
This is now released as part of coverage 5.3.1. |
Thanks so much @nedbat, hope you're doing well :) |
FWIW I can still observer this issue here with coverage 5.5 https://github.com/twisted/twisted/pull/1577/checks?check_run_id=2274177993#step:9:751 The error is triggered by This error was only observed on GitHub Actions. |
Is this reproducible on GitHub Actions? Can you try the nedbat/another-1010 branch of coverage.py? It applies the original 1010 fix to the executemany call. |
Thanks Ned for the branch and your support. Much appreciated. I have only experience this issue with PYPY. .. and only on GitHub Actions. I tried to re-run pypy with coverage on my laptop in power The same tests are executed with py 3.6, 3.7, 3.8. 3.9. 3.10(alpha) and The main difference is that on CPython coverage is using the C Extension, while on PYPY it is not using it. BTW, on PYPY with coverage the tests are 10 times slower. On PYPY it used to fail about 30%. To speed up the tests, we are now running coverage test with PYPY only for a subset of tests.. and this time we got the sqlite error. The SQLite error is observed maybe 10% of the test runs. I have create a PR using your new branch. I am giving it a few more spins and will see if after 20 runs I still get a failure. Will report back after a few more retries. |
This was merged into twisted/twisted trunk. We will give it a spin for a few weeks and see how it goes. |
I am having the same error ,i need some help |
I've made the executemany fix on master in commit fad9ecf. If you can test with that code, I'd appreciate it. |
BTW: if you are using the nedbat/another-1010 branch, you should move off of it, so that I can delete it :) |
Thanks Ned for the update. At twisted/twisted we have moved to the public coverage.py release. We no longer need that branch. All works ok so far. |
I've deleted the nedbat/another-1010 branch. |
The following error happened with
Python 3.6.9[pypy-7.3.1-final]
.If I remember correctly I've seen this before (likely also with PyPy so it
might be a (compatibility) issue there), but it is not reproducible easily
(i.e. depends on some randomness somewhere, but e.g. pytest-xdist / parallel
execution is not involved here).
(Relevant) build log snippet:
(full: https://github.com/blueyed/pytest/runs/857827442)
The text was updated successfully, but these errors were encountered: