trang segfaults on gutsy (x86 and AMD64)

Bug #141447 reported by James Henstridge
40
This bug affects 2 people
Affects Status Importance Assigned to Milestone
trang (Debian)
Fix Released
Unknown
trang (Ubuntu)
Fix Released
Medium
Daniel T Chen

Bug Description

Binary package hint: trang

I am on Gutsy x86 and with all updates applied (trang 20030619-5.1ubuntu2).

When I try to run trang, I get a segfault mentioning a libgcj version error:

    $ trang
    libgcj failure: gcj linkage error.
    Incorrect library ABI version detected. Aborting.

    Aborted (core dumped)

Perhaps trang or one of its dependencies needs to be rebuilt?

Related branches

Revision history for this message
Kay Bærulfsen (berulfsen) wrote :

Im having the same problem with trang on my updated gutsy amd64.

Version: 20030619-5.1ubuntu2

Revision history for this message
Rasmus Kaj (kaj-kth) wrote :

Perhaps trang could be packaged for use with a jvm instead of compiled to native code? Maybe as a package option?

Revision history for this message
James Henstridge (jamesh) wrote :

I just tried recompiling trang locally, and it still segfaults. There were a huge number of warnings (which are also visible in the build log). Most seem to be related to not using Enumeration and Hashtable in a parameterised fashion. I don't know if that is related.

Revision history for this message
Rasmus Kaj (kaj-kth) wrote :

Since the release of trang is from 2003, I would expect java 1.4 rather than 1.5 complience. Maybe adding -fsource=1.4 to the gcj arguments will help (or at least make it easier to spot any more serious warnings) ?

Revision history for this message
James Henstridge (jamesh) wrote :

-fsource=1.4 reduces the number of warnings, but it does not fix the segfaults.

One thing I did notice is that there are a number of Java class files that in the source package that appear to be in libgcj too (javax.xml.parsers.*), which is probably the problem. My guess is that the bug is due to the copies of the classes in the trang binary conflicting with the copies in libgcj.

I don't know enough about gcj to fix this myself, but maybe it is enough to point someone more knowledgeable in the right direction.

Revision history for this message
Cristóbal M. Palmer (cristobalpalmer) wrote :

I just experienced this too. Can we mark this confirmed please? What team should this go to?

-CMP

Revision history for this message
Steinar Bang (sb-dod) wrote :

I see this myself, on an Intel Pentium M (ie. x86), Ubuntu 7.10 installation,

Like the previous poster said: can it be marked as confirmed, please?

Rasmus Kaj (kaj-kth)
Changed in trang:
status: New → Confirmed
Revision history for this message
Christopher Warner (cwarner) wrote :

I can also confirm this bug

cwarner@cwarner-laptop [~/codespace/krangtoplone]: trang -I xml story_36491.xml blah.xsd
libgcj failure: gcj linkage error.
Incorrect library ABI version detected. Aborting.

Aborted (core dumped)

Revision history for this message
Michael Blakeley (mike+ubuntu) wrote :

Also in hardy:

trang/hardy uptodate 20030619-5.1ubuntu2
libgcj8-1/hardy uptodate 4.2.2-7ubuntu1

libgcj failure: gcj linkage error.
Incorrect library ABI version detected. Aborting.

Aborted (core dumped)

Revision history for this message
Barrakketh (barrakketh) wrote :

I'm using Gutsy x86 and also get the error:

libgcj failure: gcj linkage error.
Incorrect library ABI version detected. Aborting.

Aborted (core dumped)

Rebuilding the trang package (obtained via apt-get source) with pbuilder produces a working package. I tested it by converting the RELAX NG Specification to the compact version.

Revision history for this message
sam roberts (sroberts-uniserve) wrote :

@barrakketh

could you describe how to do this?
I tried apt-get source and then a dpkg-buildpackage and still go the incorrect library ABI detected error.

Revision history for this message
Barrakketh (barrakketh) wrote :

I said I used pbuilder.

