Thanks for answering. The user tried to commit using our SVN 1.9.7
binaries from <https://www.smartsvn.com/download/#svn>:
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: E200009: Could not add all targets because some targets are already
versioned
svn: E200009: 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 <thomas.sin...@syntevo.com> writes:
Thread 44 Crashed:: Java: WorkerThread-3
0 libsystem_kernel.dylib 0x00007fff696a0b6e __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff6986b080 pthread_kill + 333
2 libsystem_c.dylib 0x00007fff695fc1ae abort + 127
3 libsvn_subr-1.0.dylib 0x000000011ef564f5 abort_on_pool_failure +
4 libserf-1.dylib 0x000000011f0dec53 serf__process_connection + 259
5 libserf-1.dylib 0x000000011f0dd263 serf_event_trigger + 163
6 libserf-1.dylib 0x000000011f0dd39c serf_context_run + 108
7 libsvn_ra_serf-1.0.dylib 0x000000011f394845
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.
