Re: JavaHL crash on macOS 10.13.5

[Thomas Singer]

For adding/committing an empty file he is getting:


$ touch testfile.txt
$ svn add testfile.txt 
A testfile.txt
$ svn commit -m "commit test" testfile.txt 
Adding testfile.txt

Transmitting file data .svn: E175002: Commit failed (details follow):
svn: E175002: Unexpected HTTP status 400 'Bad Request' on 
'/svn/Projects/!svn/txr/7198-5vq/E867%20MS%20Marin/testfile.txt'


--
Best regards,
Thomas Singer



On 2018-06-08 8:12, Thomas Singer wrote:
Thanks for answering. The user tried to commit using our SVN 1.9.7 
binaries from :


I attempted the command line commit and got an error. It is a text 
file, RTF made in TextEdit and is 2 words. here’s the error i got from 
the command line which makes no sense to me since i have 16gigs of 
memory and over half of it free. Thanks again!


$ svn add Test\ Commit\ File.rtf svn: warning: W150002: 
'/Users/relic/Documents/SVN/Projects/E867 MS Marin/Test Commit 
File.rtf' is already under version control
svn: E29: Could not add all targets because some targets are 
already versioned

svn: E29: Illegal target for the requested operation
$ svn commit -m "commit test" Test\ Commit\ File.rtf Adding 
Test Commit File.rtf

Transmitting file data .libsvn: Out of memory - terminating application.
Abort trap: 6


Are there other, portable SVN binaries for macOS available to try them, 
too? Maybe the problem is caused by how we build?

Re: JavaHL crash on macOS 10.13.5

[Thomas Singer]

Thanks for answering. The user tried to commit using our SVN 1.9.7 
binaries from :



I attempted the command line commit and got an error. It is a text file, RTF 
made in TextEdit and is 2 words. here’s the error i got from the command line 
which makes no sense to me since i have 16gigs of memory and over half of it 
free. Thanks again!

$ svn add Test\ Commit\ File.rtf 
svn: warning: W150002: '/Users/relic/Documents/SVN/Projects/E867 MS Marin/Test Commit File.rtf' is already under version control

svn: E29: Could not add all targets because some targets are already 
versioned
svn: E29: Illegal target for the requested operation
$ svn commit -m "commit test" Test\ Commit\ File.rtf 
Adding Test Commit File.rtf

Transmitting file data .libsvn: Out of memory - terminating application.
Abort trap: 6


Are there other, portable SVN binaries for macOS available to try them, 
too? Maybe the problem is caused by how we build?


--
Best regards,
Thomas Singer



On 2018-06-07 11:24, Philip Martin wrote:

Thomas Singer  writes:


Thread 44 Crashed:: Java: WorkerThread-3
0   libsystem_kernel.dylib  0x7fff696a0b6e __pthread_kill + 10
1   libsystem_pthread.dylib 0x7fff6986b080 pthread_kill + 333
2   libsystem_c.dylib   0x7fff695fc1ae abort + 127
3 libsvn_subr-1.0.dylib 0x00011ef564f5 abort_on_pool_failure +
4 libserf-1.dylib 0x00011f0dec53 serf__process_connection + 259
5 libserf-1.dylib 0x00011f0dd263 serf_event_trigger + 163
6 libserf-1.dylib 0x00011f0dd39c serf_context_run + 108
7 libsvn_ra_serf-1.0.dylib 0x00011f394845
svn_ra_serf__context_run + 69



Unfortunately, I neither can't reproduce the crash on our macOS 10.13
machine nor do I understand the reason for the crash. Could it be,
somehow, be caused by us having compiled SVN incorrectly? Or could
this be a problem of libsystem_kernel.dylib, libsystem_pthread.dylib,
libsystem_c.dylib? Thanks in advance for any helpful clue.


abort_on_pool_failure() indicates that the process failed to allocate
dynamic memory.  There could be a memory leak, causing the process to
allocate an excessive amount of memory.  There could be some limit on
the process causing it to fail when attempting to allocate a large, but
reasonable, amount of memory.  Was the commit "large" in some way?  Lots
of files?  Large files?  Deep directories?  Lots of properties?  Large
properties? etc.

Re: handling of reparse points

[Philip Martin]

Branko Čibej  writes:

>> We do use that flag, but — just like cross-device copies on Unix — the
>> move is no longer atomic, which could break the working copy quite badly.
>
> I mean cross-device moves, of course, not copies.

svn_io_file_move() is our wrapper that is intended to make it work: it
does a cross-device copy to a temporary name and then an atomic rename.
That looks like it should be safe and workqueue.c:run_file_move() has a
comment claiming this works.

However there appears to be a different bug in svn_io_file_move: it
doesn't delete the original after a successful cross-device copy/rename.
It looks like r1685793 accidentally removed the delete.  The
cross-device code is old, it predates wc-ng, so it is possible that it
is no longer exercised.  For wc-ng it is not currently possible to put
.svn or .svn/tmp on a separate device.

-- 
Philip

Re: handling of reparse points

[Branko Čibej]

On 08.06.2018 00:30, Branko Čibej wrote:
> On 07.06.2018 18:50, Stefan Kueng wrote:
>>
>> On 05.06.2018 23:35, Philip Martin wrote:
>>> Stefan Küng  writes:
>>>
 Index: subversion/libsvn_subr/io.c
 ===
 --- subversion/libsvn_subr/io.c    (revision 1831874)
 +++ subversion/libsvn_subr/io.c    (working copy)
 @@ -342,8 +342,11 @@
     /* Not using svn_io_stat() here because we want to check the
    apr_err return explicitly. */
     SVN_ERR(cstring_from_utf8(&path_apr, path, pool));
 -
 +#ifdef WIN32
 +  flags = APR_FINFO_MIN;
 +#else
     flags = resolve_symlinks ? APR_FINFO_MIN : (APR_FINFO_MIN |
 APR_FINFO_LINK);
 +#endif
     apr_err = apr_stat(&finfo, path_apr, flags, pool);
       if (APR_STATUS_IS_ENOENT(apr_err))

>>> This needs a comment to explain why Windows needs to do something
>>> different.
>> patch with comment attached.
>>
>>> I think we would have to back this change out if we ever attempted to
>>> add svn:special support on Windows, but I suppose any such support is
>>> unlikely in the near future; as Branko pointed out CreateSymbolicLink
>>> doesn't have the semantics we want.
>> Just FYI: in that case svn would have a requirement for NTFS. Because
>> both hard links (for files) and junctions (for directories) only work
>> on NTFS. So it wouldn't be possible anymore to use svn on e.g. a usb
>> stick formatted with FAT32.
> Yes ... we'd _also_ have to detect the capabilities of the underlying
> filesystem.
>
>>> Making .svn a symbolic link on Linux came up in another thread recently:
>>>
>>> https://lists.apache.org/thread.html/d08f3a0b71600e2b67cd39817cd99e4de25a7e4f12817fe451f162e5@%3Cdev.subversion.apache.org%3E
>>>
>>>
>>> At present there is an assumption that .svn lives on the same filesystem
>>> as the working copy and that files can be atomically moved from .svn/tmp
>>> into the working copy (see workqueue.c calling svn_io_file_rename2).  If
>>> .svn becomes a symlink that points to a different filesystem then these
>>> moves fail and Subversion doesn't work.  We might be able to work around
>>> this by replacing svn_io_file_rename2 with svn_io_file_move.
>>>
>>> I don't know if Windows has the same problem.
>> On Windows, the MoveFileEx() API which is used by win32_file_rename
>> which is used by svn_io_file_rename2 can work that way: the flag
>> MOVEFILE_COPY_ALLOWED must be passed as well. Then the Move works
>> across volumes because Windows then does the move as a copy/delete
>> instead.
> We do use that flag, but — just like cross-device copies on Unix — the
> move is no longer atomic, which could break the working copy quite badly.

I mean cross-device moves, of course, not copies.

>> Also: the current implementation on Windows handles links wrong: it
>> assumes that a reparse point is always a junction, but that's not the
>> case. A junction is just a special form of a reparse point.
> Well, the more patches we get to fix these issues, the better.
>
> -- Brane
>

Re: handling of reparse points

[Branko Čibej]

On 07.06.2018 18:50, Stefan Kueng wrote:
>
>
> On 05.06.2018 23:35, Philip Martin wrote:
>> Stefan Küng  writes:
>>
>>> Index: subversion/libsvn_subr/io.c
>>> ===
>>> --- subversion/libsvn_subr/io.c    (revision 1831874)
>>> +++ subversion/libsvn_subr/io.c    (working copy)
>>> @@ -342,8 +342,11 @@
>>>     /* Not using svn_io_stat() here because we want to check the
>>>    apr_err return explicitly. */
>>>     SVN_ERR(cstring_from_utf8(&path_apr, path, pool));
>>> -
>>> +#ifdef WIN32
>>> +  flags = APR_FINFO_MIN;
>>> +#else
>>>     flags = resolve_symlinks ? APR_FINFO_MIN : (APR_FINFO_MIN |
>>> APR_FINFO_LINK);
>>> +#endif
>>>     apr_err = apr_stat(&finfo, path_apr, flags, pool);
>>>       if (APR_STATUS_IS_ENOENT(apr_err))
>>>
>>
>> This needs a comment to explain why Windows needs to do something
>> different.
>
> patch with comment attached.
>
>> I think we would have to back this change out if we ever attempted to
>> add svn:special support on Windows, but I suppose any such support is
>> unlikely in the near future; as Branko pointed out CreateSymbolicLink
>> doesn't have the semantics we want.
>
> Just FYI: in that case svn would have a requirement for NTFS. Because
> both hard links (for files) and junctions (for directories) only work
> on NTFS. So it wouldn't be possible anymore to use svn on e.g. a usb
> stick formatted with FAT32.

Yes ... we'd _also_ have to detect the capabilities of the underlying
filesystem.

>> Making .svn a symbolic link on Linux came up in another thread recently:
>>
>> https://lists.apache.org/thread.html/d08f3a0b71600e2b67cd39817cd99e4de25a7e4f12817fe451f162e5@%3Cdev.subversion.apache.org%3E
>>
>>
>> At present there is an assumption that .svn lives on the same filesystem
>> as the working copy and that files can be atomically moved from .svn/tmp
>> into the working copy (see workqueue.c calling svn_io_file_rename2).  If
>> .svn becomes a symlink that points to a different filesystem then these
>> moves fail and Subversion doesn't work.  We might be able to work around
>> this by replacing svn_io_file_rename2 with svn_io_file_move.
>>
>> I don't know if Windows has the same problem.
>
> On Windows, the MoveFileEx() API which is used by win32_file_rename
> which is used by svn_io_file_rename2 can work that way: the flag
> MOVEFILE_COPY_ALLOWED must be passed as well. Then the Move works
> across volumes because Windows then does the move as a copy/delete
> instead.

We do use that flag, but — just like cross-device copies on Unix — the
move is no longer atomic, which could break the working copy quite badly.

> Also: the current implementation on Windows handles links wrong: it
> assumes that a reparse point is always a junction, but that's not the
> case. A junction is just a special form of a reparse point.

Well, the more patches we get to fix these issues, the better.

-- Brane

Re: handling of reparse points

[Stefan Kueng]

On 05.06.2018 23:35, Philip Martin wrote:

Stefan Küng  writes:


Index: subversion/libsvn_subr/io.c
===
--- subversion/libsvn_subr/io.c (revision 1831874)
+++ subversion/libsvn_subr/io.c (working copy)
@@ -342,8 +342,11 @@
/* Not using svn_io_stat() here because we want to check the
   apr_err return explicitly. */
SVN_ERR(cstring_from_utf8(&path_apr, path, pool));
-
+#ifdef WIN32
+  flags = APR_FINFO_MIN;
+#else
flags = resolve_symlinks ? APR_FINFO_MIN : (APR_FINFO_MIN | APR_FINFO_LINK);
+#endif
apr_err = apr_stat(&finfo, path_apr, flags, pool);
  
if (APR_STATUS_IS_ENOENT(apr_err))




This needs a comment to explain why Windows needs to do something
different.


patch with comment attached.


I think we would have to back this change out if we ever attempted to
add svn:special support on Windows, but I suppose any such support is
unlikely in the near future; as Branko pointed out CreateSymbolicLink
doesn't have the semantics we want.


Just FYI: in that case svn would have a requirement for NTFS. Because 
both hard links (for files) and junctions (for directories) only work on 
NTFS. So it wouldn't be possible anymore to use svn on e.g. a usb stick 
formatted with FAT32.



Making .svn a symbolic link on Linux came up in another thread recently:

https://lists.apache.org/thread.html/d08f3a0b71600e2b67cd39817cd99e4de25a7e4f12817fe451f162e5@%3Cdev.subversion.apache.org%3E

At present there is an assumption that .svn lives on the same filesystem
as the working copy and that files can be atomically moved from .svn/tmp
into the working copy (see workqueue.c calling svn_io_file_rename2).  If
.svn becomes a symlink that points to a different filesystem then these
moves fail and Subversion doesn't work.  We might be able to work around
this by replacing svn_io_file_rename2 with svn_io_file_move.

I don't know if Windows has the same problem.


On Windows, the MoveFileEx() API which is used by win32_file_rename 
which is used by svn_io_file_rename2 can work that way: the flag 
MOVEFILE_COPY_ALLOWED must be passed as well. Then the Move works across 
volumes because Windows then does the move as a copy/delete instead.


Also: the current implementation on Windows handles links wrong: it 
assumes that a reparse point is always a junction, but that's not the 
case. A junction is just a special form of a reparse point.


Stefan

Index: libsvn_subr/io.c
===
--- libsvn_subr/io.c(revision 1833061)
+++ libsvn_subr/io.c(working copy)
@@ -342,8 +342,12 @@
   /* Not using svn_io_stat() here because we want to check the
  apr_err return explicitly. */
   SVN_ERR(cstring_from_utf8(&path_apr, path, pool));
-
+#ifdef WIN32
+  /* on Windows, svn does not handle reparse points or hard links */
+  flags = APR_FINFO_MIN;
+#else
   flags = resolve_symlinks ? APR_FINFO_MIN : (APR_FINFO_MIN | APR_FINFO_LINK);
+#endif
   apr_err = apr_stat(&finfo, path_apr, flags, pool);
 
   if (APR_STATUS_IS_ENOENT(apr_err))

Re: JavaHL crash on macOS 10.13.5

[Philip Martin]

Thomas Singer  writes:

>> Thread 44 Crashed:: Java: WorkerThread-3
>> 0   libsystem_kernel.dylib   0x7fff696a0b6e __pthread_kill + 10
>> 1   libsystem_pthread.dylib  0x7fff6986b080 pthread_kill + 333
>> 2   libsystem_c.dylib0x7fff695fc1ae abort + 127
>> 3 libsvn_subr-1.0.dylib 0x00011ef564f5 abort_on_pool_failure +
>> 4 libserf-1.dylib 0x00011f0dec53 serf__process_connection + 259
>> 5 libserf-1.dylib 0x00011f0dd263 serf_event_trigger + 163
>> 6 libserf-1.dylib 0x00011f0dd39c serf_context_run + 108
>> 7 libsvn_ra_serf-1.0.dylib 0x00011f394845
>> svn_ra_serf__context_run + 69

> Unfortunately, I neither can't reproduce the crash on our macOS 10.13
> machine nor do I understand the reason for the crash. Could it be,
> somehow, be caused by us having compiled SVN incorrectly? Or could
> this be a problem of libsystem_kernel.dylib, libsystem_pthread.dylib,
> libsystem_c.dylib? Thanks in advance for any helpful clue.

abort_on_pool_failure() indicates that the process failed to allocate
dynamic memory.  There could be a memory leak, causing the process to
allocate an excessive amount of memory.  There could be some limit on
the process causing it to fail when attempting to allocate a large, but
reasonable, amount of memory.  Was the commit "large" in some way?  Lots
of files?  Large files?  Deep directories?  Lots of properties?  Large
properties? etc.

-- 
Philip

JavaHL crash on macOS 10.13.5

[Thomas Singer]

Hi experts,

We've got a macOS crash report from a user of SmartSVN (that uses JavaHL 
for performing SVN commands). The following thread crashed when the user 
tried to add/commit a new file:



Thread 44 Crashed:: Java: WorkerThread-3
0   libsystem_kernel.dylib  0x7fff696a0b6e __pthread_kill + 10
1   libsystem_pthread.dylib 0x7fff6986b080 pthread_kill + 333
2   libsystem_c.dylib   0x7fff695fc1ae abort + 127
3   libsvn_subr-1.0.dylib   0x00011ef564f5 
abort_on_pool_failure + 21
4   libserf-1.dylib 0x00011f0dec53 
serf__process_connection + 259
5   libserf-1.dylib 0x00011f0dd263 serf_event_trigger + 
163
6   libserf-1.dylib 0x00011f0dd39c serf_context_run + 
108
7   libsvn_ra_serf-1.0.dylib0x00011f394845 
svn_ra_serf__context_run + 69
8   libsvn_ra_serf-1.0.dylib0x00011f394976 
svn_ra_serf__context_run_wait + 86
9   libsvn_ra_serf-1.0.dylib0x00011f394a5a 
svn_ra_serf__context_run_one + 138
10  libsvn_ra_serf-1.0.dylib0x00011f3840ef close_file + 223
11  libsvn_wc-1.0.dylib 0x00011f4cccee 
svn_wc__internal_transmit_text_deltas + 1342
12  libsvn_wc-1.0.dylib 0x00011f4ccd43 
svn_wc_transmit_text_deltas3 + 67
13  libsvn_client-1.0.dylib 0x00011f57a554 
svn_client__do_commit + 596
14  libsvn_client-1.0.dylib 0x00011f579373 svn_client_commit6 + 
3475
15  libsvnjavahl-1.dylib0x00011f5fbed2 SVNClient::commit(Targets&, 
CommitMessage*, svn_depth_t, bool, bool, StringArray&, PropertyTable&, 
CommitCallback*) + 242
16  libsvnjavahl-1.dylib0x00011f60e555 
Java_org_apache_subversion_javahl_SVNClient_commit + 453
17  ??? 0x00010fe96a74 0 + 4561922676
18  ??? 0x00010fe87302 0 + 4561859330
19  ??? 0x00010fe87040 0 + 4561858624
20  ??? 0x00010fe87114 0 + 4561858836
21  ??? 0x00010fe87040 0 + 4561858624
22  ??? 0x00010fe87040 0 + 4561858624
23  ??? 0x00010fe872bd 0 + 4561859261
24  ??? 0x00010fe872bd 0 + 4561859261
25  ??? 0x00010fe87040 0 + 4561858624
26  ??? 0x00010fe87114 0 + 4561858836
27  ??? 0x00010fe87040 0 + 4561858624
28  ??? 0x00010fe87114 0 + 4561858836
29  ??? 0x00010fe87114 0 + 4561858836
30  ??? 0x00010fe87302 0 + 4561859330
31  ??? 0x00010fe872bd 0 + 4561859261
32  ??? 0x00010fe87302 0 + 4561859330
33  ??? 0x00010fe7f7a7 0 + 4561827751
34  libjvm.dylib0x000100b4870a 
JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) 
+ 1710
35  libjvm.dylib0x000100b48eae 
JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, 
JavaCallArguments*, Thread*) + 356
36  libjvm.dylib0x000100b4905a 
JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, 
Thread*) + 74
37  libjvm.dylib0x000100ba37b1 
thread_entry(JavaThread*, Thread*) + 124
38  libjvm.dylib0x000100dc60b3 
JavaThread::thread_main_inner() + 155
39  libjvm.dylib0x000100dc77a0 JavaThread::run() + 
450
40  libjvm.dylib0x000100ce5aee java_start(Thread*) 
+ 246
41  libsystem_pthread.dylib 0x7fff69868661 _pthread_body + 340
42  libsystem_pthread.dylib 0x7fff6986850d _pthread_start + 377
43  libsystem_pthread.dylib 0x7fff69867bf9 thread_start + 13


Unfortunately, I neither can't reproduce the crash on our macOS 10.13 
machine nor do I understand the reason for the crash. Could it be, 
somehow, be caused by us having compiled SVN incorrectly? Or could this 
be a problem of libsystem_kernel.dylib, libsystem_pthread.dylib, 
libsystem_c.dylib? Thanks in advance for any helpful clue.


--
Best regards,
Thomas Singer

Re: Documentation to build SVN 1.10

[emmawatson8855]

Stefan Sperling-9 wrote
> On Wed, Apr 18, 2018 at 10:50:15AM +0200, Thomas Singer wrote:
>> Hi developers,
>> 
>> I'm trying to build SVN 1.10 on CentOS 6.2 based on a black-box build
>> script
>> that I have for SVN 1.9. So far it looks like SVN 1.10 requires a newer
>> sqlite-amalgamation-3081101.zip and requires something regarding LZ4.
>> Unfortunately, simply adding "--with-lz4=internal" is not sufficient,
>> because now it complains about "Subversion requires UTF8PROC". How to
>> install that - where can I find documentation about how to build SVN
>> 1.10?
> 
> See ./configure --help ; utf8proc is another new required dependency
> and, like with lz4, there's an internal copy you could compile with.

It helped me to compile on Linux, Thank you for responce



-
Mobile App Development Company 
--
Sent from: http://subversion.1072662.n5.nabble.com/Subversion-Dev-f4725.html