Hello Mark,
When I check the server logs it says the below
Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
SEVERE: Trying to unexport an object that's already unexported
java.lang.IllegalStateException: Invalid object ID 102 iota=12324
at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:348)
at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:371)
at hudson.remoting.Channel.unexport(Channel.java:612)
at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:38)
at hudson.remoting.Channel$2.handle(Channel.java:483)
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60)
Caused by: java.lang.Exception: Object appears to be deallocated at lease
before Fri Jan 30 16:15:36 CET 2015
at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:344)
... 5 more
Jan 30, 2015 7:05:24 PM hudson.remoting.ExportTable unexportByOid
SEVERE: 2nd unexport attempt is here
Command hudson.remoting.UnexportCommand@1fe8ba9 created at
at hudson.remoting.Command.<init>(Command.java:67)
at hudson.remoting.Command.<init>(Command.java:50)
at hudson.remoting.UnexportCommand.<init>(UnexportCommand.java:33)
at
hudson.remoting.RemoteInvocationHandler.finalize(RemoteInvocationHandler.java:221)
at java.lang.System$2.invokeFinalize(Unknown Source)
at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
at java.lang.ref.Finalizer.access$100(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
Not getting a clue. :(
On Tuesday, February 3, 2015 at 10:28:33 AM UTC+5:30, Mark Waite wrote:
>
> I doubt very much that "-c core.askpass=true" would cause intermittent
> fetch failures.
>
> You might consider reading the log files of your git repository server, in
> case there is some hint in those logs which will tell you why it fails.
>
> Mark Waite
>
>
> On Mon, Feb 2, 2015 at 7:55 PM, Arunkumar Perumal <arunkuma...@gmail.com
> <javascript:>> wrote:
>
>> Ivo,
>>
>> Sorry, pls find below the details. I have job which will fetch the data
>> from the remote repository & I've setup the proxy details.
>>
>> The same job is getting success for a couple of times but after that it
>> started failing. I'm using git client plugin 1.14.0, git plugin 2.3.2.
>> Couldn't understand how this is getting success some time & all other time
>> failing :(.
>>
>> So I thought of removing the -c core.askpass=true option may help.
>>
>> success case:
>>
>> using .gitcredentials to set credentials
>> > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store
>> --file=/tmp/git949589945555918016.credentials # timeout=10
>> Setting http proxy: server:8080
>> > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags
>> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>> > /usr/local/git_1.8.4.4/bin/git config --local --remove-section
>> credential # timeout=10
>> > /usr/local/git_1.8.4.4/bin/git rev-parse
>> refs/remotes/origin/master^{commit} # timeout=10
>> > /usr/local/git_1.8.4.4/bin/git rev-parse
>> refs/remotes/origin/origin/master^{commit} # timeout=10
>> Checking out Revision 8e4b0169a13bbc56d3dad066ee44eae184ec0162
>> (refs/remotes/origin/master)
>> > /usr/local/git_1.8.4.4/bin/git config core.sparsecheckout # timeout=10
>> > /usr/local/git_1.8.4.4/bin/git checkout -f
>> 8e4b0169a13bbc56d3dad066ee44eae184ec0162
>> > /usr/local/git_1.8.4.4/bin/git rev-list
>> 901c14ef7620cd409cb1712a30803742a8d49357 # timeout=10
>>
>> failure case:
>>
>> using .gitcredentials to set credentials
>> > /usr/local/git_1.8.4.4/bin/git config --local credential.helper store
>> --file=/tmp/git7741299244057538477.credentials # timeout=10
>>
>> Setting http proxy: server:8080
>> > /usr/local/git_1.8.4.4/bin/git -c core.askpass=true fetch --tags
>> --progress https://server/git/repo +refs/heads/*:refs/remotes/origin/*
>> > /usr/local/git_1.8.4.4/bin/git config --local --remove-section
>> credential # timeout=10
>> ERROR: Error fetching remote repo 'origin'
>> ERROR: Error fetching remote repo 'origin'
>>
>>
>>
>>
>>
>>
>>
>> On Tuesday, February 3, 2015 at 12:20:52 AM UTC+5:30, Ivo Bellin Salarin
>> wrote:
>>>
>>> I will try to justify a little more the existence of the -c
>>> core.askpass=true option.
>>> This is essentially a "a la volée" modification of the .gitconfig
>>> content.
>>>
>>> This option says to git to use /bin/true (which always returns 1) as
>>> identity manager in the case where the remote server asks an explicit
>>> authentication. Or, in the case the provided identification isn't
>>> sufficient for the remote server needs.
>>>
>>> (Even more detailed and precise documentation can be found on
>>> http://git-scm.com/docs/git-config)
>>>
>>> In versions before the 1.14, the git client plugin was using an explicit
>>> http connection to test the provided credentials.
>>>
>>> Such approach was limited, when compared to the libraries used by git
>>> itself. These libraries are able to use several authentication schemas,
>>> which weren't supported by the git-client plugin.
>>>
>>> I hope that these details satisfy your needs. I hope to get more details
>>> about the misbehaviors that this option is causing to you.
>>>
>>> Thanks in advance,
>>> Ivo
>>>
>>> Il giorno lun 2 feb 2015 19:13 Ivo Bellin Salarin <ivo.bell...@gmail.com>
>>> ha scritto:
>>>
>>>> Dear user of the git plugin,
>>>>
>>>> Is this option causing some misbehavior in your environment?
>>>> Could you please describe it?
>>>>
>>>> Or, yours is rather a conservative attitude towards changes which could
>>>> deteriorate your build environment?
>>>>
>>>> Il giorno lun 2 feb 2015 17:57 Arunkumar Perumal <arunkuma...@gmail.com>
>>>> ha scritto:
>>>>
>>>> Hello Mark,
>>>>>
>>>>> When I use Git Client Plugin 1.13.0, I'm not getting -c
>>>>> core.askpass=true.
>>>>>
>>>>> But when I use, 1.14.0, its using that option but you have released
>>>>> the change in 1.14.1. Could you please let me know how I can skip this
>>>>> particular step in Git Client Plugin 1.14.0
>>>>>
>>>>> 1.14.1 (Dec 27, 2014)
>>>>>
>>>>> - Only use "-c core.askpass=true" if command line git is newer
>>>>> than 1.7.9 (don't break really old git versions unnecessarily)
>>>>>
>>>>> 1.14.0 (Dec 25, 2014)
>>>>>
>>>>> - Update from JGit 3.5.3 to JGit 3.6.0
>>>>> - Use command line credentials check when using command line git
>>>>> (issue #22675 <http://issues.jenkins-ci.org/browse/JENKINS-22675>,
>>>>> issue
>>>>> #22909 <http://issues.jenkins-ci.org/browse/JENKINS-22909>, issue
>>>>> #23050 <http://issues.jenkins-ci.org/browse/JENKINS-23050>, issue
>>>>> #20533 <http://issues.jenkins-ci.org/browse/JENKINS-20533>)
>>>>>
>>>>>
>>>>>
>>>>> On Wednesday, January 28, 2015 at 10:01:24 AM UTC+5:30, Mark Waite
>>>>> wrote:
>>>>>
>>>>>> The "-c core.askpass=true" is used to prevent the git command line
>>>>>> call from prompting for a password from stdin. It was added in a recent
>>>>>> git-client-plugin and was a key change to enable resolution of several
>>>>>> other bugs. I doubt very much that argument is causing an
>>>>>> authentication
>>>>>> problem.
>>>>>>
>>>>> On Tue, Jan 27, 2015 at 9:15 AM, Rob Mandeville <
>>>>>> rmand...@dekaresearch.com> wrote:
>>>>>>
>>>>>>> I am using:
>>>>>>>
>>>>>>> · Jenkins 1.580.2
>>>>>>>
>>>>>>> · GIT client plugin 1.15.0
>>>>>>>
>>>>>>> · GIT plugin 2.3.4
>>>>>>>
>>>>>>> · Workflow plugins 1.1
>>>>>>>
>>>>>>> · Credentials plugin 1.22
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We use GitLab for source control and do not allow anonymous access
>>>>>>> of any kind. We use the Credentials plugin, have put in credentials
>>>>>>> allowing us access to Git, and on our normal projects, we simply give
>>>>>>> Git
>>>>>>> these pre-loaded credentials. Now, I’m trying to create a Workflow job.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I can’t find any doc which says how to feed credentials to Git, so I
>>>>>>> went to the credentials plugin and pulled the plugin ID from the URL.
>>>>>>> I
>>>>>>> then wrote the following Groovy CPS DSL script (without the redactions,
>>>>>>> obviously):
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> steps.stage('Setup')
>>>>>>>
>>>>>>> node('mock_builder') {
>>>>>>>
>>>>>>> String templateUrl = 'git@URL_REDACTED'
>>>>>>>
>>>>>>> steps.git(url: templateUrl, credentialsId: 'ID_REDACTED')
>>>>>>>
>>>>>>> sh 'echo hello world'
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The job gets stuck in the SCM step and exits with the following
>>>>>>> output:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Running: Setup
>>>>>>>
>>>>>>> Entering stage Setup
>>>>>>>
>>>>>>> Proceeding
>>>>>>>
>>>>>>> Running: Allocate node : Start
>>>>>>>
>>>>>>> Running on mock_builder in
>>>>>>> C:\Windows\TEMP\hudson1572436821107746068tmp\workspace\Try a Workflow
>>>>>>>
>>>>>>> Running: Allocate node : Body : Start
>>>>>>>
>>>>>>> Running: Git
>>>>>>>
>>>>>>> > git.exe rev-parse --is-inside-work-tree # timeout=10
>>>>>>>
>>>>>>> Fetching changes from the remote Git repository
>>>>>>>
>>>>>>> > git.exe config remote.origin.url git@URL_REDACTED # timeout=10
>>>>>>>
>>>>>>> Fetching upstream changes from git@URL_REDACTED
>>>>>>>
>>>>>>> > git.exe --version # timeout=10
>>>>>>>
>>>>>>> > git.exe -c core.askpass=true fetch --tags --progress
>>>>>>> git@URL_REDACTED +refs/heads/*:refs/remotes/origin/*
>>>>>>>
>>>>>>> ERROR: Timeout after 10 minutes
>>>>>>>
>>>>>>> ERROR <http://stacktrace.jenkins-ci.org/search?query=ERROR>: Error
>>>>>>> fetching remote repo 'origin'
>>>>>>>
>>>>>>> Running <http://stacktrace.jenkins-ci.org/search?query=Running>:
>>>>>>> Allocate node : Body : End
>>>>>>>
>>>>>>> Running: Allocate node : End
>>>>>>>
>>>>>>> Running: End of Workflow
>>>>>>>
>>>>>>> ERROR: Error fetching remote repo 'origin'
>>>>>>>
>>>>>>> Finished <http://stacktrace.jenkins-ci.org/search?query=Finished>:
>>>>>>> FAILURE
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I’m wondering where the “-c core.askpass=true” came from, and
>>>>>>> figuring that it was waiting to receive a password via standard input.
>>>>>>>
>>>>>>> Is there any way, with or without the credentials plugin, to feed
>>>>>>> Git credentials to this project?
>>>>>>>
>>>>>>
>>>>>> The "-c core.askpass=true" is used to prevent the git command line
>>>>>> call from prompting for a password from stdin. It was added in a recent
>>>>>> git-client-plugin and was a key change to enable resolution of several
>>>>>> other bugs. I doubt very much that argument is causing an
>>>>>> authentication
>>>>>> problem.
>>>>>>
>>>>>>
>>>>> Thanks in advance,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --Rob
>>>>>>>
>>>>>>> ------------------------------
>>>>>>> This e-mail and the information, including any attachments it
>>>>>>> contains, are intended to be a confidential communication only to the
>>>>>>> person or entity to whom it is addressed and may contain information
>>>>>>> that
>>>>>>> is privileged. If the reader of this message is not the intended
>>>>>>> recipient,
>>>>>>> you are hereby notified that any dissemination, distribution or copying
>>>>>>> of
>>>>>>> this communication is strictly prohibited. If you have received this
>>>>>>> communication in error, please immediately notify the sender and
>>>>>>> destroy
>>>>>>> the original message.
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>> Please consider the environment before printing this email.
>>>>>>>
>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "Jenkins Users" group.
>>>>>>>
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to jenkinsci-use...@googlegroups.com.
>>>>>>
>>>>>>
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/jenkinsci-users/0A40042D85
>>>>>>> E7C84DB443060EC44B3FD36D9ACEDA91%40dekaexchange07.deka.local
>>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/0A40042D85E7C84DB443060EC44B3FD36D9ACEDA91%40dekaexchange07.deka.local?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks!
>>>>>> Mark Waite
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Jenkins Users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to jenkinsci-use...@googlegroups.com.
>>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>>> msgid/jenkinsci-users/29112111-e2f5-4d62-b916-011e72dbfae2%
>>>>> 40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/29112111-e2f5-4d62-b916-011e72dbfae2%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-use...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/c461ac80-a0ef-436c-94c9-906f13fc1b4f%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/jenkinsci-users/c461ac80-a0ef-436c-94c9-906f13fc1b4f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Thanks!
> Mark Waite
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/3f8c619c-a7ba-4f50-8e2f-51b201673caf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
