-
Notifications
You must be signed in to change notification settings - Fork 43
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
Sporadic GoferRepositoryError via Metacello/SmalltalkCI #481
Comments
Metacello has the ability to unconditionally fail in the face of a GoferRepositoryError (see The best bet for figuring out what is going on is to reproduce this in an interactive environment with retryPackageResolution set to false ... then a debugger can be used to quickly get to the heart of the problem ... It should be possible to run SmalltalkCI interactively, but the type of failure you are describing should happen during regular Metacello loads, do you see these failures running local loads? |
No, it always loads w/o debuggers locally once SqueakSSL is up an running. 😄 |
Am 26. Februar 2018 17:27:25 MEZ schrieb Marcel Taeumel <notifications@github.com>:
No, it always loads w/o debuggers locally once SqueakSSL is up an
running. 😄
;P
--
Sent from mobile device
|
Hmm, that complicates things ... I don't think there is a way to customize the version of Metacello that is used by SmalltalkCI ... short of creating a clone of SmalltalkCI that uses a custom Metacello version, In the past I've debugged these problems by dumping stacks or logging additional information to the transcript. In this case we need to start by dumping a stack in MetacelloCommonMCSpecLoader>>retryingResolvePackageSpecReferences:gofer: and then work backwards with logging as we learn more about what is going wrong ... Alternatively, if we can figure out the code involved in the bogus ByteArray creation, we could possibly work forward and understand the issue from that direction --- putting in some logging that is only triggered on errors or at least code that could be safely put into the master branch of Metacello ... It just occurred to m e that I may have seen a similar issue elsewhere: Error when loading from github (failed only on gemstone) ... If you work your way down the thread there's a bug in ZipArchive when used with large zip files ... of course the error is not quite the same and in Mariano's case it was not intermittent ...but it may be related somehow... |
@dalehenrich you can run a custom script before loading a project and do whatever you want with the image, e.g. patch Metacello methods. Apart from that, there's only Maybe you could provide a changeset that adds additional logging, so Marcel can file that in before Vivide is loaded. I'm not sure if this is the reason for the error, but the VMs smalltalkCI uses for Squeak are quite old, because there are still some problems with SqueakSSL. I hope we can update them soon... |
Perhaps the root cause is actually the old vms being used by SmalltalkCI? What do you think @krono? if I is likely to be a Metacello issue then we'll need to go into debug mode... |
Old VMs is very likely. @fniephaus lets wait for a OpenSmalltalk VM release? |
Ok then, let's wait for the release and I will give those new VMs a try...fingers crossed |
Here are all variations of this behavior:
...maybe just a socket problem after all? Broken ZIP download and hence "EOCD" and negative byte string sizes... |
The project Vivide experiences sporadic issues on TravisCI via SmalltalkCI while loading the dependencies (including this and that).
It is always some (other) repository that cannot be fetched. Manual retries will eventually solve the problem, and the build will pass. I get the following hint in Travis' output:
I suspect that some HTTP request might not behave as expected and somewhere in the requestor (VM, Plugin, Squeak's sockets, Squeak's unzip mechanism, Gofer, Metacello, ...) the issue occurs and propagates up to Gofer.
I think that a more elaborate error log in Gofer can give us more clues here. Not sure how to enable such a thing. :-)
Best,
Marcel
The text was updated successfully, but these errors were encountered: