-
Notifications
You must be signed in to change notification settings - Fork 231
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
CI Win64 - "The parameter is incorrect" / "The handle is invalid" #435
Comments
It seems reasonable to wrap some of them in
or its moral equivalent in terms of maintaining the list of such tests, in such a way as they can be easily found and stripped out later when this issue is resolved. |
I can reproduce it locally. I will take a look |
A new one from #436 - https://ci.appveyor.com/project/nimbus/nim-beacon-chain/builds/27346548/job/gki7ew7tkda8ou8w#L242 This BLS test has always been working for month and the next tests work.
The change was just: status-im/nim-serialization@e874ae6...master template loadFile*(Format: distinct type,
filename: string,
RecordType: distinct type,
params: varargs[untyped]): auto =
mixin init, ReaderType
var stream = openFile(filename)
# TODO:
# Remove this when statement once the following bug is fixed:
# https://github.com/nim-lang/Nim/issues/9996
when astToStr(params) != "":
var reader = init(ReaderType(Format), stream, params)
else:
var reader = init(ReaderType(Format), stream)
reader.readValue(RecordType) template loadFile*(Format: distinct type,
filename: string,
RecordType: distinct type,
params: varargs[untyped]): auto =
reader.readValue(RecordType)
try:
# TODO:
# Remove this when statement once the following bug is fixed:
# https://github.com/nim-lang/Nim/issues/9996
when astToStr(params) != "":
var reader = init(ReaderType(Format), stream, params)
else:
var reader = init(ReaderType(Format), stream)
reader.readValue(RecordType)
finally:
# TODO: destructors
if not stream.isNil:
stream[].close() |
) * Prepare test suite for transfers * split API process_transfer / processTransfers * Add range checks on transfer * Fix invalid transfer conditions * don't test on windows 64-bit #435
* [Test] Official operations - deposits unit test * Allow ignoring deposits with invalid signature * We need stacktraces to debug windows 64 issue #408 (comment) * fix naming of unit test proc * Revert "We need stacktraces to debug windows 64 issue #408 (comment)" This reverts commit 04b8b05. * skip windows-64 in CI #435 * proposer slashing started to crash as well on win-64 #435
* Bump nim-serialization to include status-im/nim-serialization#10 and maybe solve #435 * bump again - status-im/nim-serialization#12 * fix null pointer dereference if stream is empty: status-im/nim-serialization#13 * pull status-im/nim-serialization#15, hopefully the last bump
We got a new one: https://ci.appveyor.com/project/nimbus/nim-beacon-chain/build/job/tfvhv77u93mkf88y#L3212 for PR #442
|
* enable all sanity slots tests * enable more tests in sanity blocks * win64 strikes again #435 * workaround invalid handle in win64 CI * empty_epoch_transition_not_finalizing only valid in minimal preset * sanity block ETH1 data votes are also minimal only
I have found our source of bug. see nim-lang/Nim#12186 |
closed by #513 |
) * Bump nim-serialization to include status-im/nim-serialization#10 and maybe solve status-im#435 * bump again - status-im/nim-serialization#12 * fix null pointer dereference if stream is empty: status-im/nim-serialization#13 * pull status-im/nim-serialization#15, hopefully the last bump
) * Bump nim-serialization to include status-im/nim-serialization#10 and maybe solve status-im#435 * bump again - status-im/nim-serialization#12 * fix null pointer dereference if stream is empty: status-im/nim-serialization#13 * pull status-im/nim-serialization#15, hopefully the last bump
) * Bump nim-serialization to include status-im/nim-serialization#10 and maybe solve status-im#435 * bump again - status-im/nim-serialization#12 * fix null pointer dereference if stream is empty: status-im/nim-serialization#13 * pull status-im/nim-serialization#15, hopefully the last bump
) * Bump nim-serialization to include status-im/nim-serialization#10 and maybe solve status-im#435 * bump again - status-im/nim-serialization#12 * fix null pointer dereference if stream is empty: status-im/nim-serialization#13 * pull status-im/nim-serialization#15, hopefully the last bump
#415 is blocked on an Windows + 64-bit + -d:release only error in PR #408 #422 #431
Some tests seem to fail for no apparent reason, probably while reading the file. Windows 32-bit does not exhibit this behaviour.
Example: #422 (comment) (https://ci.appveyor.com/project/nimbus/nim-beacon-chain/builds/27293393/job/0b600abqo06snpgi#L3130)
Unfortunately, it seems like a non-trivial issue to debug by just relying on the CI as we cannot even reproduce the issue with
--opt:size
instead of--d:release
.It may even be triggered randomly by the kernel see an unrelated codepath (COM+ objects) that trigger the same error randomly.
At first glance looking through those issues, and given the Nim code it should be related to opening/reading files, and maybe to LFS?
status-im/nim-serialization#9 has been open to rule out running of file descriptors.
The text was updated successfully, but these errors were encountered: