Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 429716 - net-p2p/freenet-0.7.5_p1409 - WrapperManager Error: Error in WrapperListener.start callback. // java.lang.AbstractMethodError: com.db4o.internal.query.ObjectSetFacade.iterator
Summary: net-p2p/freenet-0.7.5_p1409 - WrapperManager Error: Error in WrapperListener....
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Thomas Sachau
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-03 20:02 UTC by Justus Ranvier
Modified: 2012-10-14 10:29 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Justus Ranvier 2012-08-03 20:02:39 UTC
During a completely fresh install of Freenet I get the following error during the setup wizard just after the "Physical Security" step:

Internal error: please report

java.lang.AbstractMethodError: com.db4o.internal.query.ObjectSetFacade.iterator()Ljava/util/Iterator;
	at freenet.client.async.ClientRequestScheduler.loadKeyListeners(ClientRequestScheduler.java:114)
	at freenet.node.NodeClientCore.initKeys(NodeClientCore.java:539)
	at freenet.node.NodeClientCore.lateInitDatabase(NodeClientCore.java:656)
	at freenet.node.Node.lateSetupDatabase(Node.java:2685)
	at freenet.clients.http.wizardsteps.SECURITY_PHYSICAL.setThreatLevel(SECURITY_PHYSICAL.java:278)
	at freenet.clients.http.wizardsteps.SECURITY_PHYSICAL.postStep(SECURITY_PHYSICAL.java:255)
	at freenet.clients.http.FirstTimeWizardToadlet.handleMethodPOST(FirstTimeWizardToadlet.java:231)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at freenet.clients.http.ToadletContextImpl.handle(ToadletContextImpl.java:550)
	at freenet.clients.http.SimpleToadletServer$SocketHandler.run(SimpleToadletServer.java:988)
	at freenet.support.PooledExecutor$MyThread.realRun(PooledExecutor.java:234)
	at freenet.support.io.NativeThread.run(NativeThread.java:130)

Refreshing the browser window allows the wizard to continue, however all subsequent attempts to start Freenet result in the following console output:

Running Freenet 0.7...
wrapper  | --> Wrapper Started as Console
wrapper  | Java Service Wrapper Community Edition 64-bit 3.5.14
wrapper  |   Copyright (C) 1999-2011 Tanuki Software, Ltd. All Rights Reserved.
wrapper  |     http://wrapper.tanukisoftware.com
wrapper  | 
wrapper  | The value of wrapper.java.command does not appear to be a java binary.
wrapper  | The use of scripts is not supported. Trying to continue, but some features may not work correctly..
wrapper  | Launching a JVM...
jvm 1    | WrapperManager: Initializing...
jvm 1    | freenet.jar built with freenet-ext.jar Build #29 running with ext build 29
jvm 1    | Creating config from freenet.ini
jvm 1    | Creating logger...
jvm 1    | Set interval to 10 and multiplier to 1
jvm 1    | Starting executor...
jvm 1    | Finding old log files. New log file is /var/freenet/logs/freenet-1409-2012-08-03-14.log.gz
jvm 1    | Attempting to load the NativeThread library [NativeThread]
jvm 1    | Using the NativeThread implementation (base nice level is 10)
jvm 1    | Old log file exists for this time period: /var/freenet/logs/freenet-1409-2012-08-03-14.log.gz
jvm 1    | Renaming to: /var/freenet/logs/freenet-1409-2012-08-03-14-1.log.gz
jvm 1    | Created log files
jvm 1    | Initializing Node using Freenet Build #1409 r@unknown@ and freenet-ext Build #29 r with Sun Microsystems Inc. JVM version 1.6.0_33 running on amd64 Linux 3.4.7+
jvm 1    | Starting FProxy on 127.0.0.1,0:0:0:0:0:0:0:1:8888
jvm 1    | NOTICE: Resource name [net/i2p/util/libjbigi-linux-x86_64.so] was not found
jvm 1    | INFO: Optimized native BigInteger library 'jbigi-linux-x86_64' loaded from somewhere in the path
jvm 1    | Optimise native queries: true
jvm 1    | Query activation depth: 1
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:53] 
jvm 1    |  '/var/freenet/node.db4o' opened O.K.
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:53] 
jvm 1    |  '/var/freenet/node.db4o' close request
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:54] 
jvm 1    |  '/var/freenet/node.db4o' closed
jvm 1    | Defragmenting persistent downloads database.
jvm 1    | Optimise native queries: true
jvm 1    | Query activation depth: 1
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:54] 
jvm 1    |  '/var/freenet/node.db4o.tmp' opened O.K.
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:54] 
jvm 1    |  File not found: '/var/freenet/node.db4o' Creating new file
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:55] 
jvm 1    |  '/var/freenet/node.db4o' opened O.K.
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:58] 
jvm 1    |  '/var/freenet/node.db4o.tmp' close request
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:58] 
jvm 1    |  '/var/freenet/node.db4o.tmp' closed
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:58] 
jvm 1    |  '/var/freenet/node.db4o' close request
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:54:59] 
jvm 1    |  '/var/freenet/node.db4o' closed
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:55:01] 
jvm 1    |  '/var/freenet/node.db4o' opened O.K.
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:55:01] 
jvm 1    |  '/var/freenet/node.db4o' close request
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:55:02] 
jvm 1    |  '/var/freenet/node.db4o' closed
jvm 1    | Finalising defragmentation...
jvm 1    | Securely deleting /var/freenet/node.db4o.map which is of length 1429 bytes...
jvm 1    | Securely deleting /var/freenet/node.db4o.tmp which is of length 14888 bytes...
jvm 1    | Defragment completed. 14.5 KiB (14888) -> 7.63 KiB (7816) (47% shrink)
jvm 1    | Optimise native queries: true
jvm 1    | Query activation depth: 1
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:55:04] 
jvm 1    |  '/var/freenet/node.db4o' opened O.K.
jvm 1    | FNP port created on 0.0.0.0:46503
jvm 1    | Retrieved database handle for node on port 46503: 8014259364434314452
jvm 1    | Testnet mode DISABLED. You may have some level of anonymity. :)
jvm 1    | Note that this version of Freenet is still a very early alpha, and may well have numerous bugs and design flaws.
jvm 1    | In particular: YOU ARE WIDE OPEN TO YOUR IMMEDIATE PEERS! They can eavesdrop on your requests with relatively little difficulty at present (correlation attacks etc).
jvm 1    | Creating PeerManager
jvm 1    | No darknet peers file found.
jvm 1    | Memory is 113 MiB (119341056 bytes)
jvm 1    | Moderate memory pressure, setting 300 thread limit. Increase your memory limit in wrapper.conf if possible.
jvm 1    | Created new restart jobs queue
jvm 1    | Deleted 675 of 675 temporary files (0 non-temp files in temp directory) in 0s
jvm 1    | WrapperManager Error: Error in WrapperListener.start callback.  java.lang.AbstractMethodError: com.db4o.internal.query.ObjectSetFacade.iterator()Ljava/util/Iterator;
jvm 1    | WrapperManager Error: java.lang.AbstractMethodError: com.db4o.internal.query.ObjectSetFacade.iterator()Ljava/util/Iterator;
jvm 1    | WrapperManager Error:        at freenet.client.async.PersistentStatsPutter.restorePreviousData(PersistentStatsPutter.java:44)
jvm 1    | WrapperManager Error:        at freenet.node.NodeClientCore.<init>(NodeClientCore.java:224)
jvm 1    | WrapperManager Error:        at freenet.node.Node.<init>(Node.java:1745)
jvm 1    | WrapperManager Error:        at freenet.node.NodeStarter.start(NodeStarter.java:175)
jvm 1    | WrapperManager Error:        at org.tanukisoftware.wrapper.WrapperManager$11.run(WrapperManager.java:4006)
jvm 1    | Shutting down...
jvm 1    | Stopping database jobs...
jvm 1    | Rolling back unfinished transactions...
jvm 1    | Closing database...
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:55:06] 
jvm 1    |  '/var/freenet/node.db4o' close request
jvm 1    | Completed writing logs to disk.
jvm 1    | [db4o 7.4.79.12493   2012-08-03 14:55:07] 
jvm 1    |  '/var/freenet/node.db4o' closed
wrapper  | <-- Wrapper Stopped


Reproducible: Always
Comment 1 Thomas Sachau gentoo-dev 2012-08-04 08:34:29 UTC
Please give me the following details:

-exact name of the java package you are using (e.g. dev-java/sun-jdk-1.6.0.33-r2)
-exact version of java-service-wrapper
-output of eselect java-vm list
Comment 2 Justus Ranvier 2012-08-04 11:53:07 UTC
dev-java/sun-jdk-1.6.0.33
dev-java/java-service-wrapper-3.5.14-r1

Available Java Virtual Machines:
  [1]   sun-jdk-1.6  system-vm
Comment 3 Dennis Nezic 2012-08-04 12:29:06 UTC
Same problem here.

* dev-java/sun-jdk-1.6.0.29
* dev-java/java-service-wrapper-3.5.14-r1, 3.3.3)
Comment 4 Thomas Sachau gentoo-dev 2012-08-04 19:54:08 UTC
This looks like some really strange bug, which only seems to happen for certain setups or computers, but not for others.

Can you post your emerge --info? 

And just a hint, when you get your node running: Since you posted your wrapper.log with node ports, you might want to start a fresh setup, if you dont want people to assign it to your bugzilla account.
Comment 5 Justus Ranvier 2012-08-04 20:00:54 UTC
Portage 2.2.0_alpha120 (!/usr/site-local/portage/profiles/local/desktop/, gcc-4.6.3, glibc-2.14.1-r3, 3.4.7+ x86_64)
=================================================================
System uname: Linux-3.4.7+-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q8200_@_2.33GHz-with-gentoo-2.1
Timestamp of tree: Sat, 04 Aug 2012 07:45:01 +0000
distcc 3.1 x86_64-pc-linux-gnu [disabled]
app-shells/bash:          4.2_p20
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.7.3-r2, 3.2.3
dev-util/cmake:           2.8.7-r5
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.1-r1
sys-apps/openrc:          0.10.5
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.11.1
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            4.6.3
sys-devel/gcc-config:     1.6
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 3.5 (virtual/os-headers)
sys-libs/glibc:           2.14.1-r3
Repositories: gentoo lithium x11 roslin bitcoin v-fox kde local_repository
Installed sets: @basic-programs-intel, @kde-local
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=native"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/app-defaults /usr/share/config /usr/share/config/kdm/ /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ImageMagick /etc/NetworkManager /etc/OpenCL /etc/UPower /etc/X11/Sessions /etc/ca-certificates.conf /etc/dbus-1 /etc/env.d /etc/env.d/java/ /etc/fonts /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/init.d /etc/logrotate.d /etc/lvm /etc/polkit-1 /etc/portage/savedconfig /etc/pulse/ /etc/revdep-rebuild /etc/sandbox.d /etc/ssl /etc/terminfo /etc/xdg /usr/share/config"
CXXFLAGS="-O2 -pipe -march=native"
DISTDIR="/usr/site-local/distfiles"
EMERGE_DEFAULT_OPTS="--ask --jobs --load-average 6.4 --keep-going"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news nostrip parallel-fetch parse-eapi-ebuild-head preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://gentoo.mirrors.pair.com/ ftp://gentoo.mirrors.pair.com/"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en en_US en_UTF8"
MAKEOPTS="-j8 -l6.4"
PKGDIR="/usr/site-local/portage/package.amd64"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /var/lib/layman/x11 /var/lib/layman/roslin /var/lib/layman/bitcoin /var/lib/layman/v-fox /var/lib/layman/kde /usr/site-local/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi alsa amd64 amr atmo autotrace avahi bash-completion berkdb bluetooth branding bs2b bzip2 cairo cdda cddb cdparanoia cdr cli consolekit cracklib crypt cups cxx dbus declarative digitalradio dirac djvu dri dts dvb dvd dvdr emboss emovix encode exif faac fam ffmpeg fftw firefox flac fortran frei0r ftp gdbm gif gme gpm graphviz gs gsm gstreamer hdri iconv icu id3tag imagemagick inotify iplayer iproute2 ipv6 java jbig jpeg jpeg2k kate kde kerberos kipi ladspa lame lcms libass libnotify libsamplerate libv4l libv4l2 live lm_sensors lzma lzo mad matroska midi mjpeg mmx mng modplug modules mp3 mp3rtp mp4 mpeg mpg123 mtp mudflap multilib musepack musicbrainz nas ncurses nls nptl nsplugin ntp nut nuv offensive ogg openal openexr opengl openmp pam pango pcre pdf phonon pic plasma png pnm policykit ppds pppd projectm pulseaudio pvr qt3support qt4 quicktime radio raw readline rle rtmp rtsp scale0tilt schroedinger sdl session shout smp speex spell sqlite sse sse2 sse4_1 ssl ssse3 startup-notification svg syslog taglib tcpd tga theora threads thumbnail tiff truetype udev udisks unicode upower usb v4l v4l2 vcd vcdx video vorbis vpx wavpack webgl webkit wmf wxwidgets x264 xanim xattr xcb xcomposite xine xinerama xml xosd xscreensaver xulrunner xv xvid zeroconf zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" DRACUT_MODULES="btrfs crypt lvm" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US en_UTF8" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 6 Thomas Sachau gentoo-dev 2012-08-04 20:09:55 UTC
Also, what kernel are you running?
Comment 7 Justus Ranvier 2012-08-04 20:14:42 UTC
I use the latest stable version from kernel.org. My version number says 3.4.7+ because I've patched the Makefile to set KBUILD_OUTPUT but besides that it's identical to the stable tree.
Comment 8 Dennis Nezic 2012-08-05 00:34:43 UTC
It does look like a really strange bug indeed. Recompiling build #1407 with the java-service-wrapper I originally was using (3.3.3) produces the same error.

