anyone seen java svn crap out like this ?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

anyone seen java svn crap out like this ?

Arnaud LACOUR
this only happens on Linux RH3 and nothing I could do would solve that.
Even clobbering the workspace wouldn't help.
any ideas ?
my build is stuck now.

started
Building remotely on Linux RH4-x64 (rogue)
Updating https://xyz.dev.java.net/svn/xyz/trunk/xyz
FATAL: null
java.lang.IndexOutOfBoundsException
        at java.nio.Buffer.checkBounds(Buffer.java:454)
        at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:125)
        at java.nio.ByteBuffer.get(ByteBuffer.java:674)
        at org.tmatesoft.svn.core.internal.delta.SVNDeltaReader.deflate(SVNDeltaReader.java:159)
        at org.tmatesoft.svn.core.internal.delta.SVNDeltaReader.nextWindow(SVNDeltaReader.java:124)
        at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVDeltaHandler.characters(BasicDAVDeltaHandler.java:98)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.characters(AbstractSAXParser.java:570)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanContent(XMLDocumentFragmentScannerImpl.java:1062)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1649)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:634)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:597)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:197)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:230)
        at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:218)
        at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:219)
        at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:211)
        at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:608)
        at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:162)
        at hudson.scm.SubversionSCM$1.invoke(SubversionSCM.java:288)
        at hudson.scm.SubversionSCM$1.invoke(SubversionSCM.java:277)
        at hudson.FilePath$FileCallableWrapper.call(FilePath.java:873)
        at hudson.remoting.UserRequest.perform(UserRequest.java:57)
        at hudson.remoting.UserRequest.perform(UserRequest.java:22)
        at hudson.remoting.Request$2.run(Request.java:178)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: anyone seen java svn crap out like this ?

Fabrizio Giudici
Are you saying that you can't check out anything from dev.java.net?  
It's happening on my server since a couple of weeks (with different  
error messages). I'm getting crazy with my provider because I think  
it's a network configuration problem - but perhaps if it's happening  
to others it's a java.net problem?

(I really don't think it's a Hudson problem, BTW).

On Apr 24, 2007, at 18:46 , Arnaud LACOUR wrote:

> this only happens on Linux RH3 and nothing I could do would solve  
> that.
> Even clobbering the workspace wouldn't help.
> any ideas ?
> my build is stuck now.
>
>

--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
[hidden email] - mobile: +39 348.150.6941


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: anyone seen java svn crap out like this ?

Kohsuke Kawaguchi
Administrator
In reply to this post by Arnaud LACOUR
I'd like to check the code (yet I don't have the source code in front
of me right now), but I remember there was a very mysterious bug
report about Buffer.checkBounds error in the past. See
http://www.nabble.com/Jira-plugin-released-tf3393187.html#a9466800

2007/4/24, Arnaud LACOUR <[hidden email]>:

> this only happens on Linux RH3 and nothing I could do would solve that.
> Even clobbering the workspace wouldn't help.
> any ideas ?
> my build is stuck now.
>
> started
> Building remotely on Linux RH4-x64 (rogue)
> Updating https://xyz.dev.java.net/svn/xyz/trunk/xyz
> FATAL: null
> java.lang.IndexOutOfBoundsException
>         at java.nio.Buffer.checkBounds(Buffer.java:454)
>         at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:125)
>         at java.nio.ByteBuffer.get(ByteBuffer.java:674)
>         at org.tmatesoft.svn.core.internal.delta.SVNDeltaReader.deflate(SVNDeltaReader.java:159)
>         at org.tmatesoft.svn.core.internal.delta.SVNDeltaReader.nextWindow(SVNDeltaReader.java:124)
>         at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVDeltaHandler.characters(BasicDAVDeltaHandler.java:98)
>         at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.characters(AbstractSAXParser.java:570)
>         at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanContent(XMLDocumentFragmentScannerImpl.java:1062)
>         at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1649)
>         at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
>         at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
>         at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
>         at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
>         at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
>         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:634)
>         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:597)
>         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:197)
>         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285)
>         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:230)
>         at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:218)
>         at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:219)
>         at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:211)
>         at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:608)
>         at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:162)
>         at hudson.scm.SubversionSCM$1.invoke(SubversionSCM.java:288)
>         at hudson.scm.SubversionSCM$1.invoke(SubversionSCM.java:277)
>         at hudson.FilePath$FileCallableWrapper.call(FilePath.java:873)
>         at hudson.remoting.UserRequest.perform(UserRequest.java:57)
>         at hudson.remoting.UserRequest.perform(UserRequest.java:22)
>         at hudson.remoting.Request$2.run(Request.java:178)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>         at java.lang.Thread.run(Thread.java:595)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: anyone seen java svn crap out like this ?

Arnaud LACOUR
In reply to this post by Fabrizio Giudici
On 4/25/07, Fabrizio Giudici <[hidden email]> wrote:
> Are you saying that you can't check out anything from dev.java.net?
no, the checkout fails only on one of the machines in my cluster.
> It's happening on my server since a couple of weeks (with different
> error messages). I'm getting crazy with my provider because I think
> it's a network configuration problem - but perhaps if it's happening
> to others it's a java.net problem?
CollabNet has just undergone a major migation just recently and that
might just be what you are seeing. On my part, I believe that given
the fact my solaris boxes are reliably able to check out the code, it
might have been something in the way hudson leverages the javaSVN
library or, as you mentioned, a problem in javaSVN itself.

>
> (I really don't think it's a Hudson problem, BTW).
>
> On Apr 24, 2007, at 18:46 , Arnaud LACOUR wrote:
>
> > this only happens on Linux RH3 and nothing I could do would solve
> > that.
> > Even clobbering the workspace wouldn't help.
> > any ideas ?
> > my build is stuck now.
> >
> >
>
> --
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
> [hidden email] - mobile: +39 348.150.6941
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: anyone seen java svn crap out like this ?

Kohsuke Kawaguchi
Administrator
See the post I referenced to. This is the exact same stack trace. As
far as I can tell, this failure is impossible --- meaning it must be
VM bug, cosmic radiation, psychokinesis, etc.

If you can double check my sanity by following the code I cited, that
would be great.

2007/4/25, Arnaud LACOUR <[hidden email]>:
> CollabNet has just undergone a major migation just recently and that
> might just be what you are seeing. On my part, I believe that given
> the fact my solaris boxes are reliably able to check out the code, it
> might have been something in the way hudson leverages the javaSVN
> library or, as you mentioned, a problem in javaSVN itself.

--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]