On 24.11.2021 15:07, James McCoy wrote:
The comment says IOException, but this is InterruptedException. Is that
intentional?
Catching InterruptedException is simply to be able to call
'tunnelAgent.join()'. The comment is correct. The difference between
'tunnelAgent.join()' and 'tunnelAgent.
Indeed there was a race condition where TunnelAgent could begin writing
at the same time when pipe is being closed. This resulted in an
unexpected IOException, which was detected by the test.
This is purely a test issue and should not be a problem for real
applications.
Unfortunately it's ha
Thanks!
I tinkered with it a bit to be able to run multiple loops in parallel
(it requires changing '-Dtest.rootdir' to unique absolute dir in each
parallel run).
When running 8 loops at once, with just the guilty test, I can reproduce
the problem within ~10 secs.
Going to investigate tomo
On 22.11.2021 3:35, James McCoy wrote:
Yes, I just hit it as composing this email, although I hadn't in an
earlier 100x loop of the JavaHL suite.
Could you please give more information? :)
Did you reproduce on x86-64?
Were you running the entire suite?
Did you run it from a loop?
Any ideas the
On 11.10.2021 0:17, Daniel Sahlberg wrote:
Thanks Alexandr for your patches (this and the other mail). I was
planning on reviewing them during the weekend but I got stuck with other
build issues. I have them on my todo list and I will try to get back to
them as soon as I can. Please bump me if
OK, thanks!
On 11.10.2021 0:17, Daniel Sahlberg wrote:
Thanks Alexandr for your patches (this and the other mail). I was
planning on reviewing them during the weekend but I got stuck with other
build issues. I have them on my todo list and I will try to get back to
them as soon as I can. Pleas
This patch fixes a few errors that prevented Windows build in paths with
spaces.
[[
On Windows: fix build in paths with spaces
* build/generator/gen_win.py
Quote what needs to be quoted
]]
Index: build/generator/gen_win.py
===
--
When I'm building SVN, I like to make/install all dependencies and then
use these "installed" folders to build svn. Unfortunately SVN doesn't
recognize installed layout for SASL dependency. Let's fix that.
[[
On Windows: support install layout of sasl
Source layout of sasl has include headers
On 17.08.2021 6:45, Daniel Shahaf wrote:
Could you file an issue?
I decided to study it a bit more and found more problems, see the
newer mail I sent today. For the reasons described there, I decided
to abandon the patch: it only fixes half of the problem. While it's
already something, I'm out
At least on Linux, SVN build scripts handle custom-prefix dependencies
--with-serf and --with-zlib incorrectly.
For example, for --with-serf, the following happens
1) serf.pc is found at provided prefix, which gives:
-lserf-1 -L/path/to/serf/prefix
2) This is given to libtool, which is the co
On 14.08.2021 15:13, Daniel Shahaf wrote:
>> Currently, serf has a very specific form of .pc file, hardcoded in
its repo
>> [1].
> That's an implementation detail and may change in a future release.
> Don't rely on it.
>> This only has a single -L.
> You shouldn't rely on this either, if possib
On 31.07.2021 2:44, Daniel Shahaf wrote:
+SVN_SERF_LIBS=["$SVN_SERF_LIBS `$PKG_CONFIG $serf_pc_arg --libs-only-L
| $SED -e 's/^-L/-R/g'`"]
I'm sceptical about the regex. For all I know, there may be multiple -L
options and there may be leading spaces before the first one.
More i
I have tested on Ubuntu 20.04 (on x86-64 arch):
* Ran entire JavaHL test package 130 times
(using a loop in shell script).
Not a single error; tests succeed every single time.
* Ran just the reported test 1000 times; again no errors.
The test is
'org.apache.subversion.javahl.BasicTests.te
For two days, I struggled to build SVN on my Ubuntu 20.04 with external
serf. Finally I managed [1], tomorrow I'll try to reproduce the problem
in tests.
[1]
It seems that the problem has been there for years, see for example:
https://stackoverflow.com/questions/28663316
https://groups.google.com/g/subversion_users/c/CkbGGwFi6-0
I'm a committer in SVN, but I'm not very experienced with Linux and would
rather have this patch reviewed, thanks!
[[[
On 23.07.2021 2:41, Daniel Sahlberg wrote:
> A kind reminder to check if we ever got to the bottom of this?
Yes, sorry! I consulted my TODO list and found that my boss "kindly"
moved it to position #9 We agreed that I will fix it next thing, I
would expect somewhere on Monday next week.
Going to take longer, sorry. I'm bombarded with things to take care
of... While trying to have vacation, huh. Again, of the flaky test
stands in the way, I wouldn't mind of you just comment it out for now.
On 16.02.2021 15:27, James McCoy wrote:
> Looks like it's more of a timing issue than something architecture
> specific. The failure has also occurred on i386 and retries have since
> succeeded on mipsel, and my manual tests on mips64el have sporadically
> succeeded.
I can try to have a look to
On 29.01.2021 21:47, Johan Corveleyn wrote:
Looks good! Looks like everything is good to go now for your javahl
fixes in 1.14.1 :-).
Just to clarify: backports to bindings require only 2 votes (in fact
even only one +1, and one +0 or "concept +1"). Backports to core code
require 3 votes (or for
On 29.01.2021 20:51, Johan Corveleyn wrote:
Fingers crossed for a second vote in STATUS now :-).
Did that, hopefully I didn't mess anything up, it's my first experience
with it :)
On 27.01.2021 13:00, Johan Corveleyn wrote:
^^ some lines indented with tabs instead of spaces
^^ curly brace should be on next line
^^ The comment above, describing how the JVM crashes, refers to the
situation before you actually fixed that :-). Can you rephrase it a
bit, so it is still a
On 27.01.2021 22:56, Johan Corveleyn wrote:
Thanks for explaining. Hm, maybe it would be good to note this in some
form in the commit message, yes. Just to make sure others scrolling
through this in the future are not puzzled by it. Something like:
"While here, remove the early exit on null jclo
On 27.01.2021 23:04, Johan Corveleyn wrote:
BTW, if you would subscribe to comm...@subversion.apache.org (by
sending a mail to commits-subscribe@s.a.o), you would see the
log-message-changes (and all commits) from that side too. Not required
of course, but I use it as a means to follow along a b
On 27.01.2021 11:34, Johan Corveleyn wrote:
+ jobject jrequest;
+ jobject jresponse;
These new fields are not mentioned in the log message.
@@ -523,7 +527,10 @@ jobject create_Channel(const char *class
jmethodID ctor = env->GetMethodID(cls, "", "(J)V");
^^ also not mentioned in log me
On 27.01.2021 11:13, Johan Corveleyn wrote:
+void
+OperationContext::closeTunnel(void *tunnel_context, void *)
+{
+ TunnelContext* tc = static_cast(tunnel_context);
+ jobject jclosecb = tc->jclosecb;
+ delete tc;
+
+ JNIEnv *env = JNIUtil::getEnv();
+ if (JNIUtil::isJavaExceptionThrown())
+
Thanks for reviewing! You're quite the savior of this branch :)
On 27.01.2021 11:02, Johan Corveleyn wrote:
> was wondering what you meant by "This error is easily seen
> when running JavaHL tests"
If you checkout r1882518, tests die with 'Bad global or local ref passed
to JNI' before this erro
On 25.01.2021 1:55, Johan Corveleyn wrote:
As an update: I've started looking into this, but it's a bit more work
than I anticipated. I want to understand and properly review the
changes.
Thanks! I already started thinking that all hope is lost :)
The branch contains additional tests (added o
I have committed a series of patches for JavaHL on 'javahl-1.14-fixes'
branch. They mostly address crashes when using TunnelAgent, but also fix
some JNI warnings.
The branch also includes automatic tests for problems I fixed. If you
only checkout the first commit of the branch, there will be t
Now available on branch 'javahl-1.14-fixes', r1882523 + r1882525
Now available on branch 'javahl-1.14-fixes', r1882522.
On 05.10.2020 5:17, Nathan Hartman wrote:
While reviewing r1882115, I wondered what was the original rationale
for the C++ function SVNBase::createCppBoundObject() to cache clazz's
ctor's method ID in a locally scoped static variable.
It seems to be the common code style in JavaHL to cache the
Committed in 1882115.
On 10.09.2020 22:27, Nathan Hartman wrote:
I'll try to get my system setup to run the JavaHL tests, which has been
on my to-do list for some time anyway. If I can get that to work and
verify the changes don't introduce regressions, then we'll go from there.
If I'm not missing something, macOS/
Please find patch attached.
[[[
Fix JavaHL error in SVNBase::createCppBoundObject
The problem here is that 'SVNBase::createCppBoundObject' can work
with different classes (see argument), but it cached methodID of
'' for the first class processed.
The error is seen when running JavaHL tests with
On 11.08.2020 3:56, James McCoy wrote:
Is this superceded by your other patch?
No, these are two different patches.
On 09.08.2020 23:10, Daniel Sahlberg wrote:
I have investigated further and I think I have found the issue. A patch
is attached, basically changing
const String::Contents key(String(m_env, jkey));
to
const String str(m_env, jkey);
const String::Contents key(str);
in ImmutableMap.
Please find test snippet and patch attached.
[[[
Fix JavaHL crash in RequestChannel.nativeRead
The problem here is that when 'RemoteSession' is destroyed, it also
does 'apr_pool_destroy()' which frees memory behind 'apr_file_t', which
is represented by 'TunnelChannel.nativeChannel' in Java.
'Tun
Please find test snippet and patch attached.
[[[
Fix JavaHL crash in TunnelAgent.CloseTunnelCallback after GC
When jobject reference is kept across different JNI calls, a new global
reference must be requested with NewGlobalRef(). Otherwise, GC is free
to remove the object. Even if Java code kee
38 matches
Mail list logo
