From: Andrew P. <and...@gm...> - 2011-02-07 07:58:46
|
Hello, I am a budding Common Lisper. I was working on a cl-mechanize<https://github.com/joachifm/cl-mechanize> script to fill out an HTML form when I noticed that one of cl-mechanize's dependencies, cl+ssl <http://common-lisp.net/project/cl-plus-ssl/>, depends on CFFI. When I try to load cl-mechanize, which loads drakma, which loads cl+ssl, I get the following message: *** - CFFI requires CLISP compiled with dynamic FFI support. The problem seems to be that ffcall is not installed. When I try to install it with MacPorts, I get this message: $ sudo port install ffcall ---> Fetching ffcall ---> Attempting to fetch ffcall-1.10.tar.gz from http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/ffcall ---> Verifying checksum(s) for ffcall ---> Extracting ffcall ---> Configuring ffcall ---> Building ffcall Error: Target org.macports.build returned: shell command failed (see log for details) Log for ffcall is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ffcall/main.log Error: Status 1 encountered during processing. To report a bug, see <http://guide.macports.org/#project.tickets> Here are my specs: - cl-mechanize 0.0 (depends on drakma) - drakma 1.2.3 (depends on cl+ssl) - cl+ssl 2007 - Quicklisp 2010121400 (used to install common lisp packages) - CLISP 2.49 - ffcall 1.10 - MacPorts 1.9.2 - Mac OS X 10.6.6 - MacBook Pro 5,1 Thanks for your consideration, Andrew Pennebaker http://www.yellosoft.us/ |
From: Sam S. <sd...@gn...> - 2011-02-07 16:52:53
|
Hi, > * Andrew Pennebaker <naqerj.craaronxre@tznvy.pbz> [2011-02-07 02:58:19 -0500]: > > The problem seems to be that ffcall is not installed. When I try to install > it with MacPorts, I get this message: > > $ sudo port install ffcall > ---> Fetching ffcall > ---> Attempting to fetch ffcall-1.10.tar.gz from > http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/ffcall > ---> Verifying checksum(s) for ffcall > ---> Extracting ffcall > ---> Configuring ffcall > ---> Building ffcall > Error: Target org.macports.build returned: shell command failed (see log for > details) > Log for ffcall is at: > /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ffcall/main.log > Error: Status 1 encountered during processing. > To report a bug, see <http://guide.macports.org/#project.tickets> I think you should report the bug to macports and ask them to upgrade ffcall to the latest cvs version. 1.10 is largely obsolete; Bruno should release 1.11 eventually; he might do it sooner if you will write to him and ask him abou it. Good luck. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) http://www.PetitionOnline.com/tap12009/ http://ffii.org http://pmw.org.il http://thereligionofpeace.com http://honestreporting.com http://jihadwatch.org Never underestimate the power of stupid people in large groups. |
From: Carlos U. <car...@gm...> - 2011-02-07 20:42:42
|
Hi Sam, MacOS on Intel is not listed as supported by ffcall (http://cvs.savannah.gnu.org/viewvc/ffcall/PLATFORMS?revision=1.14&root=libffcall). I don't know if that file is up-to-date, but I can't find any references to the platform being supported in README, NEWS, or ChangeLog. Is it supossed to work? It won't for me (see below), but I've always thought that was the expected outcome... Cheers, Carlos $ cvs -z3 -d:pserver:ano...@cv...:/sources/libffcall co ffcall $ cd ffcall $ ./configure $ make cd avcall && make all gcc -E `if test true = true; then echo '-DASM_UNDERSCORE'; fi` ./avcall-i386-macro.S | grep -v '^ *#line' | grep -v '^#ident' | grep -v '^#' | sed -e 's,% ,%,g' -e 's,% ,%,g' -e 's,\. ,.,g' > avcall-i386.s /bin/sh ./libtool --mode=compile gcc -x none -c avcall-i386.s gcc -x none -c avcall-i386.s -o avcall-i386.o avcall-i386.s:7:suffix or operands invalid for `push' avcall-i386.s:9:suffix or operands invalid for `push' avcall-i386.s:10:suffix or operands invalid for `push' avcall-i386.s:39:suffix or operands invalid for `call' avcall-i386.s:47:suffix or operands invalid for `call' avcall-i386.s:53:suffix or operands invalid for `call' avcall-i386.s:168:suffix or operands invalid for `pop' avcall-i386.s:169:suffix or operands invalid for `pop' avcall-i386.s:171:suffix or operands invalid for `pop' make[1]: *** [avcall-i386.lo] Error 1 make: *** [all] Error 2 On Mon, Feb 7, 2011 at 5:52 PM, Sam Steingold <sd...@gn...> wrote: > Hi, > >> * Andrew Pennebaker <naqerj.craaronxre@tznvy.pbz> [2011-02-07 02:58:19 -0500]: >> >> The problem seems to be that ffcall is not installed. When I try to install >> it with MacPorts, I get this message: >> >> $ sudo port install ffcall >> ---> Fetching ffcall >> ---> Attempting to fetch ffcall-1.10.tar.gz from >> http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/ffcall >> ---> Verifying checksum(s) for ffcall >> ---> Extracting ffcall >> ---> Configuring ffcall >> ---> Building ffcall >> Error: Target org.macports.build returned: shell command failed (see log for >> details) >> Log for ffcall is at: >> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_ffcall/main.log >> Error: Status 1 encountered during processing. >> To report a bug, see <http://guide.macports.org/#project.tickets> > > I think you should report the bug to macports and ask them to upgrade > ffcall to the latest cvs version. > 1.10 is largely obsolete; Bruno should release 1.11 eventually; he might > do it sooner if you will write to him and ask him abou it. > > Good luck. > -- > Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) > http://www.PetitionOnline.com/tap12009/ http://ffii.org http://pmw.org.il > http://thereligionofpeace.com http://honestreporting.com http://jihadwatch.org > Never underestimate the power of stupid people in large groups. > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > clisp-list mailing list > cli...@li... > https://lists.sourceforge.net/lists/listinfo/clisp-list > |
From: Sam S. <sd...@gn...> - 2011-02-07 20:52:31
|
Hi Carlos, > * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-02-07 21:42:35 +0100]: > > MacOS on Intel is not listed as supported by ffcall > (http://cvs.savannah.gnu.org/viewvc/ffcall/PLATFORMS?revision=1.14&root=libffcall). > > Is it supossed to work? It won't for me (see below), but I've always > thought that was the expected outcome... probably not. http://www.cygwin.com/acronyms/#PTC -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) http://jihadwatch.org http://palestinefacts.org http://truepeace.org http://www.memritv.org http://mideasttruth.com http://iris.org.il I'm out of my mind, but feel free to leave a message... |
From: Didier V. <di...@lr...> - 2011-02-08 08:38:57
|
Carlos Ungil <car...@gm...> wrote: > MacOS on Intel is not listed as supported by ffcall > (http://cvs.savannah.gnu.org/viewvc/ffcall/PLATFORMS?revision=1.14&root=libffcall). > I don't know if that file is up-to-date, but I can't find any > references to the platform being supported in README, NEWS, or > ChangeLog. > > Is it supossed to work? On my Mac Book Pro (Intel Core i5) I have a working ffcall installed by Fink: didier(s002)% fink list | grep ffcall 9:36 02/08/11 i ffcall 1.10-5 Foreign function call libraries I've used CLISP with cffi on this machine without any problem. -- Resistance is futile. You will be jazzimilated. Scientific site: http://www.lrde.epita.fr/~didier Music (Jazz) site: http://www.didierverna.com |
From: Carlos U. <car...@gm...> - 2011-02-08 23:15:10
|
Hi Didier, thanks a lot for the pointer. It's good to know that FFI is availble for 32bit clisp on MacOSX. I've not investigated how is it exactly that fink manages to compile ffcall, but I've found that using that library and compiling from the latest source libsigsegv for 32bit (export CPPFLAGS=-m32 CFLAGS=-m32 LDFLAGS=-m32) I can compile the 32bit version of clisp 2.48 (the same release that is available via fink). Unfortunately the latest release (2.49) or the more recent CVS code (actually a few days old, the server seems unavailable right now) won't work. In the latter case, the compilation stops at the point shown below (the problem is at least similar to the one reported at http://comments.gmane.org/gmane.lisp.clisp.devel/16968, but maybe it's actually unrelated as that message is several years old...). Cheers, Carlos gcc -E -DASM_UNDERSCORE ari80386.c > ari80386.s gcc -m32 -I/usr/local/include -I/Users/ungil/lisp/clisp/src/gllib -m32 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT -I. -x assembler -c ari80386.s gcc -m32 -I/usr/local/include -I/Users/ungil/lisp/clisp/src/gllib -m32 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -DNO_GETTEXT -I. -DCOMPILE_STANDALONE -O0 -c genclisph.c genclisph.d: In function ‘print_printf_arg’: genclisph.d:64: error: duplicate case value genclisph.d:60: error: previously used here genclisph.d: In function ‘main’: genclisph.d:373: warning: comparison of unsigned expression < 0 is always false make: *** [genclisph.o] Error 1 On Tue, Feb 8, 2011 at 9:38 AM, Didier Verna <di...@lr...> wrote: > Carlos Ungil <car...@gm...> wrote: > >> MacOS on Intel is not listed as supported by ffcall >> (http://cvs.savannah.gnu.org/viewvc/ffcall/PLATFORMS?revision=1.14&root=libffcall). >> I don't know if that file is up-to-date, but I can't find any >> references to the platform being supported in README, NEWS, or >> ChangeLog. >> >> Is it supossed to work? > > On my Mac Book Pro (Intel Core i5) I have a working ffcall installed > by Fink: > > didier(s002)% fink list | grep ffcall 9:36 02/08/11 > i ffcall 1.10-5 Foreign function call libraries > > > I've used CLISP with cffi on this machine without any problem. > > -- > Resistance is futile. You will be jazzimilated. > > Scientific site: http://www.lrde.epita.fr/~didier > Music (Jazz) site: http://www.didierverna.com > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > clisp-list mailing list > cli...@li... > https://lists.sourceforge.net/lists/listinfo/clisp-list > |
From: Sam S. <sd...@gn...> - 2011-02-08 23:33:48
|
> * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-02-09 00:15:03 +0100]: > > -DCOMPILE_STANDALONE -O0 -c genclisph.c > genclisph.d: In function ‘print_printf_arg’: > genclisph.d:64: error: duplicate case value > genclisph.d:60: error: previously used here this means that HAVE_LONG_LONG_INT is defined (good) and sizeof(uint32) == sizeof(uint64) (double-plus-ungood). Please investigate. You can start with "make lispbibl.h"... -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) http://iris.org.il http://jihadwatch.org http://dhimmi.com http://ffii.org http://truepeace.org http://pmw.org.il http://openvotingconsortium.org The program isn't debugged until the last user is dead. |
From: Carlos U. <car...@gm...> - 2011-02-09 01:31:59
|
Hello, I've finally managed to compile a 32bit recent clisp on Snow Leopard: the problem was that intparams.h gave the wrong sizes, as it was compiled for 64bit. I'm setting the target architecture via "export CPPFLAGS=-m32 CFLAGS=-m32 CLFLAGS=-m32 LDFLAGS=-m32" (I'm not sure which ones are actually useful, and maybe there is a better way to do it that is not affected by the issue I'm about to describe). nThe problems is that the flags are ignored in some calls to gcc, in particular when generating intparam.h; the $(CFLAGS) in the following fragment of src/Makefile has been added by me. intparam.h : intparam.c config.h echo '#include "config.h"' > tmp.c cat 'intparam.c' >> tmp.c $(CC) $(CFLAGS) tmp.c -o intparam ./intparam intparam.h $(RM) intparam tmp.c After this change (and a similar one for floatparam.h, but I don't know if it makes any difference, running make compiles clisp almost to completion... however there is a similar problem in src/syscalls/Makefile. bogomips.o was created for the wrong architecture: I removed that object file and fixed the Makefile, and running make a second time I got a working clisp (but note that some other occurrences of the same problem might still exist in the modules I didn't compile). Cheers, Carlos On Wed, Feb 9, 2011 at 12:33 AM, Sam Steingold <sd...@gn...> wrote: >> * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-02-09 00:15:03 +0100]: >> >> -DCOMPILE_STANDALONE -O0 -c genclisph.c >> genclisph.d: In function ‘print_printf_arg’: >> genclisph.d:64: error: duplicate case value >> genclisph.d:60: error: previously used here > > this means that HAVE_LONG_LONG_INT is defined (good) and > sizeof(uint32) == sizeof(uint64) (double-plus-ungood). > Please investigate. > You can start with "make lispbibl.h"... > > -- > Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) > http://iris.org.il http://jihadwatch.org http://dhimmi.com http://ffii.org > http://truepeace.org http://pmw.org.il http://openvotingconsortium.org > The program isn't debugged until the last user is dead. > |
From: Andrew P. <and...@gm...> - 2011-02-27 01:22:38
|
Can someone update MacPorts with the new code? On Tue, Feb 8, 2011 at 8:31 PM, Carlos Ungil <car...@gm...> wrote: > Hello, > > I've finally managed to compile a 32bit recent clisp on Snow Leopard: > the problem was that intparams.h gave the wrong sizes, as it was > compiled for 64bit. > > I'm setting the target architecture via "export CPPFLAGS=-m32 > CFLAGS=-m32 CLFLAGS=-m32 LDFLAGS=-m32" (I'm not sure which ones are > actually useful, and maybe there is a better way to do it that is not > affected by the issue I'm about to describe). nThe problems is that > the flags are ignored in some calls to gcc, in particular when > generating intparam.h; the $(CFLAGS) in the following fragment of > src/Makefile has been added by me. > > intparam.h : intparam.c config.h > echo '#include "config.h"' > tmp.c > cat 'intparam.c' >> tmp.c > $(CC) $(CFLAGS) tmp.c -o intparam > ./intparam intparam.h > $(RM) intparam tmp.c > > After this change (and a similar one for floatparam.h, but I don't > know if it makes any difference, running make compiles clisp almost to > completion... however there is a similar problem in > src/syscalls/Makefile. bogomips.o was created for the wrong > architecture: I removed that object file and fixed the Makefile, and > running make a second time I got a working clisp (but note that some > other occurrences of the same problem might still exist in the modules > I didn't compile). > > Cheers, > > Carlos > > On Wed, Feb 9, 2011 at 12:33 AM, Sam Steingold <sd...@gn...> wrote: > >> * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-02-09 00:15:03 +0100]: > >> > >> -DCOMPILE_STANDALONE -O0 -c genclisph.c > >> genclisph.d: In function ‘print_printf_arg’: > >> genclisph.d:64: error: duplicate case value > >> genclisph.d:60: error: previously used here > > > > this means that HAVE_LONG_LONG_INT is defined (good) and > > sizeof(uint32) == sizeof(uint64) (double-plus-ungood). > > Please investigate. > > You can start with "make lispbibl.h"... > > > > -- > > Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) > > http://iris.org.il http://jihadwatch.org http://dhimmi.com > http://ffii.org > > http://truepeace.org http://pmw.org.il http://openvotingconsortium.org > > The program isn't debugged until the last user is dead. > > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > clisp-list mailing list > cli...@li... > https://lists.sourceforge.net/lists/listinfo/clisp-list > |
From: Sam S. <sd...@gn...> - 2011-02-28 16:11:29
|
> * Andrew Pennebaker <naqerj.craaronxre@tznvy.pbz> [2011-02-26 20:22:06 -0500]: > > Can someone update MacPorts with the new code? clisp-list and clisp-devel are the lists of clisp users and maintainers. we do not support MacPorts &c here. please contact the MacPorts maintainers directly. sorry, but I cannot help you further with this matter. (there is a chance that the MacPorts maintainer reads this list, but I would not bet on it). -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X http://www.memritv.org http://palestinefacts.org http://memri.org http://honestreporting.com http://jihadwatch.org http://pmw.org.il UNIX is a way of thinking. Windows is a way of not thinking. |
From: Sam S. <sd...@gn...> - 2011-04-04 15:56:31
|
Hi, > * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-02-09 02:31:50 +0100]: > > I'm setting the target architecture via "export CPPFLAGS=-m32 > CFLAGS=-m32 CLFLAGS=-m32 LDFLAGS=-m32" (I'm not sure which ones are > actually useful, and maybe there is a better way to do it that is not > affected by the issue I'm about to describe). please try hg tip - there have been important fixes there. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X http://pmw.org.il http://www.memritv.org http://palestinefacts.org http://truepeace.org http://openvotingconsortium.org http://honestreporting.com Bug free software merely has random features. |
From: Carlos U. <car...@gm...> - 2011-04-04 19:24:19
|
On Mon, Apr 4, 2011 at 5:56 PM, Sam Steingold <sd...@gn...> wrote: > Hi, > >> * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-02-09 02:31:50 +0100]: >> >> I'm setting the target architecture via "export CPPFLAGS=-m32 >> CFLAGS=-m32 CLFLAGS=-m32 LDFLAGS=-m32" (I'm not sure which ones are >> actually useful, and maybe there is a better way to do it that is not >> affected by the issue I'm about to describe). > > please try hg tip - there have been important fixes there. > > -- > Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X > http://pmw.org.il http://www.memritv.org http://palestinefacts.org > http://truepeace.org http://openvotingconsortium.org http://honestreporting.com > Bug free software merely has random features. Hi Sam, actually I found the cleanest way to compile a 32-bit clisp on MacOSX is to export CC="gcc -m32" and proceed normally (this works with the repository code, and also on 2.49). The most recent code can compile a 64-bit version without problems only for ./configure --ignore-absence-of-libsigsegv If I install libsigsegv-2.10 as suggested ("All 5 tests passed"), clisp compilation fails as shown below. System details: Intel Core i3, Snow Leopard (10.6.7), XCode 4 (i686-apple-darwin10-gcc-4.2.1) Cheers, Carlos ./lisp.run -B . -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -lp -x '(and (load "init.lisp") (sys::%saveinitmem) (ext::exit)) (ext::exit t)' i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `-+-' / 8 8 8 ooooo 8oooo `-__|__-' 8 8 8 8 8 | 8 o 8 8 o 8 8 ------+------ ooooo 8oooooo ooo8ooo ooooo 8 Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.cons.org/> Copyright (c) Bruno Haible, Michael Stoll 1992, 1993 Copyright (c) Bruno Haible, Marcus Daniels 1994-1997 Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998 Copyright (c) Bruno Haible, Sam Steingold 1999-2000 Copyright (c) Sam Steingold, Bruno Haible 2001-2010 Type :h and hit Enter for context help. ;; Loading file defseq.fas ... ;; Loaded file defseq.fas ;; Loading file backquote.fas ... ;; Loaded file backquote.fas ;; Loading file defmacro.fas ... ;; Loaded file defmacro.fas ;; Loading file macros1.fas ... ;; Loaded file macros1.fas ;; Loading file macros2.fas ... *** - handle_fault error2 ! address = 0x200037a4c not in [0x200000000,0x20003c3b0) ! SIGSEGV cannot be cured. Fault address = 0x200037a4c. GC count: 3 Space collected by GC: 632184 Run time: 0 54241 Real time: 1 12309 GC time: 0 2932 Permanently allocated: 166408 bytes. Currently in use: 416448 bytes. Free space: 524208 bytes. *** - handle_fault error2 ! address = 0x11359b000 not in [0x200000000,0x20003c3b0) ! SIGSEGV cannot be cured. Fault address = 0x11359b000. GC count: 3 Space collected by GC: 632184 Run time: 0 54353 Real time: 1 12798 GC time: 0 2932 Permanently allocated: 166408 bytes. Currently in use: 416448 bytes. Free space: 524208 bytes. make: *** [interpreted.mem] Segmentation fault |
From: Sam S. <sd...@gn...> - 2011-04-04 19:48:54
|
Hi, > * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-04-04 21:24:16 +0200]: > On Mon, Apr 4, 2011 at 5:56 PM, Sam Steingold <sd...@gn...> wrote: >>> * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-02-09 02:31:50 +0100]: >>> >>> I'm setting the target architecture via "export CPPFLAGS=-m32 >>> CFLAGS=-m32 CLFLAGS=-m32 LDFLAGS=-m32" (I'm not sure which ones are >>> actually useful, and maybe there is a better way to do it that is not >>> affected by the issue I'm about to describe). >> >> please try hg tip - there have been important fixes there. > > actually I found the cleanest way to compile a 32-bit clisp on MacOSX is to > export CC="gcc -m32" > and proceed normally (this works with the repository code, and also on 2.49). good. > The most recent code can compile a 64-bit version without problems only for > ./configure --ignore-absence-of-libsigsegv the crash you are getting indicates a problem with generational GC. please try ./configure CFLAGS='-DNO_GENERATIONAL_GC' --cbc build-no-gengc instead. > If I install libsigsegv-2.10 as suggested ("All 5 tests passed"), > clisp compilation fails as shown below. > > System details: Intel Core i3, Snow Leopard (10.6.7), XCode 4 > (i686-apple-darwin10-gcc-4.2.1) > > ./lisp.run -B . -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m 2MW -lp > -x '(and (load "init.lisp") (sys::%saveinitmem) (ext::exit)) > (ext::exit t)' > ... (loading some *fas files) > ;; Loading file macros2.fas ... > *** - handle_fault error2 ! address = 0x200037a4c not in > [0x200000000,0x20003c3b0) ! > SIGSEGV cannot be cured. Fault address = 0x200037a4c. > GC count: 3 > Space collected by GC: 632184 > Run time: 0 54241 > Real time: 1 12309 > GC time: 0 2932 > Permanently allocated: 166408 bytes. > Currently in use: 416448 bytes. > Free space: 524208 bytes. > > *** - handle_fault error2 ! address = 0x11359b000 not in > [0x200000000,0x20003c3b0) ! > SIGSEGV cannot be cured. Fault address = 0x11359b000. > GC count: 3 > Space collected by GC: 632184 > Run time: 0 54353 > Real time: 1 12798 > GC time: 0 2932 > Permanently allocated: 166408 bytes. > Currently in use: 416448 bytes. > Free space: 524208 bytes. > make: *** [interpreted.mem] Segmentation fault It appears that the generational gc is enabled (Carlos, could you please do "make gc" in your build directory, it will print the important settings) and the crash happens on the 3rd GC which is, I guess, the first full GC. Bruno, I have never seen _two_ "handle_fault error2" messages in a row. What does it mean? Thanks! PS. Carlos, when replying, please trim the quoted text (remove signatures &c). Thanks! -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X http://honestreporting.com http://palestinefacts.org http://pmw.org.il http://jihadwatch.org http://openvotingconsortium.org http://memri.org Bus error -- please leave by the rear door. |
From: Carlos U. <car...@gm...> - 2011-04-04 20:49:16
|
On Mon, Apr 4, 2011 at 9:48 PM, Sam Steingold <sd...@gn...> wrote: > the crash you are getting indicates a problem with generational GC. > please try > ./configure CFLAGS='-DNO_GENERATIONAL_GC' --cbc build-no-gengc > instead. ./configure --prefix=/Users/ungil/lisp/clisp/tools/x86_64-apple-darwin10.7.0 CFLAGS='-DNO_GENERATIONAL_GC' does produce a working binary, all tests but one (path.erg, see below) passed. $ ./lisp.run -M lispinit.mem --version GNU CLISP 2.49+ (2010-07-17) (built on imac.local [10.0.1.222]) Software: GNU C 4.2.1 (Apple Inc. build 5666) (dot 3) gcc -DNO_GENERATIONAL_GC -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DDYNAMIC_MODULES -DNO_GETTEXT -I. -lncurses -liconv -L/Users/ungil/lisp/clisp/tools/x86_64-apple-darwin10.7.0/lib -lsigsegv -lc libgnu_cl.a -L/usr/X11/lib -R/usr/X11/lib SAFETY=0 HEAPCODES STANDARD_HEAPCODES WIDE_HARD SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY libsigsegv 2.10 libiconv 1.11 Features: (LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN UNICODE BASE-CHAR=CHARACTER WORD-SIZE=64 UNIX MACOS) C Modules: (clisp) Installation directory: /Users/ungil/lisp/clisp/src/ User language: ENGLISH Machine: I386 (I386) imac.local [192.168.4.1] $ cat /Users/ungil/lisp/clisp/src/tests/*.erg Form: (LETF* ((*PATHNAME-ENCODING* CHARSET:ISO-8859-1) (WEIRD (CONCATENATE 'STRING "weird" (STRING (CODE-CHAR 160)))) (GOOD "path-tst-good-file") (DIR "path-tst-load-weird-dir/") (*LOAD-PATHS* (LIST (CONCATENATE 'STRING DIR "**")))) (RMRF DIR) (MAKE-DIRECTORY DIR) (OPEN (CONCATENATE 'STRING DIR WEIRD) :DIRECTION :PROBE :IF-DOES-NOT-EXIST :CREATE) (WITH-OPEN-FILE (OS (CONCATENATE 'STRING DIR GOOD ".lisp") :DIRECTION :OUTPUT) (FORMAT OS "(defparameter *load-var* 1234)~%")) (UNWIND-PROTECT (LIST (LETF ((*PATHNAME-ENCODING* CHARSET:ASCII)) (LOAD GOOD) *LOAD-VAR*) (EQ *PATHNAME-ENCODING* CHARSET:ISO-8859-1)) (RMRF DIR))) CORRECT: (1234 T) CLISP : ERROR PARSE-NAMESTRING: syntax error in filename "path-tst-load-weird-dir/weird " at position 29 OUT: "/Users/ungil/lisp/clisp/src/tests/path-tst-load-weird-dir/ 68 2011-04-04 22:42:26 removing directory #P\"/Users/ungil/lisp/clisp/src/tests/path-tst-load-weird-dir/\" [SIMPLE-PARSE-ERROR]: PARSE-NAMESTRING: syntax error in filename \"path-tst-load-weird-dir/weird \" at position 29 " > It appears that the generational gc is enabled (Carlos, could you please > do "make gc" in your build directory, it will print the important > settings) and the crash happens on the 3rd GC which is, I guess, the > first full GC. ./configure --prefix=/Users/ungil/lisp/clisp/tools/x86_64-apple-darwin10.7.0 cd src make make gc ((gcc -E -I/Users/ungil/lisp/clisp/tools/x86_64-apple-darwin10.7.0/include -I/Users/ungil/lisp/clisp/src/gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DDYNAMIC_MODULES -DNO_GETTEXT -I. -P lispbibl.c | grep -v "^ *$") ; (gcc -E -I/Users/ungil/lisp/clisp/tools/x86_64-apple-darwin10.7.0/include -I/Users/ungil/lisp/clisp/src/gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral -O -falign-functions=4 -DUNIX_BINARY_DISTRIB -DENABLE_UNICODE -DDYNAMIC_MODULES -DNO_GETTEXT -I. -P -dM lispbibl.c | sort) ) > lispbibl.h egrep '[^[:alpha:]](MEMORY|SPVW|GC|SIGSEGV|SAFETY|ASM|FAST|DEBUG)[^[:alpha:]]' lispbibl.h | grep -v 'define _' | egrep '^#define' #define ASM_UNDERSCORE #define ASM_get_SP_register(resultvar) ("movq %%rsp,%0" : "=g" (resultvar) : ) #define EAI_MEMORY 6 #define FAST_DOUBLE #define FAST_FLOAT #define GC_CLOSES_FILES #define GC_RESUME_WORLD(unlock_heap) #define GC_SAFE_CALL(var_assignment,statement) do { begin_blocking_call(); var_assignment statement; end_blocking_call(); } while(0) #define GC_SAFE_POINT() #define GC_SAFE_POINT_IF(gc,no_gc) #define GC_SAFE_REGION_BEGIN() #define GC_SAFE_REGION_END() #define GC_SAFE_SYSTEM_CALL(var_assignment,statement) do { begin_blocking_system_call(); var_assignment statement; end_blocking_system_call(); } while(0) #define GC_STOP_WORLD(lock_heap) #define GENERATIONAL_GC #define HAVE_MEMORY_H 1 #define HAVE_SIGSEGV_RECOVERY 1 #define INT_FAST16_MAX LONG_MAX #define INT_FAST16_MIN LONG_MIN #define INT_FAST32_MAX LONG_MAX #define INT_FAST32_MIN LONG_MIN #define INT_FAST64_MAX INT64_MAX #define INT_FAST64_MIN INT64_MIN #define INT_FAST8_MAX LONG_MAX #define INT_FAST8_MIN LONG_MIN #define KERN_INVALID_MEMORY_CONTROL 34 #define KERN_MEMORY_DATA_MOVED 24 #define KERN_MEMORY_ERROR 10 #define KERN_MEMORY_FAILURE 9 #define KERN_MEMORY_PRESENT 23 #define KERN_MEMORY_RESTART_COPY 25 #define MACH_SEND_INVALID_MEMORY 0x1000000c #define MORRIS_GC #define PERFORM_GC(statement,lock_heap) statement #define SAFETY 0 #define SIGSEGV 11 #define SIGSEGV_FAULT_ADDRESS_ALIGNMENT 1UL #define SO_DEBUG 0x0001 #define SPVW_BLOCKS #define SPVW_MIXED #define STACKCHECKB (SAFETY >= 1) #define STACKCHECKC (SAFETY >= 1) #define STACKCHECKP (SAFETY >= 1) #define STACKCHECKR (SAFETY >= 1) #define STACKCHECKS (SAFETY >= 1) #define TRIVIALMAP_MEMORY #define UINT_FAST16_MAX ULONG_MAX #define UINT_FAST32_MAX ULONG_MAX #define UINT_FAST64_MAX UINT64_MAX #define UINT_FAST8_MAX ULONG_MAX #define VALID_THREAD_STATE_FLAVOR(x) ((x == x86_THREAD_STATE32) || (x == x86_FLOAT_STATE32) || (x == x86_EXCEPTION_STATE32) || (x == x86_DEBUG_STATE32) || (x == x86_THREAD_STATE64) || (x == x86_FLOAT_STATE64) || (x == x86_EXCEPTION_STATE64) || (x == x86_DEBUG_STATE64) || (x == x86_THREAD_STATE) || (x == x86_FLOAT_STATE) || (x == x86_EXCEPTION_STATE) || (x == x86_DEBUG_STATE) || (x == THREAD_STATE_NONE)) #define VIRTUAL_MEMORY #define X86_DEBUG_STATE32_COUNT x86_DEBUG_STATE32_COUNT #define X86_DEBUG_STATE64_COUNT x86_DEBUG_STATE64_COUNT #define begin_blocking_call() GC_SAFE_REGION_BEGIN() #define begin_blocking_system_call() begin_system_call();GC_SAFE_REGION_BEGIN() #define end_blocking_call() GC_SAFE_REGION_END() #define end_blocking_system_call() end_system_call();GC_SAFE_REGION_END() #define x86_DEBUG_STATE 12 #define x86_DEBUG_STATE32 10 #define x86_DEBUG_STATE32_COUNT ((mach_msg_type_number_t) ( sizeof (x86_debug_state32_t) / sizeof (int) )) #define x86_DEBUG_STATE64 11 #define x86_DEBUG_STATE64_COUNT ((mach_msg_type_number_t) ( sizeof (x86_debug_state64_t) / sizeof (int) )) #define x86_DEBUG_STATE_COUNT ((mach_msg_type_number_t) (sizeof(x86_debug_state_t)/sizeof(unsigned int))) |
From: Sam S. <sd...@gn...> - 2011-04-04 21:06:44
|
> * Carlos Ungil <pneybf.hatvy@tznvy.pbz> [2011-04-04 22:49:09 +0200]: > > $ cat /Users/ungil/lisp/clisp/src/tests/*.erg > Form: (LETF* ((*PATHNAME-ENCODING* CHARSET:ISO-8859-1) (WEIRD > (CONCATENATE 'STRING "weird" (STRING (CODE-CHAR 160)))) (GOOD > "path-tst-good-file") (DIR "path-tst-load-weird-dir/") (*LOAD-PATHS* > (LIST (CONCATENATE 'STRING DIR "**")))) (RMRF DIR) (MAKE-DIRECTORY > DIR) (OPEN (CONCATENATE 'STRING DIR WEIRD) :DIRECTION :PROBE > :IF-DOES-NOT-EXIST :CREATE) (WITH-OPEN-FILE (OS (CONCATENATE 'STRING > DIR GOOD ".lisp") :DIRECTION :OUTPUT) (FORMAT OS "(defparameter > *load-var* 1234)~%")) (UNWIND-PROTECT (LIST (LETF > ((*PATHNAME-ENCODING* CHARSET:ASCII)) (LOAD GOOD) *LOAD-VAR*) (EQ > *PATHNAME-ENCODING* CHARSET:ISO-8859-1)) (RMRF DIR))) > CORRECT: (1234 T) > CLISP : ERROR > PARSE-NAMESTRING: syntax error in filename > "path-tst-load-weird-dir/weird " at position 29 > > OUT: > "/Users/ungil/lisp/clisp/src/tests/path-tst-load-weird-dir/ 68 > 2011-04-04 22:42:26 > removing directory > #P\"/Users/ungil/lisp/clisp/src/tests/path-tst-load-weird-dir/\" > [SIMPLE-PARSE-ERROR]: PARSE-NAMESTRING: syntax error in filename > \"path-tst-load-weird-dir/weird \" at position 29 > > " it would be nice if you could investigate this. (build with "./configure --with-debug --cbc build-g", run under gdb, break in legal_namechar, and see why the char 160 is illegal when *PATHNAME-ENCODING* is ISO-8859-1). thanks. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.5 (Final) X http://www.memritv.org http://pmw.org.il http://jihadwatch.org http://ffii.org http://iris.org.il http://palestinefacts.org http://openvotingconsortium.org A poet who reads his verse in public may have other nasty habits. |
From: Vladimir T. <vtz...@gm...> - 2011-04-08 13:42:53
|
On 4/5/11, Sam Steingold <sd...@gn...> wrote: > it would be nice if you could investigate this. > (build with "./configure --with-debug --cbc build-g", run under gdb, > break in legal_namechar, and see why the char 160 is illegal when > *PATHNAME-ENCODING* is ISO-8859-1). Sam, legal_namebyte():825 is reached with ch == 160 and this is form config.h: #define VALID_FILENAME_CHAR ((ch >= 1) && (ch <= 127) && (ch != 47)) Vladimir |
From: Sam S. <sd...@gn...> - 2011-04-11 01:46:24
|
> * Vladimir Tzankov <igmnaxbi@tznvy.pbz> [2011-04-08 16:42:45 +0300]: > > On 4/5/11, Sam Steingold <sd...@gn...> wrote: >> it would be nice if you could investigate this. >> (build with "./configure --with-debug --cbc build-g", run under gdb, >> break in legal_namechar, and see why the char 160 is illegal when >> *PATHNAME-ENCODING* is ISO-8859-1). > > legal_namebyte():825 is reached with ch == 160 and this is form config.h: > #define VALID_FILENAME_CHAR ((ch >= 1) && (ch <= 127) && (ch != 47)) is this actually correct? only ascii pathnames on mac os x? oh well... fine, so the test has to be fixed. please try the appended patch on mac os x. thanks! -- Sam Steingold (http://sds.podval.org/) on Ubuntu 10.10 (maverick) X http://openvotingconsortium.org http://iris.org.il http://jihadwatch.org http://thereligionofpeace.com http://mideasttruth.com http://www.memritv.org ((lambda (x) `(,x ',x)) '(lambda (x) `(,x ',x))) diff -r 35868d7a9a29 tests/path.tst --- a/tests/path.tst Sun Apr 10 17:53:58 2011 -0400 +++ b/tests/path.tst Sun Apr 10 21:45:13 2011 -0400 @@ -1345,8 +1345,10 @@ NIL (custom:*load-paths* (list (concatenate 'string dir "**")))) (rmrf dir) (ext:make-directory dir) + (handler-case (open (concatenate 'string dir weird) :direction :probe :if-does-not-exist :create) + (parse-error (c) (princ-error c))) ; only ASCII pathnames on OSX (with-open-file (os (concatenate 'string dir good ".lisp") :direction :output) (format os "(defparameter *load-var* 1234)~%")) |
From: Vladimir T. <vtz...@gm...> - 2011-04-08 13:44:07
|
On 4/4/11, Carlos Ungil <car...@gm...> wrote: > ;; Loading file macros2.fas ... > *** - handle_fault error2 ! address = 0x200037a4c not in > [0x200000000,0x20003c3b0) ! > SIGSEGV cannot be cured. Fault address = 0x200037a4c. > GC count: 3 > Space collected by GC: 632184 > Run time: 0 54241 > Real time: 1 12309 > GC time: 0 2932 > Permanently allocated: 166408 bytes. > Currently in use: 416448 bytes. > Free space: 524208 bytes. Fixed in hg - was wrong comparison in spvw_fault.d introduced recently. Vladimir |
From: Pascal J. B. <pj...@in...> - 2011-04-11 02:35:38
|
Sam Steingold <sd...@gn...> writes: >> * Vladimir Tzankov <igmnaxbi@tznvy.pbz> [2011-04-08 16:42:45 +0300]: >> >> On 4/5/11, Sam Steingold <sd...@gn...> wrote: >>> it would be nice if you could investigate this. >>> (build with "./configure --with-debug --cbc build-g", run under gdb, >>> break in legal_namechar, and see why the char 160 is illegal when >>> *PATHNAME-ENCODING* is ISO-8859-1). >> >> legal_namebyte():825 is reached with ch == 160 and this is form config.h: >> #define VALID_FILENAME_CHAR ((ch >= 1) && (ch <= 127) && (ch != 47)) > > is this actually correct? only ascii pathnames on mac os x? oh well... Not at all. On MacOSX, the pathnames are encoded in UTF-8 with a certain normalization. http://developer.apple.com/library/mac/#qa/qa2001/qa1173.html -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |