Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
To: users@subversion.apache.org
From: Walter Klust <walter.klust@elego.de>
Subject: JavaHL: JNIError: bad C++ this
Message-ID: <76a58dde-35e6-998c-6bc4-3d3da486d262@elego.de>
Date: Fri, 8 Jul 2016 10:58:48 +0200
User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Fri, 08 Jul 2016 08:59:04 -0000

Hello,

I have an interesting problem concerning JavaHL:

- Windows 7, JRE 8u66, Eclipse 4.2.1, Subclipse 1.8.22, JavaHL 1.8.10
- a changeset of around 2000 files; roughly 50% modified and 50% deleted (probably to a large refactoring)
- on trying to commit the changes eclipse pops up a message after a short time: "Internal error occured during 
SVNCommit",  "bad C++ this"
- in the eclipse logs a stacktrace was found:

org.apache.subversion.javahl.JNIError: bad C++ this
          at org.apache.subversion.javahl.SVNClient.dispose(Native Method)
          at
  org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapter.dispose(AbstractJhlClientAdapter.java:3007)
          at
  org.tigris.subversion.subclipse.core.SVNClientManager.returnSVNClient(SVNClientManager.java:162)
          at
  org.tigris.subversion.subclipse.ui.operations.CommitOperation.execute(CommitOperation.java:113)
          at
  org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(SVNOperation.java:90)
          at
  org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144)
          at
  org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72)
          at
  org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
          at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)


- this error does not occur when trying to commit a subset of the changes, e.g. any 2 of 4 subdirectories can be 
comitted successfully but not all 4 together.

It looks to me like a quantity problem; something like an internal buffer overflow due to the large changeset. I tried 
to reproduce this with a similar number of modified/deleted files but had no success so far.

Any ideas how to analyze this problem further ?

kind regards

-- 
Walter Klust