From: Alexander T. <ast...@gm...> - 2007-08-08 13:23:50
|
Hello, I have problem with compilation sbcl 1.08 and 1.07 on Solaris 10 x86. Compilation just stopped on file low.lisp. It seems like it could not compile the following expression: (defstruct (wrapper (:include layout ;; KLUDGE: In CMU CL, the initialization default ;; for LAYOUT-INVALID was NIL. In SBCL, that has ;; changed to :UNINITIALIZED, but PCL code might ;; still expect NIL for the initialization ;; default of WRAPPER-INVALID. Instead of trying ;; to find out, I just overrode the LAYOUT ;; default here. -- WHN 19991204 (invalid nil)) (:constructor make-wrapper-internal) (:copier nil)) (instance-slots-layout nil :type list) (class-slots nil :type list)) #-sb-fluid (declaim (sb-ext:freeze-type wrapper)) Please look on last messages from compiler: ; compiling file "/home/atrusov/Desktop/sbcl-1.0.8/src/pcl/low.lisp" (written 22 JUN 2007 09:24:28 AM): ; compiling (IN-PACKAGE "SB-PCL") ; compiling (DEFVAR *OPTIMIZE-SPEED* ...) ; compiling (DEFMACRO DOTIMES-FIXNUM ...) ; compiling (DEFSTRUCT (WRAPPER # ...) ...) real 1.9 user 1.3 sys 0.4 P.S. I have no such problem with sbcl 1.06. Thanks, Alexander. |
From: Christophe R. <cs...@ca...> - 2007-08-08 13:36:57
|
"Alexander Trusov" <ast...@gm...> writes: > Please look on last messages from compiler: > ; compiling file "/home/atrusov/Desktop/sbcl-1.0.8/src/pcl/low.lisp" (wri= tten > 22 JUN 2007 09:24:28 AM): > ; compiling (IN-PACKAGE "SB-PCL") > ; compiling (DEFVAR *OPTIMIZE-SPEED* ...) > ; compiling (DEFMACRO DOTIMES-FIXNUM ...) > ; compiling (DEFSTRUCT (WRAPPER # ...) ...) > real=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.9 > user=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1.3 > sys=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0.4 > P.S. I have no such problem with sbcl 1.06. I believe that this is normally where the first triggered garbage collection happens. What host compiler are you using to build the system? Can you bisect the range between versions 1.0.6 (which works) and 1.0.7 (which doesn't) to identify a commit which stops the system from building? Thanks, Christophe |
From: Alexander T. <ast...@gm...> - 2007-08-08 14:13:25
|
2007/8/8, Alexander Trusov <ast...@gm...>: > > "Alexander Trusov" < ast...@gm...> writes: > > > > > Please look on last messages from compiler: > > > ; compiling file "/home/atrusov/Desktop/sbcl-1.0.8/src/pcl/low.lisp" > > (written > > > 22 JUN 2007 09:24:28 AM): > > > ; compiling (IN-PACKAGE "SB-PCL") > > > ; compiling (DEFVAR *OPTIMIZE-SPEED* ...) > > > ; compiling (DEFMACRO DOTIMES-FIXNUM ...) > > > ; compiling (DEFSTRUCT (WRAPPER # ...) ...) > > > real 1.9 > > > user 1.3 > > > sys 0.4 > > > P.S. I have no such problem with sbcl 1.06. > > > > I believe that this is normally where the first triggered garbage > > collection happens. > > > > What host compiler are you using to build the system? Can you bisect > > the range between versions 1.0.6 (which works) and 1.0.7 (which > > doesn't) to identify a commit which stops the system from building? > > > > Thanks, > > > > Christophe > > > > I`m using sbcl 1.0.6 as a host compiler. Sorry, I`m a novice in lisp and > sbcl. > I simply don`t know how I can get all versions between 1.0.6 and 1.0.7. > > Thanks, Alexander. > > > |
From: Alexander T. <ast...@gm...> - 2007-08-09 08:18:35
|
2007/8/8, Christophe Rhodes <cs...@ca...>: > > "Alexander Trusov" <ast...@gm...> writes: > > > I`m using sbcl 1.0.6 as a host compiler. Sorry, I`m a novice in lisp > > and sbcl. I simply don`t know how I can get all versions between > > 1.0.6 and 1.0.7. Thanks, Alexander. > > Using <http://sbcl.cvs.sourceforge.net/sbcl/sbcl/version.lisp-expr>, > which is the log of the changes to the master version.lisp-expr file, > you can bisect by hand. For example, from that page: > > sbcl-1.0.7 was released on 'Wed Jun 27 23:44:09 2007 UTC' > sbcl-1.0.6 was released on 'Sun May 27 01:13:28 2007 UTC' > > Let's assume that you have a cvs checkout of sbcl already. Then, from > that working directory, doing > cvs update -D'2007-06-27 23:45:00 UTC' > will get you the state of the repository as of just after sbcl-1.0.7 > > Similarly, doing > cvs update -D'2007-05-27 01:14:00 UTC' > gets you the repository as of sbcl-1.0.6 > > To get the repository as of halfway between, you can bisect by date > (i.e. using -D'2007-06-12 00:00:00 UTC' for example) > or you can use the timestamps from the web page above. > > Best, > > Christophe > Hello Christophe, I found that this problem was introduced in version 1.0.6.44 with following commit : *Mon Jun 11 03:29:23 2007 UTC* (8 weeks, 2 days ago) by *jsnell* 1.0.6.44: make WITHOUT-INTERRUPTS non-consing * Consing up a closure for CALL-WITHOUT-INTERRUPTS is a performance problem, stack-allocate the closure on platforms with dx support. * Doing the stack-allocation properly is a bit tricky, encapsulate the right way into the CALL-WITH-DX-FUNCTION macro. * TODO: apply the same procedure to other CALL-WITH-FOOs. P.S. I have successfully compiled version 1.0.6.43. Regards, Alexander. |
From: Christophe R. <cs...@ca...> - 2007-08-09 09:09:58
|
"Alexander Trusov" <ast...@gm...> writes: > Hello Christophe, > I found that this problem was introduced in version [[1.0.6.44]] with > following commit : > > Mon Jun 11 03:29:23 2007 UTC (8 weeks, 2 days ago) by jsnell > [[1.0.6.44]]: make WITHOUT-INTERRUPTS non-consing > > * Consing up a closure for CALL-WITHOUT-INTERRUPTS is a performance > problem, stack-allocate the closure on platforms with dx support. > * Doing the stack-allocation properly is a bit tricky, encapsulate > the right way into the CALL-WITH-DX-FUNCTION macro. > * TODO: apply the same procedure to other CALL-WITH-FOOs. > > P.S. I have successfully compiled version [[1.0.6.43]] . > Regards, Alexander. Great, thanks. Can you try something else? Could you get the diff between 1.0.6.43 and 1.0.6.44 (by doing cvs diff -u -D'Mon Jun 11 03:27:23 2007 UTC' -D'Mon Jun 11 03:31:23 2007 UTC' -- that is, with the datestamps straddling the commit time), save the diff in a file, reacquire cvs HEAD (by checking out a fresh repository or doing cvs update -dPA), and then apply the reversed diff to that (with patch -p0 -R < /path/to/saved.diff [ you may need to use GNU patch; I don't know ]. The idea here is to see whether you can build the current development tree if we subtract out the change between 1.0.6.43 and 1.0.6.44. Thanks, Christophe |
From: Juho S. <js...@ik...> - 2007-08-09 09:25:42
|
Christophe Rhodes <cs...@ca...> writes: > Great, thanks. > > Can you try something else? Could you get the diff between 1.0.6.43 > and 1.0.6.44 (by doing > > cvs diff -u -D'Mon Jun 11 03:27:23 2007 UTC' -D'Mon Jun 11 03:31:23 2007 UTC' > > -- that is, with the datestamps straddling the commit time), save the > diff in a file, reacquire cvs HEAD (by checking out a fresh repository > or doing cvs update -dPA), and then apply the reversed diff to that (with > > patch -p0 -R < /path/to/saved.diff > > [ you may need to use GNU patch; I don't know ]. > > The idea here is to see whether you can build the current development > tree if we subtract out the change between 1.0.6.43 and 1.0.6.44. That's unlikely to work, since the changes in that commit have since been refactored. If the problem really is that stack allocation of closures causes problems on Solaris, the following patch to HEAD should help. Though I don't know why it would be the cause -- the usual suspect for mysterious Solaris/x86 bugs would be the direction flag, but dx closures shouldn't twiddle that. diff --git a/make-config.sh b/make-config.sh index ce0c8f2..955caa0 100644 --- a/make-config.sh +++ b/make-config.sh @@ -276,7 +276,7 @@ cd $original_dir if [ "$sbcl_arch" = "x86" ]; then printf ' :gencgc :stack-grows-downward-not-upward :c-stack-is-control-stack' >> $ltf printf ' :compare-and-swap-vop :unwind-to-frame-and-call-vop' >> $ltf - printf ' :stack-allocatable-closures :alien-callbacks' >> $ltf + printf ' :alien-callbacks' >> $ltf if [ "$sbcl_os" = "linux" ] || [ "$sbcl_os" = "freebsd" ] || [ "$sbcl_os" = "netbsd" ] || [ "$sbcl_os" = "sunos" ] || [ "$sbcl_os" = "darwin" ] || [ "$sbcl_os" = "win32" ]; then printf ' :linkage-table' >> $ltf fi -- Juho Snellman |
From: Alexander T. <ast...@gm...> - 2007-08-09 10:00:15
|
09 Aug 2007 12:25:55 +0300, Juho Snellman <js...@ik...>: > > Christophe Rhodes <cs...@ca...> writes: > > Great, thanks. > > > > Can you try something else? Could you get the diff between 1.0.6.43 > > and 1.0.6.44 (by doing > > > > cvs diff -u -D'Mon Jun 11 03:27:23 2007 UTC' -D'Mon Jun 11 03:31:23 > 2007 UTC' > > > > -- that is, with the datestamps straddling the commit time), save the > > diff in a file, reacquire cvs HEAD (by checking out a fresh repository > > or doing cvs update -dPA), and then apply the reversed diff to that > (with > > > > patch -p0 -R < /path/to/saved.diff > > > > [ you may need to use GNU patch; I don't know ]. > > > > The idea here is to see whether you can build the current development > > tree if we subtract out the change between 1.0.6.43 and 1.0.6.44. > > That's unlikely to work, since the changes in that commit have since > been refactored. If the problem really is that stack allocation of > closures causes problems on Solaris, the following patch to HEAD > should help. Though I don't know why it would be the cause -- the > usual suspect for mysterious Solaris/x86 bugs would be the direction > flag, but dx closures shouldn't twiddle that. > > diff --git a/make-config.sh b/make-config.sh > index ce0c8f2..955caa0 100644 > --- a/make-config.sh > +++ b/make-config.sh > @@ -276,7 +276,7 @@ cd $original_dir > if [ "$sbcl_arch" = "x86" ]; then > printf ' :gencgc :stack-grows-downward-not-upward > :c-stack-is-control-stack' >> $ltf > printf ' :compare-and-swap-vop :unwind-to-frame-and-call-vop' >> $ltf > - printf ' :stack-allocatable-closures :alien-callbacks' >> $ltf > + printf ' :alien-callbacks' >> $ltf > if [ "$sbcl_os" = "linux" ] || [ "$sbcl_os" = "freebsd" ] || [ > "$sbcl_os" = "netbsd" ] || [ "$sbcl_os" = "sunos" ] || [ "$sbcl_os" = > "darwin" ] || [ "$sbcl_os" = "win32" ]; then > printf ' :linkage-table' >> $ltf > fi > > -- > Juho Snellman > > Thanks for help, it`s work. Regards, Alexander. |
From: <fa...@gm...> - 2007-08-10 02:37:53
|
It may be that Solaris is preventing execution of code on stack, to eliminate certain widely known means of attacks of C programs (by e.g. limiting the size of the code segment). Solaris may have a way to disable this "security" feature. [ Fran=E7ois-Ren=E9 =D0VB Rideau | Reflection&Cybernethics | http://fare.tu= nes.org ] Every technique is first developed, then used, important, obsolete, normalized, and finally understood. On 09/08/07, Alexander Trusov <ast...@gm...> wrote: > 09 Aug 2007 12:25:55 +0300, Juho Snellman <js...@ik...>: > > That's unlikely to work, since the changes in that commit have since > > been refactored. If the problem really is that stack allocation of > > closures causes problems on Solaris, the following patch to HEAD > > should help. Though I don't know why it would be the cause -- the > > usual suspect for mysterious Solaris/x86 bugs would be the direction > > flag, but dx closures shouldn't twiddle that. > > Thanks for help, it`s work. |
From: Thomas F. B. <tf...@oc...> - 2007-08-10 07:47:53
|
On 8/10/07, Far=E9 <fa...@gm...> wrote: > It may be that Solaris is preventing execution of code on stack, to > eliminate certain widely known means of attacks of C programs (by e.g. > limiting the size of the code segment). Solaris may have a way to > disable this "security" feature. I don't remember offhand if SBCL mprotects its stack to set executable permission, but if not, this could be the issue. Alexander, could you look in /etc/system and see if there's a line in there that looks like: noexec_user_stack =3D 1 The default behavior for Solaris is a bit complicated: 64-bit executables have non-executable stacks by default, but for 32-bit executables the default is executable stacks, unless this kernel flag is set. In all cases, the kernel honors mprotect requests, so it actually isn't broken in the same way some other OSes in this respect. > On 09/08/07, Alexander Trusov <ast...@gm...> wrote: > > 09 Aug 2007 12:25:55 +0300, Juho Snellman <js...@ik...>: > > > That's unlikely to work, since the changes in that commit have since > > > been refactored. If the problem really is that stack allocation of > > > closures causes problems on Solaris, the following patch to HEAD > > > should help. Though I don't know why it would be the cause -- the > > > usual suspect for mysterious Solaris/x86 bugs would be the direction > > > flag, but dx closures shouldn't twiddle that. > > > > Thanks for help, it`s work. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |
From: Juho S. <js...@ik...> - 2007-08-10 08:15:27
|
"Far=E9" <fa...@gm...> writes: > It may be that Solaris is preventing execution of code on stack, to > eliminate certain widely known means of attacks of C programs (by e.g. > limiting the size of the code segment). Solaris may have a way to > disable this "security" feature. That shouldn't matter here. No code needs to be executed on the stack for dx closures. The actual code will still be on the heap, it's just the pointer to the function and the environment that's stack allocated. --=20 Juho Snellman |
From: Alexander T. <ast...@gm...> - 2007-08-10 15:45:01
|
Anyway, this is content of file /etc/system: set rlim_fd_max=65536 set rlim_fd_cur=65536 set sq_max_size=0 set autoup=60 set pcisch:pci_stream_buf_enable=0 set nfs:nfs4_nra=8 set nfs:nfs_nra=8 set shmsys:shminfo_shmmax=0xffffffff set shmsys:shminfo_shmseg=128 set semsys:seminfo_semmnu=1024 set semsys:seminfo_semmap=128 set semsys:seminfo_semmni=400 set semsys:seminfo_semmns=1024 Regards, Alexander. |