Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id E00C5200B38 for ; Fri, 8 Jul 2016 16:38:25 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id DEBBC160A5A; Fri, 8 Jul 2016 14:38:25 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 0E2C0160A36 for ; Fri, 8 Jul 2016 16:38:24 +0200 (CEST) Received: (qmail 91885 invoked by uid 500); 8 Jul 2016 14:38:24 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 91874 invoked by uid 99); 8 Jul 2016 14:38:23 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jul 2016 14:38:23 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 56E3E18052A for ; Fri, 8 Jul 2016 14:38:23 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.179 X-Spam-Level: ** X-Spam-Status: No, score=2.179 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, KAM_LIVE=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id VL0_0x5HGCt2 for ; Fri, 8 Jul 2016 14:38:20 +0000 (UTC) Received: from mail-oi0-f65.google.com (mail-oi0-f65.google.com [209.85.218.65]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 54C1F5FBAA for ; Fri, 8 Jul 2016 14:38:19 +0000 (UTC) Received: by mail-oi0-f65.google.com with SMTP id j134so9761241oib.3 for ; Fri, 08 Jul 2016 07:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H+NWUbeepcucftv2B8BTvlsTsS4Yl5mEEb2cduTq9cM=; b=sGGbG1W5QamQgjjXNjyRZpNYqKNkLDDna55pzA7AeocDIb+pqZCtLQj38JtmcTkc9U giLxTV+5xWOMBiSmE8AG5Kcn1d7SAd5od8sw/HrEfXY0Pe9ReamWj7zxUnllA3JBcKcr tozLk47t3wiImu+VTg4ehlUGnWcralV0gda+bONiW0vWDfJE9bONobtgHse3CPen5sxw Pv9G6W1zEcadnSfkjTW6smdWfxChYdDN748q/Ws4n+ORjFG1S5R1xIZIp2eQ7p5PlyRZ g++1cHqDyVvaBgcg83Bz+yWDh9jFJ3MlOzIj8pY4XB/76ULjwhTUbrNIZQvmQe23d7q6 1VRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H+NWUbeepcucftv2B8BTvlsTsS4Yl5mEEb2cduTq9cM=; b=QHQu2IrwV4NVb29FPIXeoy5VkqYZOkms3LTr5No2ibEKK0xSzYYMtb6yiNGfWkSjUx oleB4tEzAYyySrIgLAmrC8Y0+XeekXn/Euipa1zEhUvdlOTHNLFaiUtg7ccm0Ajb24jR Pg1k/iYXVIBqeAXGJZaJND95DUOYqcWDLQ7lw9ypLJBA1BXGlcO8s1/jqtzUloD1NWLm 4H3A1P26jYiCHyccnrdOez5RN3ZjoNYCnQjAM83oeEOfWXyNTIuH4FQKGH0qtrrZ4Nb0 eK+Z59CxFWtF/Dvb45x6bLh7RdTSSERHmhJKvtn9b86kttHlm6iu1TwkHSgKLtPsl7dA tG6g== X-Gm-Message-State: ALyK8tKRNah6CpbE5Oto6ZUUhlKGSkzGoqH5Zvj6gEK8QdaHlvDLskEh+MfXGIk3RKJfYcY+43nDkwG/OYfcXA== X-Received: by 10.157.16.124 with SMTP id o57mr3356712oto.142.1467988698064; Fri, 08 Jul 2016 07:38:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.91.71 with HTTP; Fri, 8 Jul 2016 07:38:16 -0700 (PDT) In-Reply-To: <76a58dde-35e6-998c-6bc4-3d3da486d262@elego.de> References: <76a58dde-35e6-998c-6bc4-3d3da486d262@elego.de> From: Mark Phippard Date: Fri, 8 Jul 2016 10:38:16 -0400 Message-ID: Subject: Re: JavaHL: JNIError: bad C++ this To: Walter Klust Cc: "users@subversion.apache.org" Content-Type: multipart/alternative; boundary=001a1141f4a8e1f73b053720c0eb archived-at: Fri, 08 Jul 2016 14:38:26 -0000 --001a1141f4a8e1f73b053720c0eb Content-Type: text/plain; charset=UTF-8 On Fri, Jul 8, 2016 at 4:58 AM, Walter Klust wrote: > 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" > I do not know if you are using changeset generically or referencing the Eclipse changeset feature. But just to clarify for SVN devs, this is not the SVN changelist feature. In terms of SVN commit, it would just be a specific list of files to commit like any other commit. Eclipse changesets are just a UI feature to organize the modified files. > - 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 ? > > It sort of seems like it could be a Subclipse bug, though it is interesting that it only manifests in specific scenarios. Makes me not really sure where to look. Does the commit work or record any errors? This exception is only happening in some cleanup that occurs after the API calls would all be completed or possibly after having processed an exception. IOW, this is not failing during an API call, it is failing when Subclipse is just disposing of the JavaHL client it obtained to make the API calls. Something that is done for every API call. The stack trace does not make a lot of sense either. This should be the relevant place in the code: org.tigris.subversion.subclipse.ui.operations.CommitOperation.execute(CommitOperation.java:113) But that does not line up with anything that makes a lot of sense for the error. -- Thanks Mark Phippard http://markphip.blogspot.com/ --001a1141f4a8e1f73b053720c0eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 8, 2016 at 4:58 AM, Walter Klust <walter.= klust@elego.de> wrote:
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 (p= robably to a large refactoring)
- on trying to commit the changes eclipse pops up a message after a short t= ime: "Internal error occured during SVNCommit",=C2=A0 "bad C= ++ this"

I do not know if you are = using changeset generically or referencing the Eclipse changeset feature.= =C2=A0 But just to clarify for SVN devs, this is not the SVN changelist fea= ture.=C2=A0 In terms of SVN commit, it would just be a specific list of fil= es to commit like any other commit.=C2=A0 Eclipse changesets are just a UI = feature to organize the modified files.

=C2=A0
- in the eclipse logs a stacktrace was found:

org.apache.subversion.javahl.JNIError: bad C++ this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at org.apache.subversion.javahl.SVNClient= .dispose(Native Method)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at
=C2=A0org.tigris.subversion.svnclientadapter.javahl.AbstractJhlClientAdapte= r.dispose(AbstractJhlClientAdapter.java:3007)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at
=C2=A0org.tigris.subversion.subclipse.core.SVNClientManager.returnSVNClient= (SVNClientManager.java:162)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at
=C2=A0org.tigris.subversion.subclipse.ui.operations.CommitOperation.execute= (CommitOperation.java:113)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at
=C2=A0org.tigris.subversion.subclipse.ui.operations.SVNOperation.run(SVNOpe= ration.java:90)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at
=C2=A0org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnab= leContext.java:144)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at
=C2=A0org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.r= unInWorkspace(JobRunnableContext.java:72)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at
=C2=A0org.eclipse.core.internal.resources.InternalWorkspaceJob.run(Internal= WorkspaceJob.java:38)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0at 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 t= ogether.

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

Any ideas how to analyze this problem further ?

It sort of seems like it could be a Subclipse bug, though it i= s interesting that it only manifests in specific scenarios.=C2=A0 Makes me = not really sure where to look.

Does the commit wor= k or record any errors?=C2=A0 This exception is only happening in some clea= nup that occurs after the API calls would all be completed or possibly afte= r having processed an exception.=C2=A0 IOW, this is not failing during an A= PI call, it is failing when Subclipse is just disposing of the JavaHL clien= t it obtained to make the API calls.=C2=A0 Something that is done for every= API call.

The stack trace does not make a lot of = sense either.=C2=A0 This should be the relevant place in the code:

=C2=A0org.tigris.subversion.subclipse.ui.operations.Commit= Operation.execute(CommitOperation.java:113)

Bu= t that does not line up with anything that makes a lot of sense for the err= or.
=C2=A0

--
--001a1141f4a8e1f73b053720c0eb--