You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Darly Senecal Baptiste <ds...@gmail.com> on 2014/06/26 18:22:17 UTC
SVN JavaHL 1.10.5 makes Eclipse to crash
Hi Community:
I updated subclipse plugin to the latest version (1.10.5) with JavaHL as
its default subversion client adapter.
I checked out code from a small repository (completely) and everything went
well. However, while I was trying to check out part of code from a large
repository, eclipse crashes unexpectedly. I don't know why
I changed the client adapter from JavaHL to SVNKit(JavaSVN) and all
checkouts went well without crashing eclipse.
I was trying to look the reasons of the crash but the eclipse log doesn't
provide the reasons of crashing.
Is there a way to look for reasons of eclipse being crashed? Please let me
know.
In addition I looked at the server logs the following error at the moment
of the incident
[Thu Jun 26 10:55:26.087485 2014] [dav:error] [pid 25691] [client
10.20.71.52:53404] Unable to deliver content. [500, #0]
[Thu Jun 26 10:55:26.087525 2014] [dav:error] [pid 25691] [client
10.20.71.52:53404] Could not write data to filter. [500, #175002]
[Thu Jun 26 10:55:26.087532 2014] [dav:error] [pid 25028] [client
10.20.71.52:53405] Unable to deliver content. [500, #0]
[Thu Jun 26 10:55:26.087559 2014] [dav:error] [pid 25028] [client
10.20.71.52:53405] Could not write data to filter. [500, #175002]
[Thu Jun 26 10:55:26.087842 2014] [dav:error] [pid 25693] [client
10.20.71.52:53399] Provider encountered an error while streaming a REPORT
response. [500, #0]
[Thu Jun 26 10:55:26.087876 2014] [dav:error] [pid 25693] [client
10.20.71.52:53399] A failure occurred while driving the update report
editor [500, #104]
Regards
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Branko Čibej <br...@wandisco.com>.
On 30.06.2014 20:26, Mark Phippard wrote:
> On Mon, Jun 30, 2014 at 1:00 PM, Darly Senecal Baptiste
> <dsenecalb@gmail.com <ma...@gmail.com>> wrote:
>
> Looking at the network trace packet wireshark PoV, looks like that
> the server tried to send data to the client (javahl), but saw that
> client's data buffer window is full (like ZeroWindow packet) and
> client is sending a zero window to the server. And finally, the
> client is sending a series of RESET packets to server. And these
> RST packets appears when javaHL crashed
>
>
> If JVM is crashing it should be producing a dump. Find it and send it.
>
> Also, as I mentioned earlier, you should see if you can recreate the
> crash using the command line.
Not necessarily. I fixed a bug in JavaHL just today that was specific to
the JavaHL native code and was not triggered by a similar code path used
by the command-line client.
That bug wasn't in any way related to this problem, though; it was in
trunk JavaHL and not in any released version; but that doesn't mean
there aren't any such bugs in released versions of JavaHL, too.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Darly Senecal Baptiste <ds...@gmail.com>.
Is there any other Java debugger can I perform it on Windows?
On Tue, Jul 1, 2014 at 12:06 PM, Darly Senecal Baptiste <dsenecalb@gmail.com
> wrote:
> In addition, I have svnkit (pure java) installed on Eclipse.
> Does it affects the use of JavaHL?
>
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Darly Senecal Baptiste <ds...@gmail.com>.
In addition, I have svnkit (pure java) installed on Eclipse.
Does it affects the use of JavaHL?
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Mark Phippard <ma...@gmail.com>.
I just realized those are not the right debug files anyway. I'll try to dig them up.
Sent from my iPad
> On Jun 30, 2014, at 5:50 PM, Branko Čibej <br...@wandisco.com> wrote:
>
>> On 30.06.2014 22:41, Mark Phippard wrote:
>> I do not know how you can debug, but I can point you to PDB's for the binaries you are using.
>>
>> http://pkg.collab.net/build/windows/CollabNet_Subversion-Win32-Debug-1.8.9.47.zip
>>
>> Brane might know better how you can use these to get better info.
>
> Well, I've never done any debugging with JavaHL on Windows. But if you somehow manage to make those .pdb's available to the JVM -- I guess it should be enough to put them in the same directory as the relevant .dll's -- then at least the JVM crash report stack trace should give better info about what caused the crash.
>
> It would also be possible to attach a debugger to the Eclipse process then; but it'll have to be a native, not Java debugger, since the crash happens in native code.
>
> -- Brane
>
>>> On Mon, Jun 30, 2014 at 4:20 PM, Darly Senecal Baptiste <ds...@gmail.com> wrote:
>>>
>>>>
>>>> This is a bit of a problem ... there's no debug information available for the native libraries, which makes it rather hard to tell what the problem might be.
>>>>
>>>>
>>>> Is the repository by any chance public, so that I could try to do a checkout using JavaHL within a debugger?
>>>>
>>>
>>> I don't think ... However, is there a way that I can debug it from Eclipse?
>
> --
> Branko Čibej | Director of Subversion
> WANdisco // Non-Stop Data
> e. brane@wandisco.com
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Branko Čibej <br...@wandisco.com>.
On 30.06.2014 22:41, Mark Phippard wrote:
> I do not know how you can debug, but I can point you to PDB's for the
> binaries you are using.
>
> http://pkg.collab.net/build/windows/CollabNet_Subversion-Win32-Debug-1.8.9.47.zip
>
> Brane might know better how you can use these to get better info.
Well, I've never done any debugging with JavaHL on Windows. But if you
somehow manage to make those .pdb's available to the JVM -- I guess it
should be enough to put them in the same directory as the relevant
.dll's -- then at least the JVM crash report stack trace should give
better info about what caused the crash.
It would also be possible to attach a debugger to the Eclipse process
then; but it'll have to be a native, not Java debugger, since the crash
happens in native code.
-- Brane
> On Mon, Jun 30, 2014 at 4:20 PM, Darly Senecal Baptiste
> <dsenecalb@gmail.com <ma...@gmail.com>> wrote:
>
>
>
> This is a bit of a problem ... there's no debug information
> available for the native libraries, which makes it rather hard
> to tell what the problem might be.
>
>
> Is the repository by any chance public, so that I could try to
> do a checkout using JavaHL within a debugger?
>
>
> I don't think ... However, is there a way that I can debug it
> from Eclipse?
>
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Mark Phippard <ma...@gmail.com>.
I do not know how you can debug, but I can point you to PDB's for the
binaries you are using.
http://pkg.collab.net/build/windows/CollabNet_Subversion-Win32-Debug-1.8.9.47.zip
Brane might know better how you can use these to get better info.
On Mon, Jun 30, 2014 at 4:20 PM, Darly Senecal Baptiste <dsenecalb@gmail.com
> wrote:
>
>
>> This is a bit of a problem ... there's no debug information available for
>> the native libraries, which makes it rather hard to tell what the problem
>> might be.
>>
>>
>> Is the repository by any chance public, so that I could try to do a
>> checkout using JavaHL within a debugger?
>>
>>
> I don't think ... However, is there a way that I can debug it from
> Eclipse?
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Darly Senecal Baptiste <ds...@gmail.com>.
>
> This is a bit of a problem ... there's no debug information available for
> the native libraries, which makes it rather hard to tell what the problem
> might be.
>
>
> Is the repository by any chance public, so that I could try to do a
> checkout using JavaHL within a debugger?
>
>
I don't think ... However, is there a way that I can debug it from Eclipse?
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Branko Čibej <br...@wandisco.com>.
On 30.06.2014 22:01, Darly Senecal Baptiste wrote:
>
>
>
> Also, you can see the jvm dump at this link
> https://db.tt/LBOXhJyi .
>
>
> Just for the archives, pasting the relevent bits. Nothing jumps
> out at me here to point in any direction though:
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6508a7cf, pid=6324, tid=6692
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_55-b14) (build 1.7.0_55-b14)
> # Java VM: Java HotSpot(TM) Client VM (24.55-b03 mixed mode, sharing windows-x86 )
> # Problematic frame:
> # C [libsvn_wc-1.dll+0x4a7cf]
> #
> # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
>
>
> Stack: [0x05880000,0x05980000], sp=0x0597eaac, free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libsvn_wc-1.dll+0x4a7cf]
> C [libsvn_ra-1.dll+0x496b7]
> C [libsvn_ra-1.dll+0x4470b]
> C [libsvn_ra-1.dll+0x44abe]
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.apache.subversion.javahl.SVNClient.checkout(Ljava/lang/String;Ljava/lang/String;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;ZZ)J+0
>
This is a bit of a problem ... there's no debug information available
for the native libraries, which makes it rather hard to tell what the
problem might be.
Is the repository by any chance public, so that I could try to do a
checkout using JavaHL within a debugger?
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Darly Senecal Baptiste <ds...@gmail.com>.
Using the following version
Are you using same SVN versions? What are you using for command line
> binaries? Ideally, try the ones from CollabNet since that is what
> Subclipse is using. Could be related to a specific version of SVN or
> dependency.
SVN Linux command line : version 1.8.5 taken from Collabnet
TortoiseSVN: version 1.8.6 with svn 1.8.8
JavaHL : version 1.8.9
On Mon, Jun 30, 2014 at 3:28 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, Jun 30, 2014 at 3:09 PM, Darly Senecal Baptiste <
> dsenecalb@gmail.com> wrote:
>
>> To be clear and to double confirm
>>
>> Recreated the same svn checkout command through command line and
>> TortoiseSVN, checkouts went through without any issue.
>>
>
> Are you using same SVN versions? What are you using for command line
> binaries? Ideally, try the ones from CollabNet since that is what
> Subclipse is using. Could be related to a specific version of SVN or
> dependency.
>
>
>
>> Also, you can see the jvm dump at this link https://db.tt/LBOXhJyi .
>>
>>
> Just for the archives, pasting the relevent bits. Nothing jumps out at me
> here to point in any direction though:
>
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6508a7cf, pid=6324, tid=6692
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_55-b14) (build 1.7.0_55-b14)
> # Java VM: Java HotSpot(TM) Client VM (24.55-b03 mixed mode, sharing windows-x86 )
> # Problematic frame:
> # C [libsvn_wc-1.dll+0x4a7cf]
> #
> # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
>
>
> Stack: [0x05880000,0x05980000], sp=0x0597eaac, free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [libsvn_wc-1.dll+0x4a7cf]
> C [libsvn_ra-1.dll+0x496b7]
> C [libsvn_ra-1.dll+0x4470b]
> C [libsvn_ra-1.dll+0x44abe]
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.apache.subversion.javahl.SVNClient.checkout(Ljava/lang/String;Ljava/lang/String;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;ZZ)J+0
> j org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.checkout(Lorg/tigris/subversion/svnclientadapter/SVNUrl;Ljava/io/File;Lorg/tigris/subversion/svnclientadapter/SVNRevision;IZZ)V+147
> j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.checkoutProject(Lorg/eclipse/core/runtime/IProgressMonitor;Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;Lorg/tigris/subversion/svnclientadapter/ISVNClientAdapter;Ljava/io/File;)V+79
> j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.basicRun(Lorg/eclipse/core/resources/IProject;Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;Lorg/eclipse/core/runtime/IProgressMonitor;)V+273
> j org.tigris.subversion.subclipse.core.commands.CheckoutCommand$1.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+13
> j org.tigris.subversion.subclipse.core.SVNProviderPlugin$6.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+10
> j org.eclipse.core.internal.resources.Workspace.run(Lorg/eclipse/core/resources/IWorkspaceRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;ILorg/eclipse/core/runtime/IProgressMonitor;)V+80
> j org.tigris.subversion.subclipse.core.SVNProviderPlugin.run(Lorg/tigris/subversion/subclipse/core/ISVNRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;Lorg/eclipse/core/runtime/IProgressMonitor;)V+20
> j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+41
> j org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute([Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;[Lorg/eclipse/core/resources/IProject;Lorg/eclipse/core/runtime/IProgressMonitor;)Z+81
> j org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute(Lorg/eclipse/core/runtime/IProgressMonitor;)V+94
> j org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+35
> j org.eclipse.team.internal.ui.actions.JobRunnableContext.run(Lorg/eclipse/jface/operation/IRunnableWithProgress;Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+2
> j org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+9
> j org.eclipse.core.internal.resources.InternalWorkspaceJob.run(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+37
> j org.eclipse.core.internal.jobs.Worker.run()V+23
> v ~StubRoutines::call_stub
>
>
>
>
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jun 30, 2014 at 3:09 PM, Darly Senecal Baptiste <dsenecalb@gmail.com
> wrote:
> To be clear and to double confirm
>
> Recreated the same svn checkout command through command line and
> TortoiseSVN, checkouts went through without any issue.
>
Are you using same SVN versions? What are you using for command line
binaries? Ideally, try the ones from CollabNet since that is what
Subclipse is using. Could be related to a specific version of SVN or
dependency.
> Also, you can see the jvm dump at this link https://db.tt/LBOXhJyi .
>
>
Just for the archives, pasting the relevent bits. Nothing jumps out at me
here to point in any direction though:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6508a7cf, pid=6324, tid=6692
#
# JRE version: Java(TM) SE Runtime Environment (7.0_55-b14) (build 1.7.0_55-b14)
# Java VM: Java HotSpot(TM) Client VM (24.55-b03 mixed mode, sharing
windows-x86 )
# Problematic frame:
# C [libsvn_wc-1.dll+0x4a7cf]
#
# Failed to write core dump. Minidumps are not enabled by default on
client versions of Windows
Stack: [0x05880000,0x05980000], sp=0x0597eaac, free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libsvn_wc-1.dll+0x4a7cf]
C [libsvn_ra-1.dll+0x496b7]
C [libsvn_ra-1.dll+0x4470b]
C [libsvn_ra-1.dll+0x44abe]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.apache.subversion.javahl.SVNClient.checkout(Ljava/lang/String;Ljava/lang/String;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Revision;Lorg/apache/subversion/javahl/types/Depth;ZZ)J+0
j org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.checkout(Lorg/tigris/subversion/svnclientadapter/SVNUrl;Ljava/io/File;Lorg/tigris/subversion/svnclientadapter/SVNRevision;IZZ)V+147
j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.checkoutProject(Lorg/eclipse/core/runtime/IProgressMonitor;Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;Lorg/tigris/subversion/svnclientadapter/ISVNClientAdapter;Ljava/io/File;)V+79
j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.basicRun(Lorg/eclipse/core/resources/IProject;Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;Lorg/eclipse/core/runtime/IProgressMonitor;)V+273
j org.tigris.subversion.subclipse.core.commands.CheckoutCommand$1.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+13
j org.tigris.subversion.subclipse.core.SVNProviderPlugin$6.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+10
j org.eclipse.core.internal.resources.Workspace.run(Lorg/eclipse/core/resources/IWorkspaceRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;ILorg/eclipse/core/runtime/IProgressMonitor;)V+80
j org.tigris.subversion.subclipse.core.SVNProviderPlugin.run(Lorg/tigris/subversion/subclipse/core/ISVNRunnable;Lorg/eclipse/core/runtime/jobs/ISchedulingRule;Lorg/eclipse/core/runtime/IProgressMonitor;)V+20
j org.tigris.subversion.subclipse.core.commands.CheckoutCommand.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+41
j org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute([Lorg/tigris/subversion/subclipse/core/ISVNRemoteFolder;[Lorg/eclipse/core/resources/IProject;Lorg/eclipse/core/runtime/IProgressMonitor;)Z+81
j org.tigris.subversion.subclipse.ui.operations.CheckoutAsProjectOperation.execute(Lorg/eclipse/core/runtime/IProgressMonitor;)V+94
j org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(Lorg/eclipse/core/runtime/IProgressMonitor;)V+35
j org.eclipse.team.internal.ui.actions.JobRunnableContext.run(Lorg/eclipse/jface/operation/IRunnableWithProgress;Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+2
j org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+9
j org.eclipse.core.internal.resources.InternalWorkspaceJob.run(Lorg/eclipse/core/runtime/IProgressMonitor;)Lorg/eclipse/core/runtime/IStatus;+37
j org.eclipse.core.internal.jobs.Worker.run()V+23
v ~StubRoutines::call_stub
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Darly Senecal Baptiste <ds...@gmail.com>.
To be clear and to double confirm
Recreated the same svn checkout command through command line and
TortoiseSVN, checkouts went through without any issue. Also, you can see
the jvm dump at this link https://db.tt/LBOXhJyi .
Regards
On Mon, Jun 30, 2014 at 2:26 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, Jun 30, 2014 at 1:00 PM, Darly Senecal Baptiste <
> dsenecalb@gmail.com> wrote:
>
>> Looking at the network trace packet wireshark PoV, looks like that the
>> server tried to send data to the client (javahl), but saw that client's
>> data buffer window is full (like ZeroWindow packet) and client is sending a
>> zero window to the server. And finally, the client is sending a series of
>> RESET packets to server. And these RST packets appears when javaHL crashed
>>
>>
> If JVM is crashing it should be producing a dump. Find it and send it.
>
> Also, as I mentioned earlier, you should see if you can recreate the crash
> using the command line. This might be produce a cleaner crash dump to look
> at. Since it is happening during checkout, you ought to be able to just
> execute the same checkout command. You could also try recreating it with
> TortoiseSVN. They have an automated system to produce and collect the
> crash dumps built-in.
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Jun 30, 2014 at 1:00 PM, Darly Senecal Baptiste <dsenecalb@gmail.com
> wrote:
> Looking at the network trace packet wireshark PoV, looks like that the
> server tried to send data to the client (javahl), but saw that client's
> data buffer window is full (like ZeroWindow packet) and client is sending a
> zero window to the server. And finally, the client is sending a series of
> RESET packets to server. And these RST packets appears when javaHL crashed
>
>
If JVM is crashing it should be producing a dump. Find it and send it.
Also, as I mentioned earlier, you should see if you can recreate the crash
using the command line. This might be produce a cleaner crash dump to look
at. Since it is happening during checkout, you ought to be able to just
execute the same checkout command. You could also try recreating it with
TortoiseSVN. They have an automated system to produce and collect the
crash dumps built-in.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Darly Senecal Baptiste <ds...@gmail.com>.
Looking at the network trace packet wireshark PoV, looks like that the
server tried to send data to the client (javahl), but saw that client's
data buffer window is full (like ZeroWindow packet) and client is sending a
zero window to the server. And finally, the client is sending a series of
RESET packets to server. And these RST packets appears when javaHL crashed
Any thoughts?
Regards
On Thu, Jun 26, 2014 at 2:59 PM, Darly Senecal Baptiste <dsenecalb@gmail.com
> wrote:
> Reviewing some information about JavaHL, isn't it because of the serf http
> library?
>
> Regards
>
>
> On Thu, Jun 26, 2014 at 12:22 PM, Darly Senecal Baptiste <
> dsenecalb@gmail.com> wrote:
>
>> Hi Community:
>>
>> I updated subclipse plugin to the latest version (1.10.5) with JavaHL as
>> its default subversion client adapter.
>>
>> I checked out code from a small repository (completely) and everything
>> went well. However, while I was trying to check out part of code from a
>> large repository, eclipse crashes unexpectedly. I don't know why
>>
>> I changed the client adapter from JavaHL to SVNKit(JavaSVN) and all
>> checkouts went well without crashing eclipse.
>>
>> I was trying to look the reasons of the crash but the eclipse log doesn't
>> provide the reasons of crashing.
>>
>> Is there a way to look for reasons of eclipse being crashed? Please let
>> me know.
>>
>> In addition I looked at the server logs the following error at the moment
>> of the incident
>>
>> [Thu Jun 26 10:55:26.087485 2014] [dav:error] [pid 25691] [client
>> 10.20.71.52:53404] Unable to deliver content. [500, #0]
>> [Thu Jun 26 10:55:26.087525 2014] [dav:error] [pid 25691] [client
>> 10.20.71.52:53404] Could not write data to filter. [500, #175002]
>> [Thu Jun 26 10:55:26.087532 2014] [dav:error] [pid 25028] [client
>> 10.20.71.52:53405] Unable to deliver content. [500, #0]
>> [Thu Jun 26 10:55:26.087559 2014] [dav:error] [pid 25028] [client
>> 10.20.71.52:53405] Could not write data to filter. [500, #175002]
>> [Thu Jun 26 10:55:26.087842 2014] [dav:error] [pid 25693] [client
>> 10.20.71.52:53399] Provider encountered an error while streaming a
>> REPORT response. [500, #0]
>> [Thu Jun 26 10:55:26.087876 2014] [dav:error] [pid 25693] [client
>> 10.20.71.52:53399] A failure occurred while driving the update report
>> editor [500, #104]
>>
>>
>>
>> Regards
>>
>
>
Re: SVN JavaHL 1.10.5 makes Eclipse to crash
Posted by Darly Senecal Baptiste <ds...@gmail.com>.
Reviewing some information about JavaHL, isn't it because of the serf http
library?
Regards
On Thu, Jun 26, 2014 at 12:22 PM, Darly Senecal Baptiste <
dsenecalb@gmail.com> wrote:
> Hi Community:
>
> I updated subclipse plugin to the latest version (1.10.5) with JavaHL as
> its default subversion client adapter.
>
> I checked out code from a small repository (completely) and everything
> went well. However, while I was trying to check out part of code from a
> large repository, eclipse crashes unexpectedly. I don't know why
>
> I changed the client adapter from JavaHL to SVNKit(JavaSVN) and all
> checkouts went well without crashing eclipse.
>
> I was trying to look the reasons of the crash but the eclipse log doesn't
> provide the reasons of crashing.
>
> Is there a way to look for reasons of eclipse being crashed? Please let me
> know.
>
> In addition I looked at the server logs the following error at the moment
> of the incident
>
> [Thu Jun 26 10:55:26.087485 2014] [dav:error] [pid 25691] [client
> 10.20.71.52:53404] Unable to deliver content. [500, #0]
> [Thu Jun 26 10:55:26.087525 2014] [dav:error] [pid 25691] [client
> 10.20.71.52:53404] Could not write data to filter. [500, #175002]
> [Thu Jun 26 10:55:26.087532 2014] [dav:error] [pid 25028] [client
> 10.20.71.52:53405] Unable to deliver content. [500, #0]
> [Thu Jun 26 10:55:26.087559 2014] [dav:error] [pid 25028] [client
> 10.20.71.52:53405] Could not write data to filter. [500, #175002]
> [Thu Jun 26 10:55:26.087842 2014] [dav:error] [pid 25693] [client
> 10.20.71.52:53399] Provider encountered an error while streaming a REPORT
> response. [500, #0]
> [Thu Jun 26 10:55:26.087876 2014] [dav:error] [pid 25693] [client
> 10.20.71.52:53399] A failure occurred while driving the update report
> editor [500, #104]
>
>
>
> Regards
>