dev-lang/swi-prolog-lite contains a series of old prolog versions, deprecated in favour of dev-lang/swi-prolog. In order to be in the position to package.mask swi-prolog-lite and eventually remove it from the tree, I'd like to see where the alpha, ppc-macos and sparc arches stand with respect to the ebuilds in dev-lang/swi-prolog. Can the alpha, ppc-macos and sparc teams attempt to emerge swi-prolog-5.6.12 and report back any successes/failures. Thanks. Keri.
swi-prolog-5.6.12 marked ~ppc-macos. Sorry for the delay.
Created attachment 89042 [details] Failed tests with 5.6.13 Failed tests for sparc with 5.6.13.
Gustavo, thanks for taking the time to test this package. Thread handling is most likely failing due to an alignment issue. This warrants further investigation.
swi-prolog-5.6.14 marked ~alpha. All tests work fine.
And who will investigate? I can give you a shell account to check it out, but i kinda doubt anyone on the sparc team has the necessary time to do so.
If you could provide me with a shell account on a sparc box that would be great. I appreciate the fact that the sparc team has much more productive use of their time than wading through the internals of a prolog package. Thanks, Keri.
dev-lang/swi-prolog-5.6.17 builds on sparc with USE="X berkdb readline ssl tetex -doc -gmp -minimal -odbc -static -threads", with FEATURES=test, it runs all tests successfully. It installs, and xpce seems to run. For it to install, it has to work reasonably well because it uses itself in the install process. Hence, -5.6.17 is now ~sparc. Is this sufficient to satisfy the summary request?
Ah, I see where there is a problem. There is an alignment problem if you USE=threads. I think it can keep its ~sparc because it is certainly testable w/o threads, and unfortunately alignment problems with threads are rather common on sparc. A common failure looks like this: 1. Program packs up a bunch of random data items and passes a packed datastream to a thread; 2. The thread knows what the data stream looks like, and maps it onto the underlying structure. 3. Unfortunately, the thread did not align the stream in such a way that it unpacks nicely. 3a. In fact, sometimes it can't be so aligned: Some programs like to pack things sort of like this:<64-bits, 32-bits, 64-bits, 8-bits, 64-bits, ...> When this happens, the receiving program must be careful not to unpack using built-in mem copy functions and the correct data types because the compiler will "optimize" these moves into Segfaults. My experiences with random 3rd party software not developed in sparc suggest that the frequency of this sort of failure is up around 100%. :( Hence, I have set USE='-threads' globally because the default case seems to be that it's going to fail anyway.
By the way, the Bus errors seem to occur only in the packages/semweb test suite. Other tests do use threads without incident. (First test to fail is 'literal'). Unfortunately, gdb on sparc has lots of problems running threaded programs, and the pl program catches its signals, so I don't see how to force a core file.
(In reply to comment #9) > By the way, the Bus errors seem to occur only in the packages/semweb test > suite. Other tests do use threads without incident. (First test to fail is > 'literal'). > To make this explicit: (cd src; make check) (cd packages ; make PKG="chr clib clpqr cpp cppproxy db http ltx2htm nlp sgml sgml/RDF ssl table xpce" check) both work fine.
Thanks for taking the time to look at this! Having ~sparc w/o threads is sufficient to close this bug. Thanks, Keri.
After updating gdb to gdb-6.5-r1, I can get a back trace for the Bus error in the semweb test. Here it is: =========================== LD_LIBRARY_PATH="$srcdir/lib/sparc-linux-gnu" gdb $srcdir/pl GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-unknown-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -q -f rdf_db_test.pl -g test,halt -t 'halt(1)' Starting program: /var/tmp/portage/swi-prolog-5.6.17/work/pl-5.6.17/src/pl -q -f rdf_db_test.pl -g test,halt -t 'halt(1)' [Thread debugging using libthread_db enabled] [New Thread 1879158640 (LWP 25012)] RDF-DB test suite. To run all tests run ?- test. Running test set "resource" . done. Running test set "literal" Program received signal SIGBUS, Bus error. [Switching to Thread 1879158640 (LWP 25012)] compare_literals (p1=0x31dd0, p2=0x595a2, type=IS_LEAF) at rdf_db.c:1410 1410 literal *l2 = *(literal**)p2; (gdb) bt #0 compare_literals (p1=0x31dd0, p2=0x595a2, type=IS_LEAF) at rdf_db.c:1410 #1 0x70ef1820 in avl_find (data=0xefa6fc8c, tree=0x59598, compar=0x70ee4f20 <compare_literals>) at avl.c:370 #2 0x70ee98ec in link_triple_silent (db=0x5a0b0, t=0x31d78) at rdf_db.c:1505 #3 0x70ee9cf4 in rdf_assert4 (subject=324, predicate=325, object=326, src=369072) at rdf_db.c:1900 #4 0x70046a48 in PL_cvt_o_integer () from /usr/lib/pl-5.6.17/lib/sparc-linux-gnu/libpl.so.5.6.17 #5 0x70046a48 in PL_cvt_o_integer () from /usr/lib/pl-5.6.17/lib/sparc-linux-gnu/libpl.so.5.6.17 Previous frame identical to this frame (corrupt stack?) (gdb) list 1405 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */ 1406 1407 static int 1408 compare_literals(void *p1, void *p2, NODE type) 1409 { literal *l1 = *(literal**)p1; 1410 literal *l2 = *(literal**)p2; 1411 1412 if ( l1->objtype == l2->objtype ) 1413 { switch(l1->objtype) 1414 { case OBJ_INTEGER: ====================================== (And p2=0x595a2 is causing the problem)
Created attachment 94226 [details, diff] Strawman patch for fixing semweb for sparc when USE=threads With the attached patch applied, sparc runs all tests successfully with swi-prolog-5.6.17 and USE="threads ...". Patch as tested is very simple, so I duplicate it inline: ==================== --- pl-5.6.17/packages/semweb/avl.h- 2006-03-06 15:23:47.000000000 +0000 +++ pl-5.6.17/packages/semweb/avl.h 2006-08-14 12:25:49.000000000 +0000 @@ -58,7 +58,11 @@ /* structure for a node in an AVL tree */ typedef struct avl_node { struct avl_node *subtree[2]; /* LEFT and RIGHT subtrees */ +#ifndef __sparc__ short bal; /* balance factor */ +#else + long bal; /* balance factor */ +#endif char data[1]; /* data on my back */ } AVLnode, *AVLtree; ============================ Note that nothing changes for anything other thqan sparc.
Thanks for sorting this out. The underlying problem is due to a lack of robust unification when broadcasting new RDF literals between threads. I've applied the above patch until literal unification is fixed upstream. Keri
