After re-emerge'ing swi-prolog (see bug #133997) I found another bug related to package JPL. It works well only with non-GUI code; any attempt to use Swing classes causes the underlying Prolog to crash. As an example, if the FamilyMT example is changed like this: public static void main(String argv[]) { Query q1 = new Query("consult(family)"); System.err.println("consult " + (q1.hasSolution() ? "succeeded" : "failed")); // This line crashes the Prolog engine! JOptionPane.showMessageDialog( null, "About to create threads!" ); for (int i = 0; i < 20; i++) { System.out.println("spawning client[" + i + "]"); new FamilyMT(i).start(); } } Running run.sh gives the following output: JPL demo: FamilyMT % family compiled 0.00 sec, 1,832 bytes consult succeeded [PROLOG SYSTEM ERROR: Thread 1 Recursively received fatal signal 11 PROLOG STACK: ] Action? [typed an 'e'] ERROR: Caught signal 11 (segv) The error occurs precisely where the Swing code is called (and the Swing thread is created). I am using Blackdown JDK 1.4.2.
Here is my "emerge --info". I re-emerge'd blackdown-jdk after adding "threads" to the USE variable (see bug #133997). Portage 2.1_rc2-r2 (default-linux/amd64/2006.0, gcc-3.4.6, glibc-2.3.5-r2, 2.6.16-gentoo-r6 x86_64) ================================================================= System uname: 2.6.16-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://www.las.ic.unicamp.br/pub/gentoo/ ftp://ftp.las.ic.unicamp.br/pub/gentoo/ http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo " LINGUAS="pt_BR eo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.samerica.gentoo.org/gentoo-portage" USE="amd64 X aim alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts cdparanoia cli crypt cups doc dri dvd dvdr emacs encode flac foomaticdb ftp gif gpm gstreamer imlib innodb ipv6 isdnlog jabber java javascript jpeg junit kde kdeenablefinal lzw lzw-tiff mad mime mozilla mp3 mpeg msn mule mysql ncurses nls nptl nsplugin offensive ogg opengl pam pdf pdflib php png postgres qt quicktime readline reflection sdl session soap sockets spell spl ssl svg tcpd tetex threads tidy tiff truetype-fonts type1-fonts unicode usb vcd videos vorbis xml xmlrpc xmms xorg xpm xv zlib elibc_glibc kernel_linux linguas_pt_BR linguas_eo userland_GNU" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
SWI-Prolog's manual says something about thread libraries: external (C) applications should be compiled with the same library used by SWI. It seems that SWI only uses pthreads, not NTPL, which (I guess) is used by the JDK. Reference: http://gollem.science.uva.nl/SWI-Prolog/Manual/foreignthread.html
It looks like the prolog engine's signal-handler is catching a signal, but it's difficult to determine whether prolog _needs_ to handle this signal; it's quite possible that another process is waiting/prepared to handle this signal. Your testcase works ok on x86, but in the meantime I can provide a few things for you to try: 1) We can get a little more debugging information by editing your testcase in order to pass a debuglevel to the prolog engine. Run your testcase with the addition of: public static void main(String argv[]) { String[] args = {"pl", "-d", "9", "-g", "true"}; JPL.init(newArgs); Query q1 = new Query("consult(family)"); 2) Add "--disable-segv-handling" to the call to econf in src_compile in the swi-prolog ebuild. Re-emerge swi-prolog and try your testcase (with the extra debugging info from 1)). 3) Ensure that the prolog engine will not handle signals. Alter your testcase to explicitely initialize the prolog engine in FamilyMT.java: public static void main(String argv[]) { String[] args = {"pl", "-d", "9", "-nosignals", "-g", "true"}; JPL.init(newArgs); Query q1 = new Query("consult(family)"); This should hopefully let us know if the prolog engine's signal handler is catching an errant signal or if we need to dig deeper. (SWI-Prolog can be built with either of the LinuxThreads and NTPL implementations of POSIX threads (pthread)). Keri.
Hi again, Keri. Thanks for the prompt answer. My code worked with the -nosignals flag. No recompilation was necessary. Here is the complete initialization line: JPL.init( new String[] { "pl", "-q", "-nosignals", "-L0", "-g", "true" } ); Now I owe you 2 beers :^) -- Mois
Hi again, Keri. Thanks for the prompt answer. My code worked with the -nosignals flag. No recompilation was necessary. Here is the complete initialization line: JPL.init( new String[] { "pl", "-q", "-nosignals", "-L0", "-g", "true" } ); Now I owe you 2 beers :^) -- Moisés