That said, after nuking my pbuilder archives and creating a new one to ensure that I could reproduce a working build from scratch I noticed that trang was segfaulting on the new builds. I had originally assumed it was just a build environment problem that was preventing it from working on my live system, but as it turns out my default pbuilder was still based on feisty which was enough to make it work.

So feisty is capable of building the package that works (for me, at least) on gutsy. And it is built with the source package provided by gutsy. So here are the instructions:

Install pbuilder (if you haven't already)
sudo pbuilder create --distribution feisty
sudo pbuilder build trang.dsc #whichever is appropriate for the build

The package will be placed in /var/cache/pbuilder/result/

Revision history for this message
Reuben Thomas (rrt) wrote :

trang should be removed from hardy if a solution cannot be found as it's currently useless: you can't run it. At the moment the Debian package has the same problem (even in a slightly newer version) and is orphaned. This is a pity, as I can't find another tool to do the same job.

Daniel T Chen (crimsun)
Changed in trang:
assignee: nobody → crimsun
importance: Undecided → Medium
status: Confirmed → Fix Committed
Revision history for this message
Daniel T Chen (crimsun) wrote :
Revision history for this message
Paul Natsuo Kishimoto (khaeru) wrote :

I tried the solution suggested by barrakketh without success on 7.10 and x86:

sudo apt-get install pbuilder
sudo pbuilder create --distribution feisty
sudo apt-get source trang
sudo pbuilder build trang*.dsc
sudo dpkg --install /var/cache/pbuilder/result/trang*.deb

dpkg complains about an unsatisfied dependency on libgcj7-0 (gutsy has libgcj7-1 instead). Even if I install libgcj7-1 and run dpkg again with --force-depends, when I try to run trang I get:

trang: error while loading shared libraries: libgcj.so.70: cannot open shared object file: No such file or directory

Symlinking /usr/lib/libgcj.so.70 to /usr/lib/libgcj.so.71 produces screenfuls of garbage. The package seems thoroughly broken.

Incidentally I found http://www.postneo.com/2007/01/16/all-i-want-to-do-is-convert-my-schema which provided some suggestions, none of which worked for RNC->RNG conversion.

Revision history for this message
Martin Pitt (pitti) wrote :

Keeping in unapproved until MOTU Release team gives ack.

Revision history for this message
Scott Kitterman (kitterman) wrote :

Ack from motu-release.

Revision history for this message
Cesare Tirabassi (norsetto) wrote :

[22:14] <norsetto> crimsun: I have no idea what -findirect-dispatch does, but I guess you tested this with success?
[22:15] <crimsun> norsetto: yes. It's taken from the Debian change by Barry.
[22:15] <norsetto> crimsun: I see, perhaps you should mention it in the changelog? Do we also need the -O2 -g in there?
[22:15] <stani> pochu: other question do I have to add pkg-config to build-depends as well?
[22:16] <crimsun> norsetto: yes, because I didn't wish to patch Makefile, which is more cumbersome, as well.
[22:17] <norsetto> crimsun: ok, but perhaps we should then do something similar to what we do for the CFLAGS
[22:18] <norsetto> crimsun: for the optimisation flag I mean
[22:18] <crimsun> sure, I'll rediff.
[22:26] <crimsun> norsetto: updated debdiff attached, thanks.
[22:55] <norsetto> crimsun: have you built this in a ppa? Trying to build it locally just trashes my hd to death
[22:59] <crimsun> norsetto: I've tried twice to build it locally. I gave up after, each time, it ate through all RAM and swap. I finally got work permission to build it on a machine there. It eats about 6 GB.
[23:01] <norsetto> crimsun: right, god bless java ....
[23:03] <norsetto> crimsun: ok, go on with that bloated thing
[23:06] <crimsun> norsetto: to be clear, is that an "ok to upload" for #141447?
[23:06] <norsetto> crimsun: roger
[23:06] <crimsun> thanks

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package trang - 20030619-5.1ubuntu3

---------------
trang (20030619-5.1ubuntu3) hardy; urgency=low

  * debian/rules: Prepend -findirect-dispatch to GCJFLAGS
    (LP: #141447). This fix makes trang usable (vice aborting
    immediately upon invocation) again. Picked from 20030619-6
    in Debian.

 -- Daniel T Chen <email address hidden> Sun, 13 Apr 2008 17:04:32 -0400

Changed in trang:
status: Fix Committed → Fix Released
Revision history for this message
James Henstridge (jamesh) wrote :

The package may not be segfaulting immediately when run, but it still seems broken. I tested it out with a simple RELAX-NG compact syntax schema:

    start = element foo { text }

I then tried converting it to a RELAX-NG XML syntax schema using trang 20030619-5.1ubuntu3 (on amd64), and got the following:

    $ trang foo.rnc foo.rng
    Exception in thread "main" java.lang.NullPointerException
       at org.relaxng.datatype.helpers.DatatypeLibraryLoader$Service$Loader2.getResources(libgcj_bc.so.1)
       at org.relaxng.datatype.helpers.DatatypeLibraryLoader$Service.<init>(libgcj_bc.so.1)
       at org.relaxng.datatype.helpers.DatatypeLibraryLoader.<init>(libgcj_bc.so.1)
       at com.thaiopensource.relaxng.input.parse.ParseInputFormat.load(trang)
       at com.thaiopensource.relaxng.translate.Driver.doMain(trang)
       at com.thaiopensource.relaxng.translate.Driver.main(trang)

I'll test to see if the same thing occurs on x86 after updating my laptop.

Changed in trang:
status: Fix Released → Confirmed
Revision history for this message
James Henstridge (jamesh) wrote :

I see that the i386 package build failed. I also tried building the version from Debian but saw the same error.

I do notice that the version of DatatypeLibraryLoader being used is the one from libgcj_bc.so rather than trang's one. I don't know if that makes a difference, but it might cause problems loading the resource files. I'm out of my depth in debugging this.

Revision history for this message
arno_b (arno.b) wrote :

The same problem for; after the update I have the same NullPointerException.

Changed in trang:
status: Unknown → Fix Released
Revision history for this message
James Henstridge (jamesh) wrote :

Looks like a new upstream Debian package is broken in the same way as the new Ubuntu package, and a new bug has been filed.

Changed in trang:
status: Unknown → New
Revision history for this message
sam roberts (sroberts-uniserve) wrote :

The trivial way to fix this really is to just use the java version, rather than the gcj version compiled to local machine code. Its not exactly performance critical piece of software.

We downloaded the upstream, and run the trang.jar file included, it works fine.

Revision history for this message
arno_b (arno.b) wrote :

Seems to be fixed for me on hardy.
Someone can confirm that?

Revision history for this message
James Henstridge (jamesh) wrote :

It is broken for me on Hardy (version 20030619-5.1ubuntu4, both x86 and amd64), giving the same error. Arnaud: how did you test the problem?

I'll give it another shot on Intrepid when I get a chance to upgrade a machine.

Revision history for this message
arno_b (arno.b) wrote :

Oops sorry, in fact it is still broken for me on hardy:
Exception in thread "main" java.lang.NullPointerException
*** Got java.lang.NullPointerException while trying to print stack trace.

Revision history for this message
James Henstridge (jamesh) wrote :

I've just tried trang under Intrepid (version 20030619-6.1), and got the same NullPointerException as seen on Hardy.

Changed in trang (Debian):
status: New → Fix Released
Revision history for this message
James Henstridge (jamesh) wrote :

Looks like this bug has been fixed in Lucid. The trang package in that release is a java bytecode version rather than native code, and passes the simple test I listed in comment #21.

Revision history for this message
David Futcher (bobbo) wrote :

Based on the last comment, I'm going to make this as Fix Released. If this is still an issue for anyone, please re-open this bug.

Changed in trang (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.