2.0.55-4ubuntu4 update causes svn failure

[atie]

I call Eclipse.org's eclipse by this script to enable libsvn-javahl for subclipse plugin.

#!/bin/bash
~/eclipse/eclipse -vm /usr/local/java/jdk1.6.0/bin/java -vmargs -Djava.library.path=/usr/lib/jni/

Today's apache2 update causes the startup script crashed at middle of eclipse splash, I think it's because of libapr0 updated along with apache2 and it is "Depends" of libsvn0.

Just calling ~/eclipse/eclipse -vm /usr/local/java/jdk1.6.0/bin/java from command line is OK, FYI in case.

[Lionel Porcheron (lionel.porcheron)]

if the problem is libsvn0, the correct source package is subversion, not apache2.

[atie (atie-at-matrix)]

Updated to today's subversion 1.3.2-3ubuntu2, but still this problem exists. As shown on the error log by eclipse/java vm, this problem seems to be at apr pool so maybe apache runtime module problem.

C [libsvnjavahl-1.so.0.0.0+0xccb4] _ZN8JNIMutexC1EP10apr_pool_t+0x44

[atie (atie-at-matrix)]

Here is ldd info in case.

$ ldd -r /usr/lib/jni/libsvnjavahl-1.so
        linux-gate.so.1 => (0xffffe000)
        libsvn_repos-1.so.0 => /usr/lib/libsvn_repos-1.so.0 (0xb7f2d000)
        libsvn_client-1.so.0 => /usr/lib/libsvn_client-1.so.0 (0xb7f07000)
        libsvn_wc-1.so.0 => /usr/lib/libsvn_wc-1.so.0 (0xb7edb000)
        libsvn_subr-1.so.0 => /usr/lib/libsvn_subr-1.so.0 (0xb7eb4000)
        libapr-0.so.0 => /usr/lib/libapr-0.so.0 (0xb7e93000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7db4000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d8e000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7d7b000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c46000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7c3a000)
        libsvn_fs-1.so.0 => /usr/lib/libsvn_fs-1.so.0 (0xb7c34000)
        libsvn_delta-1.so.0 => /usr/lib/libsvn_delta-1.so.0 (0xb7c2c000)
        libsvn_ra-1.so.0 => /usr/lib/libsvn_ra-1.so.0 (0xb7c28000)
        libsvn_diff-1.so.0 => /usr/lib/libsvn_diff-1.so.0 (0xb7c22000)
        libaprutil-0.so.0 => /usr/lib/libaprutil-0.so.0 (0xb7c0c000)
        libdb-4.3.so => /usr/lib/libdb-4.3.so (0xb7b30000)
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb7b12000)
        librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7b09000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7adb000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7ac5000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7ac0000)
        /lib/ld-linux.so.2 (0x80000000)
        libsvn_fs_fs-1.so.0 => /usr/lib/libsvn_fs_fs-1.so.0 (0xb7aa6000)
        libsvn_fs_base-1.so.0 => /usr/lib/libsvn_fs_base-1.so.0 (0xb7a81000)
        libsvn_ra_local-1.so.0 => /usr/lib/libsvn_ra_local-1.so.0 (0xb7a7b000)
        libsvn_ra_svn-1.so.0 => /usr/lib/libsvn_ra_svn-1.so.0 (0xb7a6a000)
        libsvn_ra_dav-1.so.0 => /usr/lib/libsvn_ra_dav-1.so.0 (0xb7a52000)
        libneon.so.25 => /usr/lib/libneon.so.25 (0xb7a37000)
        libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb79f8000)
        libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb78be000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb78a2000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7826000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7800000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb77fb000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb77f8000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb77e5000)
        libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb76cc000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb76b8000)

[packet (packet)]

I can confirm this bug. It makes libsvn-javahl (1.3.2-3ubuntu2) unusable. I can reproduce this bug with a self-compiled subversion 1.4.0 javahl linked against the same libraries (libapr0 2.0.55-4ubuntu4 and libneon 0.25.5.dfsg-5). The problem vanishes if I compile subversion 1.4.0 against the current libapr1 (1.2.7-3) and libaprutil1 (1.2.7-2) packages. Somehow, the apr stuff provided by apache2 seems to be incompatible with jni.

I used sun-java5-jre and sun-java5-sdk.

[packet (packet)]

I seem to have forgotten to enable the attachment...

[Jan Klesnil (klesnil)]

I have the same problem - eclipse 3.2 with latest stable subclipse plugin and svn-javahl library on Edgy.

On Dapper everything worked fine.

[atie (atie-at-matrix)]

Affected package is in question, but change status to "Confirmed" based on other's confirmations.

[Max Bowsher (maxb)]

It does seem to be something in libapr0 that is causing the crash.

I rolled back libapr0 (along with a bunch of other packages which also build from the apache2 source package, as dictated by dependencies) to 2.0.55-4ubuntu2.1 (i.e. dapper-security), and the bug went away.

It is quite odd, since there doesn't seem to be anything in the changelog for -4ubuntu3 or -4ubuntu4 that looks likely to cause this.

[Max Bowsher (maxb)]

Interesting data point: Rebuilding apache2_2.0.55-4ubuntu4 in a dapper pbuilder results in packages that work correctly. I suspect something in the APR configuration is turning out differently, and will investigate more later.

I think there's enough evidence to justify reassigning the bug back to apache2 now.

[Max Bowsher (maxb)]

I can't find anything obviously related, but I did note that there were mutex/semaphore related changes in the build:

(- is dapper, + is edgy)

autoconf definitions:
 /* Define to 1 if you have the `pthread_mutexattr_setrobust_np' function. */
-/* #undef HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP */
+#define HAVE_PTHREAD_MUTEXATTR_SETROBUST_NP 1

 /* Define if recursive pthread mutexes are available */
-#define HAVE_PTHREAD_MUTEX_RECURSIVE 1
+/* #undef HAVE_PTHREAD_MUTEX_RECURSIVE */

apr.h:
-#define APR_HAS_POSIXSEM_SERIALIZE 0
+#define APR_HAS_POSIXSEM_SERIALIZE 1

Perhaps that can be useful to someone. Or maybe it's not related at all. :-/

[Max Bowsher (maxb)]

Here is a backtrace. It sheds rather more light on the problem.

apr_thread_mutex_create dies with error 70023, APR_ENOTIMPL.

Then, whilst attempting to handle the error, libsvnjavahl segfaults - presumably because the error occurred too early in initialization for the error handling code itself to have been initialized.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209973072 (LWP 10067)]
0xae61264b in JNIUtil::setExceptionThrown ()
    at subversion-1.3.2/subversion/bindings/java/javahl/native/JNIUtil.cpp:538
538 data->m_exceptionThrown = true;
Current language: auto; currently c++
(gdb) bt
#0 0xae61264b in JNIUtil::setExceptionThrown ()
    at subversion-1.3.2/subversion/bindings/java/javahl/native/JNIUtil.cpp:538
#1 0xae612ae0 in JNIUtil::throwError (
    message=0xae63c300 "an error occurred in function apr_thread_mutex_create with return value 70023")
    at subversion-1.3.2/subversion/bindings/java/javahl/native/JNIUtil.cpp:324
#2 0xae612f54 in JNIUtil::handleAPRError (error=70023,
    op=0xae6334b4 "apr_thread_mutex_create")
    at subversion-1.3.2/subversion/bindings/java/javahl/native/JNIUtil.cpp:446
#3 0xae6113b2 in JNIMutex (this=0x8301de0, pool=0x8353d88)
    at subversion-1.3.2/subversion/bindings/java/javahl/native/JNIMutex.cpp:38
#4 0xae6136b1 in JNIUtil::JNIGlobalInit (env=0x805cf38)
    at subversion-1.3.2/subversion/bindings/java/javahl/native/JNIUtil.cpp:256
#5 0xae62a13f in Java_org_tigris_subversion_javahl_SVNClient_initNative (
    env=0x805cf38, jclazz=0xbffa0980)
    at subversion-1.3.2/subversion/bindings/java/javahl/native/org_tigris_subversion_javahl_SVNClient.cpp:1839
#6 0xb264a4db in ?? ()
#7 0x0805cf38 in ?? ()

[Max Bowsher (maxb)]

...and my comment 1 above neatly ties in with the lack of HAVE_PTHREAD_MUTEX_RECURSIVE in my comment 2 above.

Thus, when svnjavahl tries to create a recursive mutex, it errors, and its error handling then blows up and SIGSEGVs.

Cause seems to be that glibc has started hiding HAVE_PTHREAD_MUTEX_RECURSIVE unless you -D_XOPEN_SOURCE=500 (or greater).

Adding -D_XOPEN_SOURCE=500 to debian/rules and rebuilding apache2_2.0.55-4ubuntu4 results in a working subclipse again.

[biou (biouman)]

I can confirm that the fix of Max Bowsher in the precedent comment is working. Would it be a good idea to fill a bug on the apache2 or libapr0 package on that topic?

[Max Bowsher (maxb)]

Setting to confirmed for apache2, based on my own analysis, and confirmation here in this bug log, that the true problem lies in libapr0. Hopefully the apache2 maintainer(s) could comment on this and consider releasing updated packages for edgy.

[Tolstoy (keith-irwin)]

Any ETA on when this might be fixed? Or even acknowledgement by the apache/ubuntu maintainers? I had to change my NT password, which somehow broke subclipse on linux. One option is to try the javahl lib to see how that goes, but eclipse tanks as a result of the above issues.

I've no idea how to revert libapr0 as the following doesn't work:

  apt-get install libapr0=2.0.55-4ubuntu2.1

and my attempt at setting up /etc/apt/preferences doesn't seem inclined to revert all the dependencies for libapr0.

Very frustrating as I can't use subclipse via the IDE anymore.

Anyone willing to post some instructions on how to revert?

[Max Bowsher (maxb)]

I cannot test this, as I have fixed my machine in a different way - rebuilding the apache package from edgy with the tweaked flags as mentioned. However, here is a recipe that might work for getting the dapper packages installed:

( [[[ and ]]] delimit lines to copy/paste )

Add to /etc/apt/sources.list:
[[[
deb http://security.ubuntu.com/ubuntu dapper-security main
]]]

Add to /etc/apt/preferences, creating if it does not exist:
[[[

Package: apache2-common
Pin: release a=dapper-security
Pin-Priority: 1001

Package: apache2-utils
Pin: release a=dapper-security
Pin-Priority: 1001

Package: apache2-mpm-worker
Pin: release a=dapper-security
Pin-Priority: 1001

Package: apache2-mpm-perchild
Pin: release a=dapper-security
Pin-Priority: 1001

Package: apache2-mpm-prefork
Pin: release a=dapper-security
Pin-Priority: 1001

Package: apache2-doc
Pin: release a=dapper-security
Pin-Priority: 1001

Package: apache2-prefork-dev
Pin: release a=dapper-security
Pin-Priority: 1001

Package: apache2-threaded-dev
Pin: release a=dapper-security
Pin-Priority: 1001

Package: libapr0
Pin: release a=dapper-security
Pin-Priority: 1001

Package: libapr0-dev
Pin: release a=dapper-security
Pin-Priority: 1001

Package: apache2
Pin: release a=dapper-security
Pin-Priority: 1001

]]]
Do ensure that there is at least one blank line separating the added lines from any existing data in /etc/apt/preferences.

Having edited both files:

apt-get update && apt-get upgrade

Hope that works,
Max.

[Max Bowsher (maxb)]

Here is a debdiff of how I fixed things locally:
================================================================
diff -u apache2-2.0.55/debian/rules apache2-2.0.55/debian/rules
--- apache2-2.0.55/debian/rules
+++ apache2-2.0.55/debian/rules
@@ -57,7 +57,7 @@
                --enable-file-cache=shared --enable-cache=shared \
                --enable-disk-cache=shared --enable-mem-cache=shared

-AP2_CONFLAGS = $(CFLAGS) -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -g
+AP2_CONFLAGS = $(CFLAGS) -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -g -D_XOPEN_SOURCE=500
 #AP2_CONFLAGS += -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
 AP2_LDFLAGS = -ldb-4.3 -lexpat

diff -u apache2-2.0.55/debian/changelog apache2-2.0.55/debian/changelog
--- apache2-2.0.55/debian/changelog
+++ apache2-2.0.55/debian/changelog
@@ -1,3 +1,9 @@
+apache2 (2.0.55-4ubuntu4.0.maxb.1) edgy; urgency=low
+
+ * Rebuild with -D_XOPEN_SOURCE=500.
+
+ -- Max Bowsher <email address hidden> Tue, 31 Oct 2006 16:15:55 +0000
+
 apache2 (2.0.55-4ubuntu4) edgy; urgency=low

   * Add debian/patches/054_restore_prefix_fix:
================================================================

[Tolstoy (keith-irwin)]

Thanks!

BTW, do you happen to have a quick link to working with source packages?

I know how to:

  apt-get source apache2

and apply the patch. Not sure what to do after that. I guess I can google for it.

[Tolstoy (keith-irwin)]

Just to save this in case I might need it again...

I applied the above patch (which for some reason didn't apply cleanly for the first hunk), then:

  apt-get source apache2
  sudo apt-get build-deb apache2
  cd apache2-2.0.55
  dpkg-buildpackage -rfakeroot

and then after a long while:

  cd ..
  sudo dpkg -i *.deb

and that pretty much worked, far as I can tell.

Thanks again, Max, for the patch!

[Sven (anders-anduras)]

If you just uninstall the javahl library.
(If subclipse fail to load the library it will fall back to JavaSVN automatically.)

I don't now if there are some features missing, if you do it, but the basic things will work...

Maybe this will help some people...

[Immanuel Scheerer (immanuel)]

The JavaSVN bundled with Subclipse 1.1.8 seems to be a 1.4 Subversion client. The current command line client is 1.3.

After I used Subclipse to update my working copies, I can no longer use the command line client (the following message is displayed):

   svn: This client is too old to work with working copy '.'; please get a newer Subversion client

More information about the 1.3-1.4 incompatibility: http://wiki.umd.edu/wiki/display/~cdoyle/Subversion+1.4+Incompatibilities

Therefore JavaSVN is at the moment no real alternative to JavaHL. When a working patch already exists, what can you do to get the corrected packages into the ubuntu repositories as quickly as possible?

[TJ (tj)]

Just a note for those who apply Max Bowsher 's patch by copying the text from his comment here - HTML removes a *vital* double-space on the line in

debian/changelog

-- Max Bowsher <email address hidden> Tue, 31 Oct 2006 16:15:55 +0000

There should be TWO spaces after the email address, before the date, otherwise when trying to build you'll get the very-hard-to-solve error:

line 5: badly formatted trailer line

And almost the only way to spot it is using hexdump to compare the additional entry with previous ones and noticing the double-space sequence!

[Adriaan Peeters (apeeters)]

Other than that, the patch works perfectly!

[Danny Staple (danny-orionrobots)]

Hmm, I am seeing this too on Edgy.

It appears that one has to use the hl lib if access to a local filespace repo is needed - which is a massive oversite of the Java SVN library.

Anyway - for those who have not read this thread thoroughly - take note that uninstalling Apache2 will not work. It is the Source Package for Apache2 which is at fault, and the libapr0 package, upon which the libjavahl-svn depends, is actually part of the Apache2 source (Lib Apache Runtime - Shared and used by SVN). I only realised this after trying (in a what the hey it's worth a shot, and not having read everything or expected it to work) to remove Apache 2 packages and see if that would help (Apache was no longer required on this box anyway). That will not work.

This definitely needs to be sorted with a long term fix, but until then, the above fix should be applied.

Again (with corrections to Tolstoy) that is:
  apt-get source apache2
  sudo apt-get build-dep apache2

Now apply the patch. Taking into account the missing spaces - there should be TWO before the * in the debian/changelog, and TWO after the email address .

  cd apache2-2.0.55
  dpkg-buildpackage -rfakeroot

At this point it will go off, as suggested above, for a while. Ignore the genchanges gripes if you see them.

  cd ..
  sudo dpkg -i libapr*.deb

Note that you will not be able to use *.deb, as this will try to install more than one of the different apache2 modes - prefork, threaded etc and will fail.Install the one that is appropriate to your setup - or none at all if you just need this library.

Look here for info on building like this: - https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff

Anyway - it all works for me now.

[TJ (tj)]

If you're confused on how to correctly apply the patch, and simply want it to work, you can make the change manually in about 30 seconds.

After you've got the source-code downloaded and extracted, simply open the debian/rules file with any text editor and make the change.

Assuming the source is extracted to your home directory:

gedit ~/apache2-2.0.55/debian/rules

Edit > Preferences > View: "Display line numbers" = TICK

Scroll to line 60, and add the new option " -D_XOPEN_SOURCE=500" to the end (don't forget to put a space to separate it from the preceding option) so it reads:

AP2_CONFLAGS = $(CFLAGS) -pipe -I/usr/include/xmltok -I/usr/include/openssl -Wall -g -D_XOPEN_SOURCE=500

Save the file, and you're done and ready to build.

The change to the changelog isn't strictly necessary but again, you can simply add that to the beginning of debian/changelog using any text editor.

gedit ~/apache2-2.0.55/debian/changelog

Insert at the top, pushing the rest of the document down. DO NOT include the double-quotes (") I've used here to make clear where the text starts and ends.

"apache2 (2.0.55-4ubuntu4.0.maxb.1) edgy; urgency=low

  * Rebuild with -D_XOPEN_SOURCE=500.

 -- Max Bowsher <email address hidden> Tue, 31 Oct 2006 16:15:55 +0000

"

Don't forget its TWO spaces in front of "* Rebuild" and TWO spaces between "ukf.net>" and "Tue, 31".

[dlr (dlr)]

Upstream package report: The Subversion developers have fixed the error handling of the JavaHL binding's native global initialization to provide a more meaningful error, rather than just segfaulting:

  http://svn.collab.net/viewvc/svn?view=rev&revision=23383

[Matti Lindell (mlind)]

I confirm that upstream patch pointed out by dlr fixes the eclipse javahl crashing issue. Although I'm unable to get eclipse to find javahl interafce (even when using LD_LIBRARY_PATH), it doesn't crash anymore.

If this works for others too, it would be good to get this as SRU.

[Matti Lindell (mlind)]

subscribing ubuntu-sru team to take a look at this issue.

Comments should indicate that problem is in subversion's "javahl bindings native global initialization". Impact is serious because of the segfault it causes. Among other things, jvm running eclipse dies when javahl tries to initialize. Upstream patch (included in proposed debdiff and in dlr's post) addresses this issue.

[Adriaan Peeters (apeeters)]

The patch by mlind fixes the segfault, but to get javahl to work one still needs the -D_XOPEN_SOURCE=500 compile time option.

[dlr (dlr)]

Adriaan: Yup, my patch only fixes JavaHL's error handling to avoid a segfault; it will appear in Subversion 1.5.0, and 1.4.4 (if we eventually cut such a release). For JavaHL initialization to complete successfully, one still needs a properly-compiled APR.

[Martin Pitt (pitti)]

Unsubscribing ubuntu-sru. Please get this fixed and tested in Feisty first, then submit a proper SRU request as described on https://wiki.ubuntu.com/StableReleaseUpdates. Thanks!

[Matti Lindell (mlind)]

right, I was concentrating on the symptom instead of the actual issue, sorry about that. Is it only svn javahl bindings that require -D_XOPEN_SOURCE=500 or GNU_SOURCE ? It would be safer to use D_XOPEN_SOURCE=500 only for modules that do not work without it, using it globally may cause problems with some architectures.

[Max Bowsher (maxb)]

In reply to mlind:

_XOPEN_SOURCE=500 is required *whilst compiling libapr0* (source package: apache2). I'm not sure what sort of modules you mean, but no, a localized fix targetted solely to affect the javahl bindings is not likely to be feasible.

[Max Bowsher (maxb)]

Regarding the potential for a SRU:

This is a particularly awkward issue to SRU, because with Feisty having Apache 2.2 whilst Edgy has 2.0, testing in Feisty has limited relevance to Edgy.

[Soren Hansen (soren)]

Just to clarify: Is this still an issue in final Feisty?

[Adam Funk (a-funk)]

Soren Hansen:
> Just to clarify: Is this still an issue in final Feisty?

I don't think so. Since I upgraded to feisty, I can use JavaHL in Eclipse (that was the only manifestation of this bug that I had encountered).

[Adriaan Peeters (apeeters)]

Feisty does not include libapr0 so I still have the patches one from edgy installed. I will try to remove that one soon.

[Max Bowsher (maxb)]

It is not an issue with Feisty.

Feisty libsvn-java does not use libapr0 - it uses libapr1.

[atie (atie-at-matrix)]

As Max said, I don't have this issue now with feisty.

[caligari (rafacouto)]

Bug confirmed for Feisty Fawn, from scratch installation on June, 5.

[Adriaan Peeters (apeeters)]

I am unable to confirm this bug on feisty. Caligari, please list the output of

dpkg -l |grep svn
dpkg -l |grep subversion
dpkg -l |grep apr

[caligari (rafacouto)]

# dpkg -l |grep svn
ii kdesvn 0.11.0-1 subversion client with tight KDE integration
ii kdesvn-kio-plugins 0.11.0-1 subversion I/O slaves for KDE
ii libgtkhtml2-0 2.11.0+svn20061107-0ubuntu1 HTML rendering/editing library - runtime fil
ii libsvn-java 1.4.3dfsg1-1ubuntu1 Java bindings for Subversion
ii libsvn1 1.4.3dfsg1-1ubuntu1 Shared libraries used by Subversion
ii libsvnqt3 0.11.0-1 Qt wrapper library for subversion
ii libwps-0.1-1 0.1~svn20070131-2build1 Works text file format import filter library

# dpkg -l |grep subversion
ii kdesvn 0.11.0-1 subversion client with tight KDE integration
ii kdesvn-kio-plugins 0.11.0-1 subversion I/O slaves for KDE
ii libsvnqt3 0.11.0-1 Qt wrapper library for subversion
ii subversion 1.4.3dfsg1-1ubuntu1 Advanced version control system
ii subversion-tools 1.4.3dfsg1-1ubuntu1 Assorted tools related to Subversion

# dpkg -l |grep apr
ii libapr1 1.2.7-8.1 The Apache Portable Runtime Library
ii libaprutil1 1.2.7+dfsg-2build1 The Apache Portable Runtime Utility Library

# dpkg -l |grep java
ii java-common 0.25ubuntu2 Base of all Java packages
ii java-gcj-compat 1.0.65-8ubuntu3 Java runtime environment using GIJ
ii libbcel-java 5.1-6ubuntu2 Analyze, create, and manipulate (binary) Jav
ii libcommons-beanutils-java 1.7.0-4ubuntu1 utility for manipulating JavaBeans
ii libcommons-collections-java 2.1.1-6 A set of abstract data type interfaces and i
ii libcommons-collections3-java 3.1a-3.1 A set of abstract data type interfaces and i
ii libcommons-dbcp-java 1.2.1-4ubuntu1 Database Connection Pooling Services
ii libcommons-digester-java 1.7-2ubuntu1 Rule based XML Java object mapping tool
ii libcommons-el-java 1.0-3 Implementation of the JSP2.0 Expression Lang
ii libcommons-launcher-java 1.1-3 cross platform java application launcher
ii libcommons-logging-java 1.0.4-5ubuntu2 commmon wrapper interface for several log...

[Mathias Gug (mathiaz)]

caligari: do you still have the problem with gutsy ?

[Mathias Gug (mathiaz)]

Marking 'Fix released' in subversion as libapr1 fixed the problem.

[caligari (rafacouto)]

Mathias Gug:

With gutsy:

$ sudo apt-get install libsvn-java
$ sudo vi /etc/eclipse/java_home

and it works fine!

Thank you :-)

[Mathias Gug (mathiaz)]

Closing bug as this seems to work in Gutsy, and thus Hardy.

[Martin (martin-zdila)]

The issue is back in Ubuntu 11.04 updated today.

[Dave Walker (davewalker)]

@Martin, can you clarify what you are seeing? This bug report has become somewhat confusing, and I'm not quite sure what part you are experiencing.

Thanks.

[Martin (martin-zdila)]

If I run Eclipse Helios it will crash after UI is loaded. Messages in the console:

martin@bono:~/opt/eclipse$ ./eclipse

(process:5771): Gdk-WARNING **: locale not supported by C library

(process:5771): Gtk-WARNING **: Locale not supported by C library.
 Using the fallback 'C' locale.

(Eclipse:5771): Gdk-WARNING **: locale not supported by C library
Mar 9, 2011 1:15:52 PM com.objectaid.uml.license.LicenseManager initialize
INFO: found license Sequence Diagram 1.0.x - EVAL until 2011-03-17
svnjavahl: error: cannot set LC_ALL locale
svnjavahl: error: environment variable LANG is en
svnjavahl: error: please check that your locale name is correct
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f0b668007aa, pid=5771, tid=139687453128448
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libapr-1.so.0+0x2a7aa] apr_threadkey_private_get+0x14
#
# An error report file with more information is saved as:
# /home/martin/opt/eclipse/hs_err_pid5771.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

After I comment out -Djava.library.path=/usr/lib/jni in the eclipse.ini, Eclipse starts bud SVN plugin doesn't work.

[Mars29200 (mars29200)]

Hi all,
I also get such error today on eclipse startup in 11.04 :

(process:3737): Gdk-WARNING **: locale not supported by C library

(process:3737): Gtk-WARNING **: Locale not supported by C library.
 Using the fallback 'C' locale.

(Eclipse:3737): Gdk-WARNING **: locale not supported by C library
svnjavahl: error: cannot set LC_ALL locale
svnjavahl: error: environment variable LANG is de_DE.ISO-8859-1
svnjavahl: error: please check that your locale name is correct
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007ff49e328dde, pid=3737, tid=140688736360192
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libapr-1.so.0+0x2adde] apr_threadkey_private_get+0x14
#
# An error report file with more information is saved as:
# /home/msauvette/teams/is24/legacy-app/trunk/hs_err_pid3737.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

svnjavahl: error: cannot set LC_ALL locale
svnjavahl: error: environment variable LANG is de_DE.ISO-8859-1
svnjavahl: error: please check that your locale name is correct

does something different as to be set there that it work again?

[Marco Ferretti (marco-ferretti)]

Hi

same here on Ubuntu 10.04 ( 32 bit ) after this morning's updates ( I remember php5, mod-php5 but there were a few more ) .

ferrema@pupfish:~$ eclipse

(process:7461): Gdk-WARNING **: locale not supported by C library

(process:7461): Gtk-WARNING **: Locale not supported by C library.
 Using the fallback 'C' locale.

(eclipse:7461): Gdk-WARNING **: locale not supported by C library
svnjavahl: error: cannot set LC_ALL locale
svnjavahl: error: environment variable LANG is en_US
svnjavahl: error: please check that your locale name is correct
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0440f83c, pid=7461, tid=58760048
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) Client VM (20.1-b02 mixed mode, sharing linux-x86 )
# Problematic frame:
# C [libapr-1.so.0+0x2683c] signed char+0x15
#
# An error report file with more information is saved as:
# /home/ferrema/hs_err_pid7461.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted
ferrema@pupfish:~$ joe .bashrc
Processing '/etc/joe/joerc'...Processing '/etc/joe/ftyperc'...done
done

[Marco Ferretti (marco-ferretti)]

FYI :
running the following :

ferrema@pupfish:/$ export LC_ALL="en_US.UTF-8"
ferrema@pupfish:/$ sudo dpkg-reconfigure locales
Generating locales...
  en_AG.UTF-8... done
  en_AU.UTF-8... done
  en_BW.UTF-8... done
  en_CA.UTF-8... done
  en_DK.UTF-8... done
  en_GB.UTF-8... done
  en_HK.UTF-8... done
  en_IE.UTF-8... done
  en_IN.UTF-8... done
  en_NG.UTF-8... done
  en_NZ.UTF-8... done
  en_PH.UTF-8... done
  en_SG.UTF-8... done
  en_US.UTF-8... up-to-date
  en_ZA.UTF-8... done
  en_ZW.UTF-8... done
  it_CH.UTF-8... done
  it_IT.UTF-8... done
Generation complete.
ferrema@pupfish:/$ eclipse
ferrema@pupfish:/$

fixes the issue .