Bug 149537

Summary: exception updating eclipse.db on %post on x86_64
Product: [Fedora] Fedora Reporter: Alexandre Oliva <oliva>
Component: eclipseAssignee: Andrew Overholt <overholt>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: ziga.mahkovec
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-11 17:52:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alexandre Oliva 2005-02-23 20:51:25 UTC
Description of problem:
Removing all of:

eclipse-ecj-3.0.1_fc-14
eclipse-platform-3.0.1_fc-14
eclipse-jdt-3.0.1_fc-14
eclipse-pde-3.0.1_fc-14
libswt3-gtk2-3.0.1_fc-14

removes /usr/lib64/eclipse/eclipse.db, as expected.  If you re-install
them, the %post scripts print:

Preparing packages for installation...
eclipse-ecj-3.0.1_fc-14
error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException: eclipse.db
error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException: eclipse.db
error: %post(eclipse-ecj-3.0.1_fc-14.x86_64) scriptlet failed, exit
status 2
eclipse-jdt-3.0.1_fc-14
error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException: eclipse.db
[lost of the same]
error: %post(eclipse-jdt-3.0.1_fc-14.x86_64) scriptlet failed, exit
status 2
eclipse-platform-3.0.1_fc-14
error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException: eclipse.db
[lost of the same]
error: %post(eclipse-platform-3.0.1_fc-14.x86_64) scriptlet failed,
exit status 2
eclipse-pde-3.0.1_fc-14
error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException: eclipse.db
[lost of the same]
error: %post(eclipse-pde-3.0.1_fc-14.x86_64) scriptlet failed, exit
status 2
libswt3-gtk2-3.0.1_fc-14
error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException: eclipse.db
error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException: eclipse.db
error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException: eclipse.db
error: %post(libswt3-gtk2-3.0.1_fc-14.x86_64) scriptlet failed, exit
status 2

The %post failure has resulted in my having half a dozen different
versions of libswt3-gtk2 while tracking rawhide for a few weeks with
up2date.

If I then run:

rm -f /usr/lib64/eclipse/eclipse.db; gcj-dbtool4 -n
/usr/lib64/eclipse/eclipse.db 80000; for j in `find /usr/share/eclipse
-name \*.jar`; do  echo $j;   gcj-dbtool4 -a
/usr/lib64/eclipse/eclipse.db $j /usr/lib64/eclipse/`basename $j`.so; done

it prints a list of files, and the error I get is:

error: could not update /usr/lib64/eclipse/eclipse.db:
java.lang.IllegalArgumentException:
/usr/lib64/eclipse/resources.jar.so is not a file

the gcj-dbtool4 invocation works for all other .jar files listed by
the command above.

Version-Release number of selected component (if applicable):
eclipse-3.0.1_fc-14

How reproducible:
Always

Comment 1 Ziga Mahkovec 2005-02-24 22:25:10 UTC
I reproduced this on i386.  eclipse-ecj-3.0.1_fc-14 and some other packages
bundle an empty eclipse.db database which, when tested, results in:

$ rpm2cpio eclipse-ecj-3.0.1_fc-14.i386.rpm | \
  cpio -ivd ./usr/lib/eclipse/eclipse.db
$ gcj-dbtool4 -t ./usr/lib/eclipse/eclipse.db
java.lang.IllegalArgumentException: eclipse.db
   at gnu.gcj.runtime.PersistentByteMap.PersistentByteMap(...) (...)
   at gnu.java.lang.MainThread.call_main() (...)
   at gnu.java.lang.MainThread.run() (/usr/lib/libgcj_fc4.so.6.0.0)

A quick check reveals that the problem is in a magic word mismatch -- the magic
word was changed recently [1] from 0x12345678 to 0x67636a64 ("gcjd").  Looks
like the bundled databases need an update.

[1]
http://savannah.gnu.org/cgi-bin/viewcvs/gcc/gcc/libjava/gnu/gcj/runtime/PersistentByteMap.java.diff?r1=1.3&r2=1.4

Comment 2 Andrew Overholt 2005-03-08 17:54:43 UTC
Is this fixed with out new 3.1 builds?

Comment 3 Ziga Mahkovec 2005-03-08 18:20:11 UTC
WORKSFORME.
Looks like the build system simply needed a gcc-java upgrade, since
the databases are created in %install.

Comment 4 Alexandre Oliva 2005-03-11 17:52:49 UTC
Yup, fixed.