recent changes seem to break winbot #60
Comments
|
In fact, there are 2 issues:
This one is indeed related to #58, but it's not a regression. If possible, I'd like to increase timestamp precision on Windows platform.
It concerns #52, and it was not fixed by #57.
IOW, on Windows:
|
I have no Windows box but I made some searches and found that Meanwhile for ZODB, I'll just add a |
|
Please fix winbot, you know what a long standing red CI means... |
This is a 404 page. In the future can you please copy the traceback itself into the GitHub issue? |
|
my bad |
Merged
|
Bad news: winbot is still unhappy :( http://winbot.zope.org/builders/ZODB_dev%20py_270_win32/builds/17/steps/test/logs/stdio: (This was building commit ee94233) |
|
The failures seem more rare, e.g. only 3 tests failed on Python 3.3 (32-bit), and none at all on Python 3.3 (64-bit). The failures on Python 2.7 are all about X being not less than X with the exact same timestamp on both sides. The failures on Python 3.x look like X not less than Y where Y looks like X truncated to 6 decimal digits, e.g. Looks like the precision of |
|
I don't think there's any missing sleep. It's like sleep(0.001) does nothing. |
|
On Thu, Jun 16, 2016 at 7:38 AM, Julien Muchembled <notifications@github.com
Yes. I predict .002 will be enough.
If not, I'm not opposed to trying this on master. In fact, I'll bump it to
Jim Jim Fulton |
|
On Thu, Jun 16, 2016 at 8:50 AM, Jim Fulton jim@jimfulton.info wrote:
Done, Travis is green. Does anyone know how to force winbot to run? Jim Jim Fulton |
Sadly not, it's a buildbot, not a fancy-funky CI. |
I'll kick winbot |
|
I could test on Windows and found that there was a missing sleep. Only committed in branch '4' for the moment. |
tseaver
added a commit
that referenced
this issue
Jun 23, 2016
|
2ms are useless. The issue was already fixed by f46359e (you can see also see the difference between builds #26 and #27). Winbot still fails for another reason, apparently due to #56: |
|
@jmuchemb the 2ms change is what fixed the winbot timestamp failures. Those tests kept failing after f46359e (which you committed 2016-06-19 23:01 UTC), and went away after I pushed f886a01 (2016-06-23 12:08 UTC). |
jmuchemb
referenced
this issue
Aug 2, 2016
…tion. This implements: #50 Rather than watching invalidations, simply use 1 + the storages lastTransaction, which is equivalent to but much simpler than waiting for the first invalidation after a transaction starts. More importantly, it means we can always use loadBefore and get away from load. We no longer have to worry about ordering of invalidations and load() results. Much thanks to NEO for pointing the way toward this simplification! Implementing this initially caused a deadlock, because DB.open() called Connection.open() while holding a database lock and Connection.open() now calls IStotage.lastTransaction(), which acquires a storage lock. (It's not clear that lastTransaction() really needs a storage lock.) Meanwhile, IStotage.tpc_finish() calls a DB function that requires the DB lock while holding the storage lock. Fixing this required moving the call to Connection.open() outside the region where the DB lock was held. To debug the problem above, I greatly improved lock-debugging support. Now all of the ZODB code imports Lock, RLock and Condition from ZODB.utils. If the DEBUG_LOCKING is set to a non-empty value, then these are wrapped in such a way that debugging information is printed as they are used. This made spotting the nature of the deadlock easier. Of course, a change this basic broke lots of tests. Most of the breakage arises from the fact that connections now call lastTransaction on storages at transaction boundaries. Lots of tests didn't clean up databases and connections properly. I fixed many tests, but ultimately gave up and added some extra cleanup code that violated transaction-manager underware (and the underware's privates) to clear transaction synchonizers in test setup and tear-down. I plan to add a transaction manager API for this and to use it in a subsequent PR. This tests makes database and connection hygiene a bit more important, especially for tests, because a connection will continue to interact with storages if it isn't properly closed, which can lead to errors if the storage is closed. I chose not to swallow these errors in Connection, choosing rather to clean up tests. The thread debugging and test changes make this PR larger than I would have liked. Apologies in advance to the reviewers.
|
The above issue is fixed by 8b00038, but I didn't notice there was yet another issue on win32: |
|
... Maybe this can be reproduced on linux 32 ? |
|
In #157 CI services on Windows (AppVeyor) were added in April of this year. Those are green, so maybe this issue can be closed? It appears that winbot is still failing, but for a completely unrelated issue with buildout. |
|
Winbot's days are numbered anyway. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
http://winbot.zope.org/builders/ZODB_dev%20py_270_win32/builds/2116/steps/test/logs/stdio
(I plan to update builders to the currently supported platforms)
(also, @jimfulton you need failure emails from winbot?)
The text was updated successfully, but these errors were encountered: