Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Branko Čibej 
On 25.06.2014 14:43, Philip Martin wrote:
 Philip Martin philip.mar...@wandisco.com writes:

 I'm getting a SEGV in the JVM and it varies from run to run, two
 examples at the end.  I tried r1603298 and r1603297 and those also SEGV.
 Looks like I made a mistake when building the older versions.  I am now
 seeing the SEGV with r1603306 but not with r1603305 or earlier versions.

Can you please send the JVM stack trace file, too? Thanks.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Branko Čibej 
On 25.06.2014 14:45, Philip Martin wrote:
 Philip Martin philip.mar...@wandisco.com writes:

 Philip Martin philip.mar...@wandisco.com writes:

 I'm getting a SEGV in the JVM and it varies from run to run, two
 examples at the end.  I tried r1603298 and r1603297 and those also SEGV.
 Looks like I made a mistake when building the older versions.  I am now
 seeing the SEGV with r1603306 but not with r1603305 or earlier versions.
 Adding -Xcheck:jni to the java invocation gives:

 /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Xcheck:jni -Xbatch 
 -Dtest.rootdir=/home/pm/sw/subversion/obj/subversion/bindings/javahl/test-work
  -Dtest.srcdir=/home/pm/sw/subversion/obj/../src/subversion/bindings/javahl 
 -Dtest.rooturl= -Dtest.fstype= 
 -Djava.library.path=subversion/bindings/javahl/native/.libs:/usr/local/subversionx/lib
  -classpath 
 subversion/bindings/javahl/classes:/home/pm/sw/subversion/obj/../src/subversion/bindings/javahl/src:/usr/share/java/junit4.jar
  -Dtest.tests= org.apache.subversion.javahl.RunTests
 .
 .FATAL ERROR in native method: Using JNIEnv in the wrong thread
   at org.apache.subversion.javahl.util.ResponseChannel.nativeWrite(Native 
 Method)
   at 
 org.apache.subversion.javahl.util.ResponseChannel.write(ResponseChannel.java:48)
   at 
 org.apache.subversion.javahl.BasicTests$Tunnel.run(BasicTests.java:4004)
 Aborted

This particular case should be fixed by r1605718. I'm looking at other
possible culprits now.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Philip Martin 
Branko Čibej br...@wandisco.com writes:

 On 25.06.2014 14:43, Philip Martin wrote:
 Philip Martin philip.mar...@wandisco.com writes:

 I'm getting a SEGV in the JVM and it varies from run to run, two
 examples at the end.  I tried r1603298 and r1603297 and those also SEGV.
 Looks like I made a mistake when building the older versions.  I am now
 seeing the SEGV with r1603306 but not with r1603305 or earlier versions.

 Can you please send the JVM stack trace file, too? Thanks.

I don't think it is much use as the exact crash varies from run to run.
It happens after different numbers of dots in the test output and the
stack trace varies.  Some examples:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77fd7700 (LWP 20342)]
0x76a1524a in JavaCallWrapper::JavaCallWrapper(methodHandle, Handle, 
JavaValue*, Thread*) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
(gdb) bt
#0  0x76a1524a in JavaCallWrapper::JavaCallWrapper(methodHandle, 
Handle, JavaValue*, Thread*) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#1  0x76a163d5 in JavaCalls::call_helper(JavaValue*, methodHandle*, 
JavaCallArguments*, Thread*) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#2  0x76a15f95 in JavaCalls::call(JavaValue*, methodHandle, 
JavaCallArguments*, Thread*) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#3  0x76a2b4bb in jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, 
JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#4  0x76a3010d in jni_CallObjectMethod ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#5  0x7568c931 in JNU_GetStringPlatformChars ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/libjava.so
#6  0x756921a8 in Java_java_io_UnixFileSystem_createDirectory ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/libjava.so
#7  0x72480cd8 in ?? ()
#8  0x in ?? ()

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77fd7700 (LWP 20359)]
0x724dfb55 in ?? ()
(gdb) bt
#0  0x724dfb55 in ?? ()
#1  0x7fffd8084740 in ?? ()
#2  0x0025 in ?? ()
#3  0x77fd4348 in ?? ()
#4  0x7248ba03 in ?? ()
#5  0x72473310 in ?? ()
#6  0x in ?? ()

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77fd7700 (LWP 20401)]
0x76a351aa in 
ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
(gdb) bt
#0  0x76a351aa in 
ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#1  0x76d2aec0 in Unsafe_CompareAndSwapInt ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#2  0x72480cd8 in ?? ()
#3  0x in ?? ()

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Branko Čibej 
On 26.06.2014 12:22, Philip Martin wrote:
 Philip Martin philip.mar...@wandisco.com writes:

 Can you please send the JVM stack trace file, too? Thanks.
 I don't think it is much use as the exact crash varies from run to run.
 It happens after different numbers of dots in the test output and the
 stack trace varies.  Some examples:
 Here is an Java log file from one crash:


Thanks, this is extremely helpful.

Results from valgrind or a debugger are pretty much useless because
there appear to be cases where the JVM /expects/ segfaults to happen,
and handles them itself ... but valgrind doesn't know enough to ignore
them. Since they happen in different threads, the timing is not predictable.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Philip Martin 
Branko Čibej br...@wandisco.com writes:

 Results from valgrind or a debugger are pretty much useless because
 there appear to be cases where the JVM /expects/ segfaults to happen,
 and handles them itself ... but valgrind doesn't know enough to ignore
 them. Since they happen in different threads, the timing is not predictable.

Right, so when gdb catches a SEGV it is possible to continue execution
and further SEGVs are caught.  Playing with this a bit it appears that
the SEGV that matters is this one:

Program received signal SIGSEGV, Segmentation fault.
0x7fffe6529de8 in find_entry (ht=0x7fffd8060c60, key=0x7fffe69a00a8, 
klen=-1, val=0x0) at tables/apr_hash.c:271
271 hash = ht-hash_func(key, klen);
(gdb) bt
#0  0x7fffe6529de8 in find_entry (ht=0x7fffd8060c60, key=0x7fffe69a00a8, 
klen=-1, val=0x0) at tables/apr_hash.c:271
#1  0x7fffe652a14f in apr_hash_get (ht=0x7fffd8060c60, key=0x7fffe69a00a8, 
klen=-1) at tables/apr_hash.c:344
#2  0x7fffe698b610 in (anonymous namespace)::build_credential (env=..., 
cred=0x7fffd8060c60, cred_kind=0x7fffd80652c0 svn.username, 
realm=0x7fffd80652e0 https://svn.example.com:443;, 
scratch_pool=0x7fffd8068550)
at 
../src/subversion/bindings/javahl/native/org_apache_subversion_javahl_util_ConfigLib.cpp:102
#3  0x7fffe698c138 in 
Java_org_apache_subversion_javahl_util_ConfigLib_nativeGetCredential 
(jenv=0x60d9d8, jthis=0x77fd5c70, 
jconfig_dir=0x77fd5c68, jcred_kind=0x77fd5c60, 
jrealm=0x77fd5c58)
at 
../src/subversion/bindings/javahl/native/org_apache_subversion_javahl_util_ConfigLib.cpp:297
#4  0x72480cd8 in ?? ()
#5  0x0060e438 in ?? ()
#6  0x0060e438 in ?? ()
#7  0x0060e468 in ?? ()
#8  0x0060e468 in ?? ()
#9  0x7ffe in ?? ()
#10 0x77fd5bf8 in ?? ()
#11 0x0006ff6e7cc8 in ?? ()
#12 0x77fd5c70 in ?? ()
#13 0x0006ff6e8270 in ?? ()
#14 0x in ?? ()

(gdb) p ht
$1 = (apr_hash_t *) 0x7fffd8060c60
(gdb) p ht[0]
$2 = {pool = 0x7fffd8006470, array = 0x4141414141414141, iterator = {
ht = 0x4141414141414141, this = 0x4141414141414141, 
next = 0x4141414141414141, index = 1094795585}, count = 1094795585, 
  max = 1094795585, seed = 1094795585, hash_func = 0x4141414141414141, 
  free = 0x4141414141414141}

(gdb) up 3
#3  0x7fffe698c138 in 
Java_org_apache_subversion_javahl_util_ConfigLib_nativeGetCredential 
(jenv=0x60d9d8, jthis=0x77fd5c70, 
jconfig_dir=0x77fd5c68, jcred_kind=0x77fd5c60, 
jrealm=0x77fd5c58)
at 
../src/subversion/bindings/javahl/native/org_apache_subversion_javahl_util_ConfigLib.cpp:297
297   pool.getPool());
(gdb) p cb
$6 = {(anonymous namespace)::WalkCredentialsCallback = {
_vptr.WalkCredentialsCallback = 0x7fffe69bb650}, 
  m_cred_kind = 0x7fffd80652c0 svn.username, 
  m_realm = 0x7fffd80652e0 https://svn.example.com:443;, 
  m_delete_when_found = false, m_cred = 0x7fffd8060c60}


-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Branko Čibej 
On 26.06.2014 13:04, Philip Martin wrote:
 Branko Čibej br...@wandisco.com writes:

 Results from valgrind or a debugger are pretty much useless because
 there appear to be cases where the JVM /expects/ segfaults to happen,
 and handles them itself ... but valgrind doesn't know enough to ignore
 them. Since they happen in different threads, the timing is not predictable.
 Right, so when gdb catches a SEGV it is possible to continue execution
 and further SEGVs are caught.  Playing with this a bit it appears that
 the SEGV that matters is this one:

Yup, I've been looking at exactly this spot and I suspect that I need to
make a copy of the hash table into the correct pool.

-- Brane


 Program received signal SIGSEGV, Segmentation fault.
 0x7fffe6529de8 in find_entry (ht=0x7fffd8060c60, key=0x7fffe69a00a8, 
 klen=-1, val=0x0) at tables/apr_hash.c:271
 271   hash = ht-hash_func(key, klen);
 (gdb) bt
 #0  0x7fffe6529de8 in find_entry (ht=0x7fffd8060c60, key=0x7fffe69a00a8, 
 klen=-1, val=0x0) at tables/apr_hash.c:271
 #1  0x7fffe652a14f in apr_hash_get (ht=0x7fffd8060c60, 
 key=0x7fffe69a00a8, 
 klen=-1) at tables/apr_hash.c:344
 #2  0x7fffe698b610 in (anonymous namespace)::build_credential (env=..., 
 cred=0x7fffd8060c60, cred_kind=0x7fffd80652c0 svn.username, 
 realm=0x7fffd80652e0 https://svn.example.com:443;, 
 scratch_pool=0x7fffd8068550)
 at 
 ../src/subversion/bindings/javahl/native/org_apache_subversion_javahl_util_ConfigLib.cpp:102
 #3  0x7fffe698c138 in 
 Java_org_apache_subversion_javahl_util_ConfigLib_nativeGetCredential 
 (jenv=0x60d9d8, jthis=0x77fd5c70, 
 jconfig_dir=0x77fd5c68, jcred_kind=0x77fd5c60, 
 jrealm=0x77fd5c58)
 at 
 ../src/subversion/bindings/javahl/native/org_apache_subversion_javahl_util_ConfigLib.cpp:297
 #4  0x72480cd8 in ?? ()
 #5  0x0060e438 in ?? ()
 #6  0x0060e438 in ?? ()
 #7  0x0060e468 in ?? ()
 #8  0x0060e468 in ?? ()
 #9  0x7ffe in ?? ()
 #10 0x77fd5bf8 in ?? ()
 #11 0x0006ff6e7cc8 in ?? ()
 #12 0x77fd5c70 in ?? ()
 #13 0x0006ff6e8270 in ?? ()
 #14 0x in ?? ()

 (gdb) p ht
 $1 = (apr_hash_t *) 0x7fffd8060c60
 (gdb) p ht[0]
 $2 = {pool = 0x7fffd8006470, array = 0x4141414141414141, iterator = {
 ht = 0x4141414141414141, this = 0x4141414141414141, 
 next = 0x4141414141414141, index = 1094795585}, count = 1094795585, 
   max = 1094795585, seed = 1094795585, hash_func = 0x4141414141414141, 
   free = 0x4141414141414141}

 (gdb) up 3
 #3  0x7fffe698c138 in 
 Java_org_apache_subversion_javahl_util_ConfigLib_nativeGetCredential 
 (jenv=0x60d9d8, jthis=0x77fd5c70, 
 jconfig_dir=0x77fd5c68, jcred_kind=0x77fd5c60, 
 jrealm=0x77fd5c58)
 at 
 ../src/subversion/bindings/javahl/native/org_apache_subversion_javahl_util_ConfigLib.cpp:297
 297 pool.getPool());
 (gdb) p cb
 $6 = {(anonymous namespace)::WalkCredentialsCallback = {
 _vptr.WalkCredentialsCallback = 0x7fffe69bb650}, 
   m_cred_kind = 0x7fffd80652c0 svn.username, 
   m_realm = 0x7fffd80652e0 https://svn.example.com:443;, 
   m_delete_when_found = false, m_cred = 0x7fffd8060c60}




-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Philip Martin 
Branko Čibej br...@wandisco.com writes:

 On 26.06.2014 13:04, Philip Martin wrote:

 Yup, I've been looking at exactly this spot and I suspect that I need to
 make a copy of the hash table into the correct pool.

 (gdb) p ht
 $1 = (apr_hash_t *) 0x7fffd8060c60
 (gdb) p ht[0]
 $2 = {pool = 0x7fffd8006470, array = 0x4141414141414141, iterator = {
 ht = 0x4141414141414141, this = 0x4141414141414141, 
 next = 0x4141414141414141, index = 1094795585}, count = 1094795585, 
   max = 1094795585, seed = 1094795585, hash_func = 0x4141414141414141, 
   free = 0x4141414141414141}

I have pool debugging enabled and 0x41 is the poison byte that is used
to overwrite memory before it is freed.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Branko Čibej 
On 26.06.2014 13:15, Philip Martin wrote:
 Branko Čibej br...@wandisco.com writes:

 On 26.06.2014 13:04, Philip Martin wrote:

 Yup, I've been looking at exactly this spot and I suspect that I need to
 make a copy of the hash table into the correct pool.
 (gdb) p ht
 $1 = (apr_hash_t *) 0x7fffd8060c60
 (gdb) p ht[0]
 $2 = {pool = 0x7fffd8006470, array = 0x4141414141414141, iterator = {
 ht = 0x4141414141414141, this = 0x4141414141414141, 
 next = 0x4141414141414141, index = 1094795585}, count = 1094795585, 
   max = 1094795585, seed = 1094795585, hash_func = 0x4141414141414141, 
   free = 0x4141414141414141}
 I have pool debugging enabled and 0x41 is the poison byte that is used
 to overwrite memory before it is freed.

Should be fixed in r1605739.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-26 Thread Philip Martin 
Branko Čibej br...@wandisco.com writes:

 Should be fixed in r1605739.

Yes, the tests now pass on my box.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-25 Thread Philip Martin 
Branko Čibej br...@wandisco.com writes:

 On 24.06.2014 21:48, Bert Huijben wrote:
  Hi,

 For some time the JavaHL tests on the svn-x64-ubuntu-gcc have been
 segfaulting.

 Looking at
 http://ci.apache.org/builders/svn-x64-ubuntu-gcc?numbuilds=200

 It appears this bot started failing after either 
 r1603298 or r1603299

 Other, similar bots don't produce the same segfault.

 Can somebody get more details of the bot to help diagnosing this problem?

 Can you post one of the JVM stack traces, please; the test output
 contains a path to the generated file. FWIW, I've seen reports of JavaHL
 segfaults but never been able to reproduce them, this would be an ideal
 opportunity.

I'm getting a SEGV in the JVM and it varies from run to run, two
examples at the end.  I tried r1603298 and r1603297 and those also SEGV.
I also tried valgrind but there are a huge number of warnings related to
the JVM.  I spotted two valgrind warnings that might indicate a
Subversion problem (multiple occurrences of each) but these occur after
several hundred other warnings:

==26302== Invalid write of size 4
==26302==at 0x77A1F48: ???
==26302==by 0x77914E6: ???
==26302==by 0x5FAC4DD: JavaCalls::call_helper(JavaValue*, methodHandle*, Jav
aCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/se
rver/libjvm.so)
==26302==by 0x5FABF94: JavaCalls::call(JavaValue*, methodHandle, JavaCallArg
uments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/lib
jvm.so)
==26302==by 0x5FC14BA: jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*,
 JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) (in /usr/lib/jvm/java-7
-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==26302==by 0x5FC5CE5: jni_CallIntMethodV (in /usr/lib/jvm/java-7-openjdk-am
d64/jre/lib/amd64/server/libjvm.so)
==26302==by 0x17AF63A6: JNIEnv_::CallIntMethod(_jobject*, _jmethodID*, ...)
(jni.h:987)
==26302==by 0x17AF62B6: EnumMapper::getOrdinal(char const*, _jobject*) (Enum
Mapper.cpp:324)
==26302==by 0x17AF5EFC: EnumMapper::toDepth(_jobject*) (EnumMapper.cpp:219)
==26302==by 0x17B2841D: Java_org_apache_subversion_javahl_SVNClient_doImport
 (org_apache_subversion_javahl_SVNClient.cpp:826)
==26302==by 0x77A3CD7: ???
==26302==by 0x7797057: ???
==26302==  Address 0x414b3a8 is not stack'd, malloc'd or (recently) free'd


==26302== Invalid write of size 4
==26302==at 0x77A1BC5: ???
==26302==by 0x7797705: ???
==26302==by 0x77914E6: ???
==26302==by 0x5FAC4DD: JavaCalls::call_helper(JavaValue*, methodHandle*, Jav
aCallArguments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/se
rver/libjvm.so)
==26302==by 0x5FABF94: JavaCalls::call(JavaValue*, methodHandle, JavaCallArg
uments*, Thread*) (in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/lib
jvm.so)
==26302==by 0x5FC14BA: jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*,
 JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) (in /usr/lib/jvm/java-7
-openjdk-amd64/jre/lib/amd64/server/libjvm.so)
==26302==by 0x5FC5139: jni_CallVoidMethodV (in /usr/lib/jvm/java-7-openjdk-a
md64/jre/lib/amd64/server/libjvm.so)
==26302==by 0x17AE97B8: JNIEnv_::CallVoidMethod(_jobject*, _jmethodID*, ...)
 (jni.h:1054)
==26302==by 0x17AE9FBE: ClientContext::notify(void*, svn_wc_notify_t const*,
 apr_pool_t*) (ClientContext.cpp:196)
==26302==by 0x17BF1DA5: import_dir (import.c:573)
==26302==by 0x17BF1A39: import_children (import.c:458)
==26302==by 0x17BF2355: import (import.c:751)
==26302==  Address 0x414fd10 is not stack'd, malloc'd or (recently) free'd


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77fd7700 (LWP 1685)]
0x76a351aa in 
ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
(gdb) bt
#0  0x76a351aa in 
ThreadStateTransition::transition_from_native(JavaThread*, JavaThreadState) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#1  0x76d2aec0 in Unsafe_CompareAndSwapInt ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#2  0x72480cd8 in ?? ()
#3  0x77fd5f10 in ?? ()
#4  0x72474233 in ?? ()
#5  0x in ?? ()


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe6cc5700 (LWP 20525)]
0x7680e379 in ciEnv::get_field_by_index(ciInstanceKlass*, int) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
(gdb) bt
#0  0x7680e379 in ciEnv::get_field_by_index(ciInstanceKlass*, int) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#1  0x76829683 in ciBytecodeStream::get_field(bool) ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so
#2  0x76c16915 in Parse::do_field_access(bool, bool) ()
   from

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-25 Thread Philip Martin 
Philip Martin philip.mar...@wandisco.com writes:

 I'm getting a SEGV in the JVM and it varies from run to run, two
 examples at the end.  I tried r1603298 and r1603297 and those also SEGV.

Looks like I made a mistake when building the older versions.  I am now
seeing the SEGV with r1603306 but not with r1603305 or earlier versions.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-25 Thread Philip Martin 
Philip Martin philip.mar...@wandisco.com writes:

 Philip Martin philip.mar...@wandisco.com writes:

 I'm getting a SEGV in the JVM and it varies from run to run, two
 examples at the end.  I tried r1603298 and r1603297 and those also SEGV.

 Looks like I made a mistake when building the older versions.  I am now
 seeing the SEGV with r1603306 but not with r1603305 or earlier versions.

Adding -Xcheck:jni to the java invocation gives:

/usr/lib/jvm/java-7-openjdk-amd64/bin/java -Xcheck:jni -Xbatch 
-Dtest.rootdir=/home/pm/sw/subversion/obj/subversion/bindings/javahl/test-work
 -Dtest.srcdir=/home/pm/sw/subversion/obj/../src/subversion/bindings/javahl 
-Dtest.rooturl= -Dtest.fstype= 
-Djava.library.path=subversion/bindings/javahl/native/.libs:/usr/local/subversionx/lib
 -classpath 
subversion/bindings/javahl/classes:/home/pm/sw/subversion/obj/../src/subversion/bindings/javahl/src:/usr/share/java/junit4.jar
 -Dtest.tests= org.apache.subversion.javahl.RunTests
.
.FATAL ERROR in native method: Using JNIEnv in the wrong thread
at org.apache.subversion.javahl.util.ResponseChannel.nativeWrite(Native 
Method)
at 
org.apache.subversion.javahl.util.ResponseChannel.write(ResponseChannel.java:48)
at 
org.apache.subversion.javahl.BasicTests$Tunnel.run(BasicTests.java:4004)
Aborted

-- 
Philip

Re: JavaHL segfault on svn-x64-ubuntu-gcc buildbot

2014-06-24 Thread Branko Čibej 
On 24.06.2014 21:48, Bert Huijben wrote:
   Hi,

 For some time the JavaHL tests on the svn-x64-ubuntu-gcc have been
 segfaulting.

 Looking at
 http://ci.apache.org/builders/svn-x64-ubuntu-gcc?numbuilds=200

 It appears this bot started failing after either 
 r1603298 or r1603299

 Other, similar bots don't produce the same segfault.

 Can somebody get more details of the bot to help diagnosing this problem?

Can you post one of the JVM stack traces, please; the test output
contains a path to the generated file. FWIW, I've seen reports of JavaHL
segfaults but never been able to reproduce them, this would be an ideal
opportunity.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com