/me puts on thinking cap and begins investigating deeper.
Comment 9 Dennis Nezic 2012-08-10 00:33:21 UTC
The only thing that changed on my system, since my working build1407 months ago, judging by my emerge.log is mainly:

net-p2p/freenet-0.7.5_p1407 to /
dev-libs/libffi-3.0.11 to /
dev-libs/elfutils-0.154 to /
dev-perl/XML-Parser-2.410.0 to /
dev-util/intltool-0.50.2 to /
dev-libs/glib-2.32.3 to /
dev-util/pkgconfig-0.26 to /
dev-libs/libxml2-2.8.0-r1 to /

So surely one of these suspects is the culprit? Perhaps whoever else is having this weird bug, can check their emerge.log to see if they upgraded one of these packages as well? Perhaps they can try recompiling 1407 to see if that works?

The actual (wrapper.log) error seems to be related to the dev-java/db4o-jdk-7.4 -- i.e. that's where com/db4o/internal/query/ObjectSetFacade.java is from. I think this AbstractMethodError is usually the result of some kind of version/binary incompatibility, but how/where? :S
Comment 10 Thomas Sachau gentoo-dev 2012-08-12 09:52:58 UTC
(In reply to comment #9)
> The only thing that changed on my system, since my working build1407 months
> ago, judging by my emerge.log is mainly:
> 
> net-p2p/freenet-0.7.5_p1407 to /
> dev-libs/libffi-3.0.11 to /

I also have this in my list.

> dev-libs/glib-2.32.3 to /

i have dev-libs/glib-2.30.3 in my list

> dev-libs/libxml2-2.8.0-r1 to /

I have dev-libs/libxml2-2.8.0_rc1 in my list
> 
> So surely one of these suspects is the culprit? Perhaps whoever else is
> having this weird bug, can check their emerge.log to see if they upgraded
> one of these packages as well? Perhaps they can try recompiling 1407 to see
> if that works?

Recompiling 1407 does not change the results.

From my testings, i can confirm the results of the original reporter: Start a new node, do the wizard and once you have done the "Pysical Security" step, you will have a node not any more starting.

The main problem i see here is the following:

I have 1 node affected and another node running fine, they both use the same db4o version and the same version of java-service-wrapper.

Beside that, neither the jdk version or package nor the kernel seems to be related.

So for now, i dont know, how to find out the reason for this, so cant suggest or commit a fix at the moment. If someone else has a hint or finds a reason, please  provide it.
Comment 11 Dennis Nezic 2012-08-12 11:35:36 UTC
So we've possibly narrowed the problem down to:

dev-libs/libffi-3.0.11
dev-libs/glib-2.3[0-2]
dev-libs/libxml2-2.8

I.e. your working node didn't have thos packages upgraded? Maybe you can try upgrading them, (low-level ones first), to see which one (probably) causes it? :)
Comment 12 Thomas Sachau gentoo-dev 2012-08-12 19:42:54 UTC
(In reply to comment #11)
> So we've possibly narrowed the problem down to:
> 
> dev-libs/libffi-3.0.11
> dev-libs/glib-2.3[0-2]
> dev-libs/libxml2-2.8
> 
> I.e. your working node didn't have thos packages upgraded? Maybe you can try
> upgrading them, (low-level ones first), to see which one (probably) causes
> it? :)

I tried with the next older version of libffi and libxml2, but even with those, the issue still exists. And for glib, you seem to have a newer version then me, so unless you updated from <glib-2.30, it probably isnt the reason either.

My working node runs on a latest testing system, so has (or had) those versions too, but i did not see the issue there.
Comment 13 Dennis Nezic 2012-08-12 23:07:42 UTC
I upgraded from glib 2.24.2 and from libffi 3.0.9 -- none of which can easily be downgraded :S. This is so bizarre. What versions of those packages is your working "new" system using?
Comment 14 Thomas Sachau gentoo-dev 2012-08-13 17:21:13 UTC
My system with a working freenet node has the following for the 2:

dev-libs/libffi-3.0.11
dev-libs/glib-2.32.4
Comment 15 Dennis Nezic 2012-08-14 12:58:57 UTC
Well those 2 are a dead end. I have them as well, and it still doesn't work.

(Is your working machine an x86_64? Mine and Justus's are :p.)
Comment 16 Dennis Nezic 2012-08-15 02:54:38 UTC
It looks like a datastore corruption. Try starting with a fresh datastore, as suggested on the freenet-support mailing list :p.

But why are we all (all 3 of us :p) encountering this now, all at once?
Comment 17 Thomas Sachau gentoo-dev 2012-08-15 18:53:57 UTC
(In reply to comment #16)
> It looks like a datastore corruption. Try starting with a fresh datastore,
> as suggested on the freenet-support mailing list :p.
> 
> But why are we all (all 3 of us :p) encountering this now, all at once?

Obviously this is not related to a datastore corruption, since at least the original reporter and my node both show the issue, when creating a new node, which means no datastore at all there.
Comment 18 Dennis Nezic 2012-08-15 18:58:35 UTC
I was getting the exact same error. Now I am not. The only thing that changed now, I am sure, is I did a clean installation / or a recreated datastore. Now, why that worked for me and not for you is indeed incredibly bizarre. But surely it's related. (I'm running on the lowest security settings -- not sure if that matters.)
Comment 19 Thomas Sachau gentoo-dev 2012-08-15 20:52:33 UTC
ok, another detail:

When you remove the wizard line from freenet.ini and remove node.db4o/node.db4o.crypt (first step prevents that file from being recreated), then freenet does start again without that error.
Once you claim the wizard being finished or set the physical security level, that file gets created again (in which case you get the error in the wizard) and on each restart it again creates the error.
Comment 20 Dennis Nezic 2012-08-15 21:31:34 UTC
So how do you think I can reproduce the error? I have "fproxy.hasCompletedWizard=true" in freenet.ini, and my security levels are set.

When I tried a fresh installation, I think I also completed the wizard, and it was able to run and restart properly.

And how does this explain why I couldn't get 1407 to work -- that was a pretty stable build, that was working fine for many months before?

Are you able to reproduce this consistently, on all your machines?
Comment 21 Thomas Sachau gentoo-dev 2012-08-18 15:58:24 UTC
(In reply to comment #20)
> Are you able to reproduce this consistently, on all your machines?

One machine with reproducable error message and one machine working fine. But i cant find the difference, especially since db4o and wrapper versions are the same, while the jdk provider and version doesnt matter.
Comment 22 Thomas Sachau gentoo-dev 2012-08-19 11:53:33 UTC
(In reply to comment #18)
> I was getting the exact same error. Now I am not. The only thing that
> changed now, I am sure, is I did a clean installation / or a recreated
> datastore. Now, why that worked for me and not for you is indeed incredibly
> bizarre. But surely it's related. (I'm running on the lowest security
> settings -- not sure if that matters.)

Which parts of your system did you change between the time, when it failed and the time, when it worked again?

-kernel change?
-jdk/jre change?
-updates for packages in that timeframe?
-packages recompiled in that timeframe?
-changes to /etc/make.conf (for CC, CFLAGS or other vars)?
-profile changes?


Also, is it a headless system without X?
Comment 23 Dennis Nezic 2012-08-19 12:30:38 UTC
So, ever since I tried upgrading/restarting my node to build 1409 (the first time I encountered the error), I first tried deleting the node.db4o.crypt file. I then tried upgrading/recompiling the obvious dependencies db4o-jdk, ant-core, java-service-wrapper. I then tried recompiling all those with icedtea-bin instead of sun-java. I then tried recompiling every single immediate dependency. I then tried downgrading stuff as best I could to the last working environment, only to discover that 1407 doesn't even work.

There were never any profile changes, no changes to make.conf or the CCs. No kernel changes. Just a bunch of package recompiling/downgrading. It is headless -- no X.

However, it should be noted, that I rebuilt my datastore with icedtea-bin, and it's working with icedtea-bin now. However, icedtea-bin + my old datastore didn't work. I'm not sure if this is relevant, but maybe :p.

So, it works for me now, though. I would bet money that the problem is a freenet bug, that causes a datastore corruption caused by the 1409 build. All the signs point to it -- the fact that no other dependencies seem to be affecting the issue -- the fact that we all started seeing this error around the same time (when we tried upgrading to 1409, and never before) -- the fact that older builds no longer work. The only counter-evidence is that a clean install of older versions still reproduces this error for you guys? You guys have tried a clean reinstall (no datastore) with 1407? Although, this doesn't necessarily refute my theory. It could just be that whatever triggers the corruption only occurs under certain conditions.
Comment 24 Thomas Sachau gentoo-dev 2012-08-19 16:32:58 UTC
I get the same error, when i downgrade freenet to 1407 and remove everything except freenet.ini, run.sh and seednodes.fref.

Next try will be a full system rebuild.
Comment 25 Dennis Nezic 2012-08-19 20:19:37 UTC
Fascinating. In a scary way. Before you do that though, get rid of those 3 files as well. I can imagine lots of ways old freenet.ini settings could trigger this.
Comment 26 Thomas Sachau gentoo-dev 2012-08-19 22:45:25 UTC
(In reply to comment #25)
> Fascinating. In a scary way. Before you do that though, get rid of those 3
> files as well. I can imagine lots of ways old freenet.ini settings could
> trigger this.

-run.sh is just a nice wrapper to start and stop freenet, remove that and your init script is broken ;)

-seednodes.fref is required for opennet mode, otherwise the node has no way to know, where to get the initial connections from, so also vital

-this freenet.ini is a fresh one, since i moved the old folder away, it was newly created by freenet before it failed

I already tried before with just run.sh and seednodes.fref, the result was the same. And now, i did a complete rebuild of the system, but this did not change anything.

So i am again back to my previous conclusion and did not get any further:

This error seems to be related to node.db4o/node.db4o.crypt, since that file can cause the error, even when the wizard is not yet finished, but even moving a node.db4o from my working node over does not change the error, so does not look like the content of that file matters.

So still too many open questions:

-Why does it happen on some systems?
-Why does it not happen on other systems?
-Why is it gone for at least one system?

and most importantly:

-What is the real reason for this error?
Comment 27 adr 2012-10-03 12:15:28 UTC
Please try this in /etc/freenet-wrapper.conf, wrapper.java.classpath.2:

Move "/usr/share/db4o-jdk12/lib/db4o-jdk12.jar" earlier in the path, like:

...:/usr/share/db4o-jdk5/lib/db4o-jdk5.jar:/usr/share/db4o-jdk12/lib/db4o-jdk12.jar:/usr/share/db4o-jdk11/lib/db4o-jdk11.jar:...

They are dependencies. Not claiming this is the correct order though. :)
Comment 28 jonys 2012-10-13 15:41:37 UTC
I'm using freenet-0.7.5_p1417 and this bug is still present, but applying the workaround proposed in comment #27 (editing the CLASSPATH) made it work. Thanks!
Comment 29 adr 2012-10-13 19:24:18 UTC
These 3 jars contain duplicate class names. I guess the newest must override the older class versions. The numbering looked a bit odd to me, but it's in fact JDK-5, JDK-1.4 and JDK-1.2.

For older installs, the sudden outbreak of this bug may be related to a portage upgrade.

---- sys-apps/portage/ChangeLog: -----

*portage-2.1.10.61 (16 May 2012)

  (...) FEATURES=config-protect-if-modified is now enabled by default. This causes the CONFIG_PROTECT behavior to be skipped for files that have not been modified since they were installed.
  (...)

----
Comment 30 Thomas Sachau gentoo-dev 2012-10-14 09:22:11 UTC
(In reply to comment #29)
> These 3 jars contain duplicate class names. I guess the newest must override
> the older class versions. The numbering looked a bit odd to me, but it's in
> fact JDK-5, JDK-1.4 and JDK-1.2.
> 
> For older installs, the sudden outbreak of this bug may be related to a
> portage upgrade.
> 
> ---- sys-apps/portage/ChangeLog: -----
> 
> *portage-2.1.10.61 (16 May 2012)
> 
>   (...) FEATURES=config-protect-if-modified is now enabled by default. This
> causes the CONFIG_PROTECT behavior to be skipped for files that have not
> been modified since they were installed.
>   (...)
> 
> ----

I guess, you used wrong numbers, also you found the cause of the start failure: The oder should be jdk-5, jdk-12, jdk-11.

This does not look related to the mentioned portage Changelog entry, but seems to have a even more worrying reason:

The code in the ebuild seems to behave differently on different machines, while my working machine gets the order right, the failing machines create the wrong order for the jar files in the classpath, resulting in the start failure.
Comment 31 Thomas Sachau gentoo-dev 2012-10-14 10:29:20 UTC
seems like i finally found the issue, fixed in 0.7.5_p1419, which should be on your local rsync mirrors in a few hours