Skip to content
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

Open
marceltaeumel opened this issue Feb 26, 2018 · 9 comments
Open

Sporadic GoferRepositoryError via Metacello/SmalltalkCI #481

marceltaeumel opened this issue Feb 26, 2018 · 9 comments

Comments

@marceltaeumel
Copy link
Contributor

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:

gofer repository error: 'GoferRepositoryError: ByteString called #basicNew: with invalid argument -236'...ignoring

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

@dalehenrich
Copy link
Member

Metacello has the ability to unconditionally fail in the face of a GoferRepositoryError (see
MetacelloCommonMCSpecLoader class>>retryPackageResolution and MetacelloCommonMCSpecLoader class>>retryPackageResolution:) but I'm not sure if you can arrange to set that for a Travis run --- it can be challenging to debug issues remotely via Travis.

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?

@marceltaeumel
Copy link
Contributor Author

No, it always loads w/o debuggers locally once SqueakSSL is up an running. 😄

@krono
Copy link
Collaborator

krono commented Feb 26, 2018 via email

@dalehenrich
Copy link
Member

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...

@fniephaus
Copy link
Contributor

@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 #useLatestMetacello because that seems like a common request. Not sure if we really need to support loading of a specific Metacello version for debugging purposes in smalltalkCI?

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...

@dalehenrich
Copy link
Member

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...

@krono
Copy link
Collaborator

krono commented Feb 27, 2018

Old VMs is very likely. @fniephaus lets wait for a OpenSmalltalk VM release?

@fniephaus
Copy link
Contributor

Ok then, let's wait for the release and I will give those new VMs a try...fingers crossed

@marceltaeumel
Copy link
Contributor Author

Here are all variations of this behavior:

Job 347760798

Could not resolve: BaselineOfAnimations [BaselineOfAnimations] in /home/travis/smalltalkCI-master/_builds/package-cache github://hpi-swa/animations:master/repository ERROR: 'GoferRepositoryError: can''t find EOCD position'

Job 345921210

Could not resolve: BaselineOfWidgets [BaselineOfWidgets] in /home/travis/smalltalkCI-master/_builds/package-cache github://hpi-swa/widgets:master/repository ERROR: 'GoferRepositoryError: '

Job 345921211

Could not resolve: BaselineOfSignals [BaselineOfSignals] in /Users/travis/smalltalkCI-master/_builds/package-cache github://hpi-swa/signals:master/repository ERROR: 'GoferRepositoryError: ByteString called #basicNew: with invalid argument -236'

...maybe just a socket problem after all? Broken ZIP download and hence "EOCD" and negative byte string sizes...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants