Change in symlink behavior

[Dean Yu]

Hi folks,
  I'm actually a Hudson user, so I inherit SVNKit through Hudson. Hudson recently upgraded SVNKit from 1.2.2 to 1.3.0. After this upgrade, revisioned symlinks went from being checked out as the referenced file, to being checked out as a file that contains the string "link" followed by the name of the referenced file or directory. I should point out that Hudson used to set -Dsvnkit.symlinks=false, which is what causes this behavior to happen.
  This was fixed in Hudson by removing that property. Unfortunately for us, that second change causes the JVM to crash with a segfault on FreeBSD[1]. I don't know if the true culprit is SVNKit, JNA, or Hudson's remoting code, but I thought I would start here.
  I'm not subscribed to this mailing list so please be sure to include me on any responses. Thanks.

  -- Dean

[1] Here's the stack trace from the generated hs_err file:

Stack: [0x01300000,0x01340000),  sp=0x0133f338,  free space=252k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc_r.so.4+0x77aaf]  strlcat+0x1b
C  [libc_r.so.4+0x9004e]  .cerror+0x6
C  [hudson-remoting9638.libjnidispatch.so+0xf91f]  ffi_call+0x8b
C  [hudson-remoting9638.libjnidispatch.so+0x33da]  +0xf1a
C  [hudson-remoting9638.libjnidispatch.so+0x3b92]  Java_com_sun_jna_Function_invokeInt+0x32
j  com.sun.jna.Function.invokeInt(I[Ljava/lang/Object;)I+0
j  com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/Class;Z)Ljava/lang/Object;+315
j  com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;+214
j  com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+341
j  org.tmatesoft.svn.core.internal.util.jna.$Proxy7.lstat(Ljava/lang/String;Lcom/sun/jna/Pointer;)I+20
j  org.tmatesoft.svn.core.internal.util.jna.SVNLinuxUtil.getFileType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+96
j  org.tmatesoft.svn.core.internal.util.jna.SVNJNAUtil.getFileType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+7
j  org.tmatesoft.svn.core.internal.wc.SVNFileType.getType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+41
j  org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(Lorg/tmatesoft/svn/core/SVNURL;Ljava/io/File;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/SVNDepth;Z)J+206
j  org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(Lorg/tmatesoft/svn/core/SVNURL;Ljava/io/File;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/wc/SVNRevision;Z)J+12
j  hudson.scm.SubversionSCM$CheckOutTask.invoke(Ljava/io/File;Lhudson/remoting/VirtualChannel;)Ljava/util/List;+570
j  hudson.scm.SubversionSCM$CheckOutTask.invoke(Ljava/io/File;Lhudson/remoting/VirtualChannel;)Ljava/lang/Object;+3
j  hudson.FilePath$FileCallableWrapper.call()Ljava/lang/Object;+21
j  hudson.remoting.UserRequest.perform(Lhudson/remoting/Channel;)Lhudson/remoting/UserResponse;+136
j  hudson.remoting.UserRequest.perform(Lhudson/remoting/Channel;)Ljava/io/Serializable;+2
j  hudson.remoting.Request$2.run()V+8
j  java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object;+4
j  java.util.concurrent.FutureTask$Sync.innerRun()V+22
j  java.util.concurrent.FutureTask.run()V+4
j  java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/Runnable;)V+44
j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
V  [libjvm.so+0x280618]
V  [libjvm.so+0x3aab48]
V  [libjvm.so+0x27fd5f]
V  [libjvm.so+0x2801f6]
V  [libjvm.so+0x28036e]
V  [libjvm.so+0x2e34ba]
V  [libjvm.so+0x41c110]
V  [libjvm.so+0x41c1d1]
V  [libjvm.so+0x3a7a09]
C  [libc_r.so.4+0x18648]  _thread_start+0x34

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  com.sun.jna.Function.invokeInt(I[Ljava/lang/Object;)I+0
j  com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/Class;Z)Ljava/lang/Object;+315
j  com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;+214
j  com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+341
j  org.tmatesoft.svn.core.internal.util.jna.$Proxy7.lstat(Ljava/lang/String;Lcom/sun/jna/Pointer;)I+20
j  org.tmatesoft.svn.core.internal.util.jna.SVNLinuxUtil.getFileType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+96
j  org.tmatesoft.svn.core.internal.util.jna.SVNJNAUtil.getFileType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+7
j  org.tmatesoft.svn.core.internal.wc.SVNFileType.getType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+41
j  org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(Lorg/tmatesoft/svn/core/SVNURL;Ljava/io/File;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/SVNDepth;Z)J+206
j  org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(Lorg/tmatesoft/svn/core/SVNURL;Ljava/io/File;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/wc/SVNRevision;Z)J+12
j  hudson.scm.SubversionSCM$CheckOutTask.invoke(Ljava/io/File;Lhudson/remoting/VirtualChannel;)Ljava/util/List;+570
j  hudson.scm.SubversionSCM$CheckOutTask.invoke(Ljava/io/File;Lhudson/remoting/VirtualChannel;)Ljava/lang/Object;+3
j  hudson.FilePath$FileCallableWrapper.call()Ljava/lang/Object;+21
j  hudson.remoting.UserRequest.perform(Lhudson/remoting/Channel;)Lhudson/remoting/UserResponse;+136
j  hudson.remoting.UserRequest.perform(Lhudson/remoting/Channel;)Ljava/io/Serializable;+2
j  hudson.remoting.Request$2.run()V+8
j  java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object;+4
j  java.util.concurrent.FutureTask$Sync.innerRun()V+22
j  java.util.concurrent.FutureTask.run()V+4
j  java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/Runnable;)V+44
j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub

[Alexander Kitaev-3]

Hello Dean,

Thank you for reporting this issue.

>   This was fixed in Hudson by removing that property. Unfortunately
for us,
> that second change causes the JVM to crash with a segfault on
FreeBSD[1]. I
> don't know if the true culprit is SVNKit, JNA, or Hudson's remoting code,
> but I thought I would start here.
Could you please provide some additional information:

1. What version of FreeBSD do you use (output of "uname -a" command)
2. Could you please try to use latest version of the JNA (3.2.2,
download at https://jna.dev.java.net/). Does the problem persist?
3. Do you experience this crash all the time or only occasionally?

I hope will manage to find the reason and fix this issue eventually, but
meanwhile you may disable JNA by removing jna.jar from Hudson classpath,
or set -Dsvnkit.symlinks=false back - probably this will help (though
I'm not sure, because JNA will be used anyway to get file type).

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!

Dean Yu wrote:

> Hi folks,
>   I'm actually a Hudson user, so I inherit SVNKit through Hudson. Hudson
> recently upgraded SVNKit from 1.2.2 to 1.3.0. After this upgrade, revisioned
> symlinks went from being checked out as the referenced file, to being
> checked out as a file that contains the string "link" followed by the name
> of the referenced file or directory. I should point out that Hudson used to
> set -Dsvnkit.symlinks=false, which is what causes this behavior to happen.
>   This was fixed in Hudson by removing that property. Unfortunately for us,
> that second change causes the JVM to crash with a segfault on FreeBSD[1]. I
> don't know if the true culprit is SVNKit, JNA, or Hudson's remoting code,
> but I thought I would start here.
>   I'm not subscribed to this mailing list so please be sure to include me on
> any responses. Thanks.
>
>   -- Dean
>
> [1] Here's the stack trace from the generated hs_err file:
>
> Stack: [0x01300000,0x01340000),  sp=0x0133f338,  free space=252k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> C  [libc_r.so.4+0x77aaf]  strlcat+0x1b
> C  [libc_r.so.4+0x9004e]  .cerror+0x6
> C  [hudson-remoting9638.libjnidispatch.so+0xf91f]  ffi_call+0x8b
> C  [hudson-remoting9638.libjnidispatch.so+0x33da]  +0xf1a
> C  [hudson-remoting9638.libjnidispatch.so+0x3b92]
> Java_com_sun_jna_Function_invokeInt+0x32
> j  com.sun.jna.Function.invokeInt(I[Ljava/lang/Object;)I+0
> j
> com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/Class;Z)Ljava/lang/Object;+315
> j
> com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;+214
> j
> com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+341
> j
> org.tmatesoft.svn.core.internal.util.jna.$Proxy7.lstat(Ljava/lang/String;Lcom/sun/jna/Pointer;)I+20
> j
> org.tmatesoft.svn.core.internal.util.jna.SVNLinuxUtil.getFileType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+96
> j
> org.tmatesoft.svn.core.internal.util.jna.SVNJNAUtil.getFileType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+7
> j
> org.tmatesoft.svn.core.internal.wc.SVNFileType.getType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+41
> j
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(Lorg/tmatesoft/svn/core/SVNURL;Ljava/io/File;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/SVNDepth;Z)J+206
> j
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(Lorg/tmatesoft/svn/core/SVNURL;Ljava/io/File;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/wc/SVNRevision;Z)J+12
> j
> hudson.scm.SubversionSCM$CheckOutTask.invoke(Ljava/io/File;Lhudson/remoting/VirtualChannel;)Ljava/util/List;+570
> j
> hudson.scm.SubversionSCM$CheckOutTask.invoke(Ljava/io/File;Lhudson/remoting/VirtualChannel;)Ljava/lang/Object;+3
> j  hudson.FilePath$FileCallableWrapper.call()Ljava/lang/Object;+21
> j
> hudson.remoting.UserRequest.perform(Lhudson/remoting/Channel;)Lhudson/remoting/UserResponse;+136
> j
> hudson.remoting.UserRequest.perform(Lhudson/remoting/Channel;)Ljava/io/Serializable;+2
> j  hudson.remoting.Request$2.run()V+8
> j  java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object;+4
> j  java.util.concurrent.FutureTask$Sync.innerRun()V+22
> j  java.util.concurrent.FutureTask.run()V+4
> j
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/Runnable;)V+44
> j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
> j  java.lang.Thread.run()V+11
> v  ~StubRoutines::call_stub
> V  [libjvm.so+0x280618]
> V  [libjvm.so+0x3aab48]
> V  [libjvm.so+0x27fd5f]
> V  [libjvm.so+0x2801f6]
> V  [libjvm.so+0x28036e]
> V  [libjvm.so+0x2e34ba]
> V  [libjvm.so+0x41c110]
> V  [libjvm.so+0x41c1d1]
> V  [libjvm.so+0x3a7a09]
> C  [libc_r.so.4+0x18648]  _thread_start+0x34
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  com.sun.jna.Function.invokeInt(I[Ljava/lang/Object;)I+0
> j
> com.sun.jna.Function.invoke([Ljava/lang/Object;Ljava/lang/Class;Z)Ljava/lang/Object;+315
> j
> com.sun.jna.Function.invoke(Ljava/lang/Class;[Ljava/lang/Object;Ljava/util/Map;)Ljava/lang/Object;+214
> j
> com.sun.jna.Library$Handler.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object;+341
> j
> org.tmatesoft.svn.core.internal.util.jna.$Proxy7.lstat(Ljava/lang/String;Lcom/sun/jna/Pointer;)I+20
> j
> org.tmatesoft.svn.core.internal.util.jna.SVNLinuxUtil.getFileType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+96
> j
> org.tmatesoft.svn.core.internal.util.jna.SVNJNAUtil.getFileType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+7
> j
> org.tmatesoft.svn.core.internal.wc.SVNFileType.getType(Ljava/io/File;)Lorg/tmatesoft/svn/core/internal/wc/SVNFileType;+41
> j
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(Lorg/tmatesoft/svn/core/SVNURL;Ljava/io/File;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/SVNDepth;Z)J+206
> j
> org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(Lorg/tmatesoft/svn/core/SVNURL;Ljava/io/File;Lorg/tmatesoft/svn/core/wc/SVNRevision;Lorg/tmatesoft/svn/core/wc/SVNRevision;Z)J+12
> j
> hudson.scm.SubversionSCM$CheckOutTask.invoke(Ljava/io/File;Lhudson/remoting/VirtualChannel;)Ljava/util/List;+570
> j
> hudson.scm.SubversionSCM$CheckOutTask.invoke(Ljava/io/File;Lhudson/remoting/VirtualChannel;)Ljava/lang/Object;+3
> j  hudson.FilePath$FileCallableWrapper.call()Ljava/lang/Object;+21
> j
> hudson.remoting.UserRequest.perform(Lhudson/remoting/Channel;)Lhudson/remoting/UserResponse;+136
> j
> hudson.remoting.UserRequest.perform(Lhudson/remoting/Channel;)Ljava/io/Serializable;+2
> j  hudson.remoting.Request$2.run()V+8
> j  java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object;+4
> j  java.util.concurrent.FutureTask$Sync.innerRun()V+22
> j  java.util.concurrent.FutureTask.run()V+4
> j
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Ljava/lang/Runnable;)V+44
> j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+28
> j  java.lang.Thread.run()V+11
> v  ~StubRoutines::call_stub
>

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Dean Yu]

Alexander Kitaev-3 wrote:

Hello Dean,

Thank you for reporting this issue.

>   This was fixed in Hudson by removing that property. Unfortunately
for us,
> that second change causes the JVM to crash with a segfault on
FreeBSD[1]. I
> don't know if the true culprit is SVNKit, JNA, or Hudson's remoting code,
> but I thought I would start here.
Could you please provide some additional information:

1. What version of FreeBSD do you use (output of "uname -a" command)
2. Could you please try to use latest version of the JNA (3.2.2,
download at https://jna.dev.java.net/). Does the problem persist?
3. Do you experience this crash all the time or only occasionally?

I hope will manage to find the reason and fix this issue eventually, but
meanwhile you may disable JNA by removing jna.jar from Hudson classpath,
or set -Dsvnkit.symlinks=false back - probably this will help (though
I'm not sure, because JNA will be used anyway to get file type).

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!

Hi Alexander,
  Thanks for responding. Here is the information you've requested:

1. This happens on a variety of versions of FreeBSD: 4.10 and 4.11, on i386 processors. We build OS images internally, so I don't know if the exact uname -a output would be useful to you.
2. I've tried JNA 3.2.2 and the problem still exists.
3. This happens all the time, on every FreeBSD machine I've tried, and the repository URL doesn't matter.

Unfortunately, I can't remove JNA because Hudson uses it for other purposes. Is there another way to disable it just from SVNKit? Also, as I mentioned, the behavior of -Dsvnskit.symlinks=false changed between SVNKit 1.2.2 and SVNKit 1.3. In the old version, svmlinks were getting checked out as the files the links reference. In the newer version, symlinks get checked out as files that contain the name of the referenced file. So builds that used to work with SVNKit 1.2.2 no longer work.

  -- Dean

[Alexander Kitaev-3]

Hello,

> Unfortunately, I can't remove JNA because Hudson uses it for other
purposes.
> Is there another way to disable it just from SVNKit? Also, as I mentioned,
> the behavior of -Dsvnskit.symlinks=false changed between SVNKit 1.2.2 and
> SVNKit 1.3. In the old version, svmlinks were getting checked out as the
> files the links reference. In the newer version, symlinks get checked
out as
> files that contain the name of the referenced file. So builds that used to
> work with SVNKit 1.2.2 no longer work.
With SVNKit 1.3 you may use the following system property to disable JNA
usage while JNA library is still on classpath:

-Dsvnkit.useJNA=false

Wouldn't you mind if I send you a test program to run on your FreeBSD
box - this will help to figure out exact reason of the problem.

Thanks,
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!

Dean Yu wrote:

>
>
> Alexander Kitaev-3 wrote:
>> Hello Dean,
>>
>> Thank you for reporting this issue.
>>
>>>   This was fixed in Hudson by removing that property. Unfortunately
>> for us,
>>> that second change causes the JVM to crash with a segfault on
>> FreeBSD[1]. I
>>> don't know if the true culprit is SVNKit, JNA, or Hudson's remoting code,
>>> but I thought I would start here.
>> Could you please provide some additional information:
>>
>> 1. What version of FreeBSD do you use (output of "uname -a" command)
>> 2. Could you please try to use latest version of the JNA (3.2.2,
>> download at https://jna.dev.java.net/). Does the problem persist?
>> 3. Do you experience this crash all the time or only occasionally?
>>
>> I hope will manage to find the reason and fix this issue eventually, but
>> meanwhile you may disable JNA by removing jna.jar from Hudson classpath,
>> or set -Dsvnkit.symlinks=false back - probably this will help (though
>> I'm not sure, because JNA will be used anyway to get file type).
>>
>> Alexander Kitaev,
>> TMate Software,
>> http://svnkit.com/ - Java [Sub]Versioning Library!
>> http://sqljet.com/ - Java SQLite Library!
>>
>
> Hi Alexander,
>   Thanks for responding. Here is the information you've requested:
>
> 1. This happens on a variety of versions of FreeBSD: 4.10 and 4.11, on i386
> processors. We build OS images internally, so I don't know if the exact
> uname -a output would be useful to you.
> 2. I've tried JNA 3.2.2 and the problem still exists.
> 3. This happens all the time, on every FreeBSD machine I've tried, and the
> repository URL doesn't matter.
>
> Unfortunately, I can't remove JNA because Hudson uses it for other purposes.
> Is there another way to disable it just from SVNKit? Also, as I mentioned,
> the behavior of -Dsvnskit.symlinks=false changed between SVNKit 1.2.2 and
> SVNKit 1.3. In the old version, svmlinks were getting checked out as the
> files the links reference. In the newer version, symlinks get checked out as
> files that contain the name of the referenced file. So builds that used to
> work with SVNKit 1.2.2 no longer work.
>
>   -- Dean
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...

[Dean Yu]

Alexander Kitaev-3 wrote:

With SVNKit 1.3 you may use the following system property to disable JNA
usage while JNA library is still on classpath:

-Dsvnkit.useJNA=false

This gets me around the immediate problem.

  -- Dean