Re: interrupts in 64-bit GCL

[Camm Maguire-2]

Greetings!  I suspect a missing signal block around some code that
needs protecting.  I've reprodced under gdb, but there are no
debugging symbols in the image.  [ Question for list -- have computers
now become so fast that -g should be included by default in all gcl
images? It used to slow down the compiler, don't know about now.  It
does make the image quite a bit bigger. ]

Ideally, you or someone else at the site might be so kind as to
rebuild atop

1) a gcl build with --enable-debug.  If this does not reproduce, then
in addition
2) rebuild atop a standard gcl with the CFLAGS environment variable
set to -g before configure and make.  Please make sure -g is included
in the gcc calls.  Otherwise, makedefs can be modified after configure
and before make to include -g wherever one sees -O3 or -O

Would this be too much trouble?

Take care,

Matt Kaufmann <kaufmann@...> writes:

> Hi --
>
> The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
> suggested.  It's working great on 32-bit linux, but I've run into an
> issue for 64-bit linux.
>
> You can re-create the issue on a UT CS 64-bit linux machine as
> follows.
>
> Start up ACL2 built on GCL, as follows:
>
> /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
>
> Then issue these commands:
>
>   ; Just to slow down the output from the next form:
>   (trace$ rewrite)
>
>   ; ACL2 disables the debugger by default; this restores it:
>   (set-debugger-enable t)
>
>   ; This goes pretty fast but you'll have time to interrupt it:
>   (thm (equal (append (append x x) x) (append x x x)))
>
>   [Now quickly interrupt with control-c, and then :q from the break.
>    If the form above completes, just try it again.  Eventually I think
>    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
>
> By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
> follows, on lhug-0 (a 64-bit linux machine):
>
> rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
>
> where "my-fast-gcl" is a script containing:
>
> #!/bin/sh
> /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
>
> Also by the way, if you instead run the following on a 32-bit UT CS
> linux machine
>
> /projects/acl2/v3-4-linux/gcl-saved_acl2
>
> then you won't see the interrupt problem described above (or at least,
> I didn't, and I tried).
>
> Thanks --
> -- Matt
>
>
>
>

--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Gabriel Dos Reis-2]

Camm Maguire <camm@...> writes:

| Greetings!  I suspect a missing signal block around some code that
| needs protecting.  I've reprodced under gdb, but there are no
| debugging symbols in the image.  [ Question for list -- have computers
| now become so fast that -g should be included by default in all gcl
| images? It used to slow down the compiler, don't know about now.  It
| does make the image quite a bit bigger. ]

I'm not sure what it the relation between -g and

    (proclaim '(optimize debug))

but I can report that with GCL-based OpenAxiom, the build is really
slow and the resulting system runs very slow, even on my fastest
quad-core machines.

-- Gaby


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings!  You can see the gcc flags emitted with

(trace si::system)

I think the current behavior is

(proclaim '(optimize debug))

Warning:
The OPTIMIZE quality DEBUG is unknown.
NIL

in 2.6.8 and a no-op in 2.7.0, though it should be fixed in the
latter.

Take care,

Gabriel Dos Reis <gdr@...> writes:

> Camm Maguire <camm@...> writes:
>
> | Greetings!  I suspect a missing signal block around some code that
> | needs protecting.  I've reprodced under gdb, but there are no
> | debugging symbols in the image.  [ Question for list -- have computers
> | now become so fast that -g should be included by default in all gcl
> | images? It used to slow down the compiler, don't know about now.  It
> | does make the image quite a bit bigger. ]
>
> I'm not sure what it the relation between -g and
>
>     (proclaim '(optimize debug))
>
> but I can report that with GCL-based OpenAxiom, the build is really
> slow and the resulting system runs very slow, even on my fastest
> quad-core machines.
>
> -- Gaby
>
>
>
>

--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Gabriel Dos Reis-2]

Camm Maguire <camm@...> writes:

| Greetings!  You can see the gcc flags emitted with
|
| (trace si::system)
|
| I think the current behavior is
|
| (proclaim '(optimize debug))
|
| Warning:
| The OPTIMIZE quality DEBUG is unknown.
| NIL
|
| in 2.6.8 and a no-op in 2.7.0, though it should be fixed in the
| latter.

Absolutely right, you are.   I confused 'debug' with 'safety'.
I just checked what OpenAxiom emits when I say

     open-axiom.trunk/configure --enable-checking

The answer is

   ;; Lisp compiler optimization settings.
   (defconstant |$LispOptimizeOptions|
     '(speed safety))
   (proclaim '(optimize speed safety))


so, not 'debug' but 'safety'.  And, now I see I put a comment in the
configure file saying

   if test x"$axiom_enable_checking" = xyes; then
      case $axiom_lisp_flavor in
        gcl) # GCL-2.6.x does not understand debug.
           axiom_optimize_options="$axiom_optimize_options safety"
           ;;
        *) axiom_optimize_options="$axiom_optimize_options safety debug"
           ;;
      esac
      AC_MSG_NOTICE([runtime checking may increase compilation time])
   fi


With safety 3 on, OpenAxiom takes approximately 5 times longer to build
the entire algebra.  

-- Gaby


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings!

Yes, safety, which stands for 'safety level 3', essentially passes all
function calls through the interpreter, disables inlining, etc.  2.7.0
has made this less severe, while reserving the old mode for safety
level 4.  In any case, one gets code with most checks with safety
level 2 (declaim (optimize (safety 2))).  The precise definitions were
discussed in an earlier post if interested.  We can revisit this if
desired.

I think one could do an open axiom test of the -g effects with

(setq compiler:*cc* (concatenate 'string compiler::*cc* " -g "))

If you get timing results I'd be interested.

Take care,

Gabriel Dos Reis <gdr@...> writes:

> Camm Maguire <camm@...> writes:
>
> | Greetings!  You can see the gcc flags emitted with
> |
> | (trace si::system)
> |
> | I think the current behavior is
> |
> | (proclaim '(optimize debug))
> |
> | Warning:
> | The OPTIMIZE quality DEBUG is unknown.
> | NIL
> |
> | in 2.6.8 and a no-op in 2.7.0, though it should be fixed in the
> | latter.
>
> Absolutely right, you are.   I confused 'debug' with 'safety'.
> I just checked what OpenAxiom emits when I say
>
>      open-axiom.trunk/configure --enable-checking
>
> The answer is
>
>    ;; Lisp compiler optimization settings.
>    (defconstant |$LispOptimizeOptions|
>      '(speed safety))
>    (proclaim '(optimize speed safety))
>
>
> so, not 'debug' but 'safety'.  And, now I see I put a comment in the
> configure file saying
>
>    if test x"$axiom_enable_checking" = xyes; then
>       case $axiom_lisp_flavor in
>         gcl) # GCL-2.6.x does not understand debug.
>            axiom_optimize_options="$axiom_optimize_options safety"
>            ;;
>         *) axiom_optimize_options="$axiom_optimize_options safety debug"
>            ;;
>       esac
>       AC_MSG_NOTICE([runtime checking may increase compilation time])
>    fi
>
>
> With safety 3 on, OpenAxiom takes approximately 5 times longer to build
> the entire algebra.  
>
> -- Gaby
>
>
>
>

--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Thanks!  Please let me know if you run into troubles here.

Take care,

Matt Kaufmann <kaufmann@...> writes:

> Howdy --
>
> Thanks for the reply.
>
> If gripe@cs is willing to do (1), or to send me the exact configure
> and make commands and source directory used so that I can do it
> myself, then I'll try to reproduce the error by building ACL2 on top
> of it.  I'm assuming that --enable-debug is given to the configure
> command, not to make.
>
> Then if if I can't reproduce the problem, I'll let you and gripe@cs
> know and we can explore (2).  In that case, if gripe@cs is willing to
> do it, great; then I'll try to reproduce the problem.  But if I'm to
> do the build, I'd need explicit instructions on how to "make sure -g
> is included in the gcc calls"; maybe I need to do some setq in Lisp?
> Also I didn't understand the comment about makedefs.  But I guess we
> can ignore (2) if (1) works.
>
> -- Matt
>    Cc: gcl-devel@..., gripe@...
>    From: Camm Maguire <camm@...>
>    Date: Fri, 20 Feb 2009 20:58:49 -0500
>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
>    X-UTCS-Spam-Status: No, hits=-282 required=165
>
>    Greetings!  I suspect a missing signal block around some code that
>    needs protecting.  I've reprodced under gdb, but there are no
>    debugging symbols in the image.  [ Question for list -- have computers
>    now become so fast that -g should be included by default in all gcl
>    images? It used to slow down the compiler, don't know about now.  It
>    does make the image quite a bit bigger. ]
>
>    Ideally, you or someone else at the site might be so kind as to
>    rebuild atop
>
>    1) a gcl build with --enable-debug.  If this does not reproduce, then
>    in addition
>    2) rebuild atop a standard gcl with the CFLAGS environment variable
>    set to -g before configure and make.  Please make sure -g is included
>    in the gcc calls.  Otherwise, makedefs can be modified after configure
>    and before make to include -g wherever one sees -O3 or -O
>
>    Would this be too much trouble?
>
>    Take care,
>
>    Matt Kaufmann <kaufmann@...> writes:
>
>    > Hi --
>    >
>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
>    > suggested.  It's working great on 32-bit linux, but I've run into an
>    > issue for 64-bit linux.
>    >
>    > You can re-create the issue on a UT CS 64-bit linux machine as
>    > follows.
>    >
>    > Start up ACL2 built on GCL, as follows:
>    >
>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
>    >
>    > Then issue these commands:
>    >
>    >   ; Just to slow down the output from the next form:
>    >   (trace$ rewrite)
>    >
>    >   ; ACL2 disables the debugger by default; this restores it:
>    >   (set-debugger-enable t)
>    >
>    >   ; This goes pretty fast but you'll have time to interrupt it:
>    >   (thm (equal (append (append x x) x) (append x x x)))
>    >
>    >   [Now quickly interrupt with control-c, and then :q from the break.
>    >    If the form above completes, just try it again.  Eventually I think
>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
>    >
>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
>    > follows, on lhug-0 (a 64-bit linux machine):
>    >
>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
>    >
>    > where "my-fast-gcl" is a script containing:
>    >
>    > #!/bin/sh
>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
>    >
>    > Also by the way, if you instead run the following on a 32-bit UT CS
>    > linux machine
>    >
>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
>    >
>    > then you won't see the interrupt problem described above (or at least,
>    > I didn't, and I tried).
>    >
>    > Thanks --
>    > -- Matt
>    >
>    >
>    >
>    >
>
>    --
>    Camm Maguire        camm@...
>    ==========================================================================
>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>
>
>
>

--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Gabriel Dos Reis-2]

Camm Maguire <camm@...> writes:

| Greetings!
|
| Yes, safety, which stands for 'safety level 3', essentially passes all
| function calls through the interpreter, disables inlining, etc.  2.7.0
| has made this less severe, while reserving the old mode for safety
| level 4.  In any case, one gets code with most checks with safety
| level 2 (declaim (optimize (safety 2))).  The precise definitions were
| discussed in an earlier post if interested.  We can revisit this if
| desired.
|
| I think one could do an open axiom test of the -g effects with
|
| (setq compiler:*cc* (concatenate 'string compiler::*cc* " -g "))
|
| If you get timing results I'd be interested.

Hi Camm,

  Including "-g" in the GCL compiler's command line wasn't as straight
as I thought (somehow the use of LINK seems to forget that setting)

I believe I've managed to convince GCL.  The numbers are in:

    * pristine OpenAxiom (trunk)
       make  1624.70s user 102.77s system 99% cpu 28:57.07 total

    * modified OpenAxiom
       make  1672.23s user 107.45s system 100% cpu 29:35.42 total

this is with GCL-2.6.8pre on a dual-core with 4GB RAM, and 4GB cache
size each at 2.40Gz, running opensuse-10.3.

-- Gaby


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings!

Gabriel Dos Reis <gdr@...> writes:

> Camm Maguire <camm@...> writes:
>
> | Greetings!
> |
> | Yes, safety, which stands for 'safety level 3', essentially passes all
> | function calls through the interpreter, disables inlining, etc.  2.7.0
> | has made this less severe, while reserving the old mode for safety
> | level 4.  In any case, one gets code with most checks with safety
> | level 2 (declaim (optimize (safety 2))).  The precise definitions were
> | discussed in an earlier post if interested.  We can revisit this if
> | desired.
> |
> | I think one could do an open axiom test of the -g effects with
> |
> | (setq compiler:*cc* (concatenate 'string compiler::*cc* " -g "))
> |
> | If you get timing results I'd be interested.
>
> Hi Camm,
>
>   Including "-g" in the GCL compiler's command line wasn't as straight
> as I thought (somehow the use of LINK seems to forget that setting)
>
> I believe I've managed to convince GCL.  The numbers are in:
>
>     * pristine OpenAxiom (trunk)
>        make  1624.70s user 102.77s system 99% cpu 28:57.07 total
>
>     * modified OpenAxiom
>        make  1672.23s user 107.45s system 100% cpu 29:35.42 total
>

Great!  And thanks!  If you still have the builds, what about

1) the image sizes and
2) the time of the axiom test suite run?

Take care,

> this is with GCL-2.6.8pre on a dual-core with 4GB RAM, and 4GB cache
> size each at 2.40Gz, running opensuse-10.3.
>
> -- Gaby
>
>
>
>

--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Matt Kaufmann]

Thanks, Dave!  I really appreciate it.

When I get the word from you, or when I see
/lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
top of it and try to reproduce the problem.

Thanks again --
-- Matt
   Date: Mon, 23 Feb 2009 10:13:54 -0600
   From: "David A. Kotz" <dkotz@...>
   CC: Matt Kaufmann <kaufmann@...>, gripe@...,
           gcl-devel@...

   I'll rebuild it with the debug flag.

   - dave


   Camm Maguire wrote:
   > Thanks!  Please let me know if you run into troubles here.
   >
   > Take care,
   >
   > Matt Kaufmann <kaufmann@...> writes:
   >
   >> Howdy --
   >>
   >> Thanks for the reply.
   >>
   >> If gripe@cs is willing to do (1), or to send me the exact configure
   >> and make commands and source directory used so that I can do it
   >> myself, then I'll try to reproduce the error by building ACL2 on top
   >> of it.  I'm assuming that --enable-debug is given to the configure
   >> command, not to make.
   >>
   >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
   >> know and we can explore (2).  In that case, if gripe@cs is willing to
   >> do it, great; then I'll try to reproduce the problem.  But if I'm to
   >> do the build, I'd need explicit instructions on how to "make sure -g
   >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
   >> Also I didn't understand the comment about makedefs.  But I guess we
   >> can ignore (2) if (1) works.
   >>
   >> -- Matt
   >>    Cc: gcl-devel@..., gripe@...
   >>    From: Camm Maguire <camm@...>
   >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
   >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   >>    X-UTCS-Spam-Status: No, hits=-282 required=165
   >>
   >>    Greetings!  I suspect a missing signal block around some code that
   >>    needs protecting.  I've reprodced under gdb, but there are no
   >>    debugging symbols in the image.  [ Question for list -- have computers
   >>    now become so fast that -g should be included by default in all gcl
   >>    images? It used to slow down the compiler, don't know about now.  It
   >>    does make the image quite a bit bigger. ]
   >>
   >>    Ideally, you or someone else at the site might be so kind as to
   >>    rebuild atop
   >>
   >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
   >>    in addition
   >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
   >>    set to -g before configure and make.  Please make sure -g is included
   >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
   >>    and before make to include -g wherever one sees -O3 or -O
   >>
   >>    Would this be too much trouble?
   >>
   >>    Take care,
   >>
   >>    Matt Kaufmann <kaufmann@...> writes:
   >>
   >>    > Hi --
   >>    >
   >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
   >>    > suggested.  It's working great on 32-bit linux, but I've run into an
   >>    > issue for 64-bit linux.
   >>    >
   >>    > You can re-create the issue on a UT CS 64-bit linux machine as
   >>    > follows.
   >>    >
   >>    > Start up ACL2 built on GCL, as follows:
   >>    >
   >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
   >>    >
   >>    > Then issue these commands:
   >>    >
   >>    >   ; Just to slow down the output from the next form:
   >>    >   (trace$ rewrite)
   >>    >
   >>    >   ; ACL2 disables the debugger by default; this restores it:
   >>    >   (set-debugger-enable t)
   >>    >
   >>    >   ; This goes pretty fast but you'll have time to interrupt it:
   >>    >   (thm (equal (append (append x x) x) (append x x x)))
   >>    >
   >>    >   [Now quickly interrupt with control-c, and then :q from the break.
   >>    >    If the form above completes, just try it again.  Eventually I think
   >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >>    >
   >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
   >>    > follows, on lhug-0 (a 64-bit linux machine):
   >>    >
   >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
   >>    >
   >>    > where "my-fast-gcl" is a script containing:
   >>    >
   >>    > #!/bin/sh
   >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
   >>    >
   >>    > Also by the way, if you instead run the following on a 32-bit UT CS
   >>    > linux machine
   >>    >
   >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
   >>    >
   >>    > then you won't see the interrupt problem described above (or at least,
   >>    > I didn't, and I tried).
   >>    >
   >>    > Thanks --
   >>    > -- Matt
   >>    >
   >>    >
   >>    >
   >>    >
   >>
   >>    --
   >>    Camm Maguire        camm@...
   >>    ==========================================================================
   >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
   >>
   >>
   >>
   >>
   >



_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Matt Kaufmann]

Thanks, Dave.  When you say "both of our 64bit flavors", to what do
you refer?  I was only aware of /lusr/opt/gcl-2.6.8pre/bin/gcl.

Thanks --
-- Matt
   Date: Mon, 23 Feb 2009 17:12:04 -0600
   From: "David A. Kotz" <dkotz@...>
   CC: camm@..., gripe@..., gcl-devel@...

   I've replaced both of our 64bit flavors and the 32bit with debug-enabled
   versions.  The 64s are in place now, and the 32 should rdist around
   tonight.  I want to keep all of them in sync, even if we're only
   investigating a problem in one.

   - dave


   Matt Kaufmann wrote:
   > Thanks, Dave!  I really appreciate it.
   >
   > When I get the word from you, or when I see
   > /lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
   > top of it and try to reproduce the problem.
   >
   > Thanks again --
   > -- Matt
   >    Date: Mon, 23 Feb 2009 10:13:54 -0600
   >    From: "David A. Kotz" <dkotz@...>
   >    CC: Matt Kaufmann <kaufmann@...>, gripe@...,
   >   gcl-devel@...
   >
   >    I'll rebuild it with the debug flag.
   >
   >    - dave
   >
   >
   >    Camm Maguire wrote:
   >    > Thanks!  Please let me know if you run into troubles here.
   >    >
   >    > Take care,
   >    >
   >    > Matt Kaufmann <kaufmann@...> writes:
   >    >
   >    >> Howdy --
   >    >>
   >    >> Thanks for the reply.
   >    >>
   >    >> If gripe@cs is willing to do (1), or to send me the exact configure
   >    >> and make commands and source directory used so that I can do it
   >    >> myself, then I'll try to reproduce the error by building ACL2 on top
   >    >> of it.  I'm assuming that --enable-debug is given to the configure
   >    >> command, not to make.
   >    >>
   >    >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
   >    >> know and we can explore (2).  In that case, if gripe@cs is willing to
   >    >> do it, great; then I'll try to reproduce the problem.  But if I'm to
   >    >> do the build, I'd need explicit instructions on how to "make sure -g
   >    >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
   >    >> Also I didn't understand the comment about makedefs.  But I guess we
   >    >> can ignore (2) if (1) works.
   >    >>
   >    >> -- Matt
   >    >>    Cc: gcl-devel@..., gripe@...
   >    >>    From: Camm Maguire <camm@...>
   >    >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
   >    >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   >    >>    X-UTCS-Spam-Status: No, hits=-282 required=165
   >    >>
   >    >>    Greetings!  I suspect a missing signal block around some code that
   >    >>    needs protecting.  I've reprodced under gdb, but there are no
   >    >>    debugging symbols in the image.  [ Question for list -- have computers
   >    >>    now become so fast that -g should be included by default in all gcl
   >    >>    images? It used to slow down the compiler, don't know about now.  It
   >    >>    does make the image quite a bit bigger. ]
   >    >>
   >    >>    Ideally, you or someone else at the site might be so kind as to
   >    >>    rebuild atop
   >    >>
   >    >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
   >    >>    in addition
   >    >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
   >    >>    set to -g before configure and make.  Please make sure -g is included
   >    >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
   >    >>    and before make to include -g wherever one sees -O3 or -O
   >    >>
   >    >>    Would this be too much trouble?
   >    >>
   >    >>    Take care,
   >    >>
   >    >>    Matt Kaufmann <kaufmann@...> writes:
   >    >>
   >    >>    > Hi --
   >    >>    >
   >    >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
   >    >>    > suggested.  It's working great on 32-bit linux, but I've run into an
   >    >>    > issue for 64-bit linux.
   >    >>    >
   >    >>    > You can re-create the issue on a UT CS 64-bit linux machine as
   >    >>    > follows.
   >    >>    >
   >    >>    > Start up ACL2 built on GCL, as follows:
   >    >>    >
   >    >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
   >    >>    >
   >    >>    > Then issue these commands:
   >    >>    >
   >    >>    >   ; Just to slow down the output from the next form:
   >    >>    >   (trace$ rewrite)
   >    >>    >
   >    >>    >   ; ACL2 disables the debugger by default; this restores it:
   >    >>    >   (set-debugger-enable t)
   >    >>    >
   >    >>    >   ; This goes pretty fast but you'll have time to interrupt it:
   >    >>    >   (thm (equal (append (append x x) x) (append x x x)))
   >    >>    >
   >    >>    >   [Now quickly interrupt with control-c, and then :q from the break.
   >    >>    >    If the form above completes, just try it again.  Eventually I think
   >    >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >    >>    >
   >    >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
   >    >>    > follows, on lhug-0 (a 64-bit linux machine):
   >    >>    >
   >    >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
   >    >>    >
   >    >>    > where "my-fast-gcl" is a script containing:
   >    >>    >
   >    >>    > #!/bin/sh
   >    >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
   >    >>    >
   >    >>    > Also by the way, if you instead run the following on a 32-bit UT CS
   >    >>    > linux machine
   >    >>    >
   >    >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
   >    >>    >
   >    >>    > then you won't see the interrupt problem described above (or at least,
   >    >>    > I didn't, and I tried).
   >    >>    >
   >    >>    > Thanks --
   >    >>    > -- Matt
   >    >>    >
   >    >>    >
   >    >>    >
   >    >>    >
   >    >>
   >    >>    --
   >    >>    Camm Maguire        camm@...
   >    >>    ==========================================================================
   >    >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
   >    >>
   >    >>
   >    >>
   >    >>
   >    >



_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Matt Kaufmann]

Hi --

I was able to reproduce the error after building ACL2 a new debug copy
of 64-bit gcl that the sysadmins built.  Same instructions as before,
except for a slight change in the ACL2 executable directory.  Quoting
from below, but updating the executable path (and fixing a misleading
comment):

  Start up ACL2 built on GCL, as follows:

  /projects/acl2/v3-4-linux-64/fast-linux-gcl-saved_acl2

  Then issue these commands:

    ; Just to slow down the output from the thm form below:
    (trace$ rewrite)

    ; ACL2 disables the debugger by default; this restores it:
    (set-debugger-enable t)

    ; This goes pretty fast but you'll have time to interrupt it:
    (thm (equal (append (append x x) x) (append x x x)))

    [Now quickly interrupt with control-c, and then :q from the break.
     If the form above completes, just try it again.  Eventually I think
     you'll see a Lisp "fatal error" or even a "Segmentation fault".]

It seems to take me about 3 to 5 THM calls to get the error, which
looks like this:

  ACL2 !>(thm (equal (append (append x x) x) (append x x x)))
  [SGC off]
  Error: Caught fatal error [memory may be damaged]
  Fast links are on: do (si::use-fast-links nil) for debugging
  Error signalled by ACL2_*1*_ACL2::THM-FN.
  Broken at COND.  Type :H for Help.
  ACL2[RAW LISP]>>

-- Matt
   Date: Mon, 23 Feb 2009 17:12:04 -0600
   From: "David A. Kotz" <dkotz@...>
   CC: camm@..., gripe@..., gcl-devel@...

   I've replaced both of our 64bit flavors and the 32bit with debug-enabled
   versions.  The 64s are in place now, and the 32 should rdist around
   tonight.  I want to keep all of them in sync, even if we're only
   investigating a problem in one.

   - dave


   Matt Kaufmann wrote:
   > Thanks, Dave!  I really appreciate it.
   >
   > When I get the word from you, or when I see
   > /lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
   > top of it and try to reproduce the problem.
   >
   > Thanks again --
   > -- Matt
   >    Date: Mon, 23 Feb 2009 10:13:54 -0600
   >    From: "David A. Kotz" <dkotz@...>
   >    CC: Matt Kaufmann <kaufmann@...>, gripe@...,
   >   gcl-devel@...
   >
   >    I'll rebuild it with the debug flag.
   >
   >    - dave
   >
   >
   >    Camm Maguire wrote:
   >    > Thanks!  Please let me know if you run into troubles here.
   >    >
   >    > Take care,
   >    >
   >    > Matt Kaufmann <kaufmann@...> writes:
   >    >
   >    >> Howdy --
   >    >>
   >    >> Thanks for the reply.
   >    >>
   >    >> If gripe@cs is willing to do (1), or to send me the exact configure
   >    >> and make commands and source directory used so that I can do it
   >    >> myself, then I'll try to reproduce the error by building ACL2 on top
   >    >> of it.  I'm assuming that --enable-debug is given to the configure
   >    >> command, not to make.
   >    >>
   >    >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
   >    >> know and we can explore (2).  In that case, if gripe@cs is willing to
   >    >> do it, great; then I'll try to reproduce the problem.  But if I'm to
   >    >> do the build, I'd need explicit instructions on how to "make sure -g
   >    >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
   >    >> Also I didn't understand the comment about makedefs.  But I guess we
   >    >> can ignore (2) if (1) works.
   >    >>
   >    >> -- Matt
   >    >>    Cc: gcl-devel@..., gripe@...
   >    >>    From: Camm Maguire <camm@...>
   >    >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
   >    >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   >    >>    X-UTCS-Spam-Status: No, hits=-282 required=165
   >    >>
   >    >>    Greetings!  I suspect a missing signal block around some code that
   >    >>    needs protecting.  I've reprodced under gdb, but there are no
   >    >>    debugging symbols in the image.  [ Question for list -- have computers
   >    >>    now become so fast that -g should be included by default in all gcl
   >    >>    images? It used to slow down the compiler, don't know about now.  It
   >    >>    does make the image quite a bit bigger. ]
   >    >>
   >    >>    Ideally, you or someone else at the site might be so kind as to
   >    >>    rebuild atop
   >    >>
   >    >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
   >    >>    in addition
   >    >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
   >    >>    set to -g before configure and make.  Please make sure -g is included
   >    >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
   >    >>    and before make to include -g wherever one sees -O3 or -O
   >    >>
   >    >>    Would this be too much trouble?
   >    >>
   >    >>    Take care,
   >    >>
   >    >>    Matt Kaufmann <kaufmann@...> writes:
   >    >>
   >    >>    > Hi --
   >    >>    >
   >    >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
   >    >>    > suggested.  It's working great on 32-bit linux, but I've run into an
   >    >>    > issue for 64-bit linux.
   >    >>    >
   >    >>    > You can re-create the issue on a UT CS 64-bit linux machine as
   >    >>    > follows.
   >    >>    >
   >    >>    > Start up ACL2 built on GCL, as follows:
   >    >>    >
   >    >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
   >    >>    >
   >    >>    > Then issue these commands:
   >    >>    >
   >    >>    >   ; Just to slow down the output from the next form:
   >    >>    >   (trace$ rewrite)
   >    >>    >
   >    >>    >   ; ACL2 disables the debugger by default; this restores it:
   >    >>    >   (set-debugger-enable t)
   >    >>    >
   >    >>    >   ; This goes pretty fast but you'll have time to interrupt it:
   >    >>    >   (thm (equal (append (append x x) x) (append x x x)))
   >    >>    >
   >    >>    >   [Now quickly interrupt with control-c, and then :q from the break.
   >    >>    >    If the form above completes, just try it again.  Eventually I think
   >    >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >    >>    >
   >    >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
   >    >>    > follows, on lhug-0 (a 64-bit linux machine):
   >    >>    >
   >    >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
   >    >>    >
   >    >>    > where "my-fast-gcl" is a script containing:
   >    >>    >
   >    >>    > #!/bin/sh
   >    >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
   >    >>    >
   >    >>    > Also by the way, if you instead run the following on a 32-bit UT CS
   >    >>    > linux machine
   >    >>    >
   >    >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
   >    >>    >
   >    >>    > then you won't see the interrupt problem described above (or at least,
   >    >>    > I didn't, and I tried).
   >    >>    >
   >    >>    > Thanks --
   >    >>    > -- Matt
   >    >>    >
   >    >>    >
   >    >>    >
   >    >>    >
   >    >>
   >    >>    --
   >    >>    Camm Maguire        camm@...
   >    >>    ==========================================================================
   >    >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
   >    >>
   >    >>
   >    >>
   >    >>
   >    >


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings!  OK, suprisingly enough I think I might have indirectly
deduced what is going on.  It is verifiably independent of SGC, but
appears related to 64bit only by the enhanced time window possible in
which to receive SIGINT.

In short, could you please send me (and post to gcl-devel) the
instructions for rebuilding your source again against a patched gcl
tree for testing.

This does bring up the legacy gcl signal handling code, which is quite
clever given the age in which it was developed, but has since been
made somewhat obsolete by recent system developments, at least on
Linux.

The GCL strategy is to maintain global variables tracking pending and
blcked signals, and to loop over alarm(1) until the unblocking code
snippet is executed.  (i.e. BEGIN_NO_INTERRUPT and END_NO_INTERRUPT,
which essentially set signals_allowed to 0 and restores the previous
value respectively).  Nowadays, bracketing the code needing protection
directly with sigprocmask is more typical.  Heaven knows what
portability issues are involved in making this change.

The bug appears to be that critical GC code is not protected against
interrupts and subsequent possible longjumps.  Specifically,
add_page_to_freelist is apparently allowing partially initialized
freelists to escape.  An immediate fix would be at hand in this case,
but more systematically we need to review the areas this protection is
required and come up with a decent centralization policy.  I don't
think there is any reason to clock signals other that object creation,
gc, and anything modifying tm_table.  Other thoughts most welcome.

Take care,



Matt Kaufmann <kaufmann@...> writes:

> Hi --
>
> I was able to reproduce the error after building ACL2 a new debug copy
> of 64-bit gcl that the sysadmins built.  Same instructions as before,
> except for a slight change in the ACL2 executable directory.  Quoting
> from below, but updating the executable path (and fixing a misleading
> comment):
>
>   Start up ACL2 built on GCL, as follows:
>
>   /projects/acl2/v3-4-linux-64/fast-linux-gcl-saved_acl2
>
>   Then issue these commands:
>
>     ; Just to slow down the output from the thm form below:
>     (trace$ rewrite)
>
>     ; ACL2 disables the debugger by default; this restores it:
>     (set-debugger-enable t)
>
>     ; This goes pretty fast but you'll have time to interrupt it:
>     (thm (equal (append (append x x) x) (append x x x)))
>
>     [Now quickly interrupt with control-c, and then :q from the break.
>      If the form above completes, just try it again.  Eventually I think
>      you'll see a Lisp "fatal error" or even a "Segmentation fault".]
>
> It seems to take me about 3 to 5 THM calls to get the error, which
> looks like this:
>
>   ACL2 !>(thm (equal (append (append x x) x) (append x x x)))
>   [SGC off]
>   Error: Caught fatal error [memory may be damaged]
>   Fast links are on: do (si::use-fast-links nil) for debugging
>   Error signalled by ACL2_*1*_ACL2::THM-FN.
>   Broken at COND.  Type :H for Help.
>   ACL2[RAW LISP]>>
>
> -- Matt
>    Date: Mon, 23 Feb 2009 17:12:04 -0600
>    From: "David A. Kotz" <dkotz@...>
>    CC: camm@..., gripe@..., gcl-devel@...
>
>    I've replaced both of our 64bit flavors and the 32bit with debug-enabled
>    versions.  The 64s are in place now, and the 32 should rdist around
>    tonight.  I want to keep all of them in sync, even if we're only
>    investigating a problem in one.
>
>    - dave
>
>
>    Matt Kaufmann wrote:
>    > Thanks, Dave!  I really appreciate it.
>    >
>    > When I get the word from you, or when I see
>    > /lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
>    > top of it and try to reproduce the problem.
>    >
>    > Thanks again --
>    > -- Matt
>    >    Date: Mon, 23 Feb 2009 10:13:54 -0600
>    >    From: "David A. Kotz" <dkotz@...>
>    >    CC: Matt Kaufmann <kaufmann@...>, gripe@...,
>    >   gcl-devel@...
>    >
>    >    I'll rebuild it with the debug flag.
>    >
>    >    - dave
>    >
>    >
>    >    Camm Maguire wrote:
>    >    > Thanks!  Please let me know if you run into troubles here.
>    >    >
>    >    > Take care,
>    >    >
>    >    > Matt Kaufmann <kaufmann@...> writes:
>    >    >
>    >    >> Howdy --
>    >    >>
>    >    >> Thanks for the reply.
>    >    >>
>    >    >> If gripe@cs is willing to do (1), or to send me the exact configure
>    >    >> and make commands and source directory used so that I can do it
>    >    >> myself, then I'll try to reproduce the error by building ACL2 on top
>    >    >> of it.  I'm assuming that --enable-debug is given to the configure
>    >    >> command, not to make.
>    >    >>
>    >    >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
>    >    >> know and we can explore (2).  In that case, if gripe@cs is willing to
>    >    >> do it, great; then I'll try to reproduce the problem.  But if I'm to
>    >    >> do the build, I'd need explicit instructions on how to "make sure -g
>    >    >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
>    >    >> Also I didn't understand the comment about makedefs.  But I guess we
>    >    >> can ignore (2) if (1) works.
>    >    >>
>    >    >> -- Matt
>    >    >>    Cc: gcl-devel@..., gripe@...
>    >    >>    From: Camm Maguire <camm@...>
>    >    >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
>    >    >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
>    >    >>    X-UTCS-Spam-Status: No, hits=-282 required=165
>    >    >>
>    >    >>    Greetings!  I suspect a missing signal block around some code that
>    >    >>    needs protecting.  I've reprodced under gdb, but there are no
>    >    >>    debugging symbols in the image.  [ Question for list -- have computers
>    >    >>    now become so fast that -g should be included by default in all gcl
>    >    >>    images? It used to slow down the compiler, don't know about now.  It
>    >    >>    does make the image quite a bit bigger. ]
>    >    >>
>    >    >>    Ideally, you or someone else at the site might be so kind as to
>    >    >>    rebuild atop
>    >    >>
>    >    >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
>    >    >>    in addition
>    >    >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
>    >    >>    set to -g before configure and make.  Please make sure -g is included
>    >    >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
>    >    >>    and before make to include -g wherever one sees -O3 or -O
>    >    >>
>    >    >>    Would this be too much trouble?
>    >    >>
>    >    >>    Take care,
>    >    >>
>    >    >>    Matt Kaufmann <kaufmann@...> writes:
>    >    >>
>    >    >>    > Hi --
>    >    >>    >
>    >    >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
>    >    >>    > suggested.  It's working great on 32-bit linux, but I've run into an
>    >    >>    > issue for 64-bit linux.
>    >    >>    >
>    >    >>    > You can re-create the issue on a UT CS 64-bit linux machine as
>    >    >>    > follows.
>    >    >>    >
>    >    >>    > Start up ACL2 built on GCL, as follows:
>    >    >>    >
>    >    >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
>    >    >>    >
>    >    >>    > Then issue these commands:
>    >    >>    >
>    >    >>    >   ; Just to slow down the output from the next form:
>    >    >>    >   (trace$ rewrite)
>    >    >>    >
>    >    >>    >   ; ACL2 disables the debugger by default; this restores it:
>    >    >>    >   (set-debugger-enable t)
>    >    >>    >
>    >    >>    >   ; This goes pretty fast but you'll have time to interrupt it:
>    >    >>    >   (thm (equal (append (append x x) x) (append x x x)))
>    >    >>    >
>    >    >>    >   [Now quickly interrupt with control-c, and then :q from the break.
>    >    >>    >    If the form above completes, just try it again.  Eventually I think
>    >    >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
>    >    >>    >
>    >    >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
>    >    >>    > follows, on lhug-0 (a 64-bit linux machine):
>    >    >>    >
>    >    >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
>    >    >>    >
>    >    >>    > where "my-fast-gcl" is a script containing:
>    >    >>    >
>    >    >>    > #!/bin/sh
>    >    >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
>    >    >>    >
>    >    >>    > Also by the way, if you instead run the following on a 32-bit UT CS
>    >    >>    > linux machine
>    >    >>    >
>    >    >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
>    >    >>    >
>    >    >>    > then you won't see the interrupt problem described above (or at least,
>    >    >>    > I didn't, and I tried).
>    >    >>    >
>    >    >>    > Thanks --
>    >    >>    > -- Matt
>    >    >>    >
>    >    >>    >
>    >    >>    >
>    >    >>    >
>    >    >>
>    >    >>    --
>    >    >>    Camm Maguire        camm@...
>    >    >>    ==========================================================================
>    >    >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>    >    >>
>    >    >>
>    >    >>
>    >    >>
>    >    >
>
>
>
>

--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Matt Kaufmann]

Great!  Thank you.  Dave, if you send me your build instructions, I'll
forward them along since you're (I'm guessing) not on the gcl-devel
list, which only allows posts from members.

Thanks --
-- Matt
   Cc: dkotz@..., gripe@..., gcl-devel@...
   From: Camm Maguire <camm@...>
   Date: Wed, 25 Feb 2009 15:03:41 -0500
   X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   X-UTCS-Spam-Status: No, hits=-282 required=165

   Greetings!  OK, suprisingly enough I think I might have indirectly
   deduced what is going on.  It is verifiably independent of SGC, but
   appears related to 64bit only by the enhanced time window possible in
   which to receive SIGINT.

   In short, could you please send me (and post to gcl-devel) the
   instructions for rebuilding your source again against a patched gcl
   tree for testing.

   This does bring up the legacy gcl signal handling code, which is quite
   clever given the age in which it was developed, but has since been
   made somewhat obsolete by recent system developments, at least on
   Linux.

   The GCL strategy is to maintain global variables tracking pending and
   blcked signals, and to loop over alarm(1) until the unblocking code
   snippet is executed.  (i.e. BEGIN_NO_INTERRUPT and END_NO_INTERRUPT,
   which essentially set signals_allowed to 0 and restores the previous
   value respectively).  Nowadays, bracketing the code needing protection
   directly with sigprocmask is more typical.  Heaven knows what
   portability issues are involved in making this change.

   The bug appears to be that critical GC code is not protected against
   interrupts and subsequent possible longjumps.  Specifically,
   add_page_to_freelist is apparently allowing partially initialized
   freelists to escape.  An immediate fix would be at hand in this case,
   but more systematically we need to review the areas this protection is
   required and come up with a decent centralization policy.  I don't
   think there is any reason to clock signals other that object creation,
   gc, and anything modifying tm_table.  Other thoughts most welcome.

   Take care,



   Matt Kaufmann <kaufmann@...> writes:

   > Hi --
   >
   > I was able to reproduce the error after building ACL2 a new debug copy
   > of 64-bit gcl that the sysadmins built.  Same instructions as before,
   > except for a slight change in the ACL2 executable directory.  Quoting
   > from below, but updating the executable path (and fixing a misleading
   > comment):
   >
   >   Start up ACL2 built on GCL, as follows:
   >
   >   /projects/acl2/v3-4-linux-64/fast-linux-gcl-saved_acl2
   >
   >   Then issue these commands:
   >
   >     ; Just to slow down the output from the thm form below:
   >     (trace$ rewrite)
   >
   >     ; ACL2 disables the debugger by default; this restores it:
   >     (set-debugger-enable t)
   >
   >     ; This goes pretty fast but you'll have time to interrupt it:
   >     (thm (equal (append (append x x) x) (append x x x)))
   >
   >     [Now quickly interrupt with control-c, and then :q from the break.
   >      If the form above completes, just try it again.  Eventually I think
   >      you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >
   > It seems to take me about 3 to 5 THM calls to get the error, which
   > looks like this:
   >
   >   ACL2 !>(thm (equal (append (append x x) x) (append x x x)))
   >   [SGC off]
   >   Error: Caught fatal error [memory may be damaged]
   >   Fast links are on: do (si::use-fast-links nil) for debugging
   >   Error signalled by ACL2_*1*_ACL2::THM-FN.
   >   Broken at COND.  Type :H for Help.
   >   ACL2[RAW LISP]>>
   >
   > -- Matt
   >    Date: Mon, 23 Feb 2009 17:12:04 -0600
   >    From: "David A. Kotz" <dkotz@...>
   >    CC: camm@..., gripe@..., gcl-devel@...
   >
   >    I've replaced both of our 64bit flavors and the 32bit with debug-enabled
   >    versions.  The 64s are in place now, and the 32 should rdist around
   >    tonight.  I want to keep all of them in sync, even if we're only
   >    investigating a problem in one.
   >
   >    - dave
   >
   >
   >    Matt Kaufmann wrote:
   >    > Thanks, Dave!  I really appreciate it.
   >    >
   >    > When I get the word from you, or when I see
   >    > /lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
   >    > top of it and try to reproduce the problem.
   >    >
   >    > Thanks again --
   >    > -- Matt
   >    >    Date: Mon, 23 Feb 2009 10:13:54 -0600
   >    >    From: "David A. Kotz" <dkotz@...>
   >    >    CC: Matt Kaufmann <kaufmann@...>, gripe@...,
   >    >   gcl-devel@...
   >    >
   >    >    I'll rebuild it with the debug flag.
   >    >
   >    >    - dave
   >    >
   >    >
   >    >    Camm Maguire wrote:
   >    >    > Thanks!  Please let me know if you run into troubles here.
   >    >    >
   >    >    > Take care,
   >    >    >
   >    >    > Matt Kaufmann <kaufmann@...> writes:
   >    >    >
   >    >    >> Howdy --
   >    >    >>
   >    >    >> Thanks for the reply.
   >    >    >>
   >    >    >> If gripe@cs is willing to do (1), or to send me the exact configure
   >    >    >> and make commands and source directory used so that I can do it
   >    >    >> myself, then I'll try to reproduce the error by building ACL2 on top
   >    >    >> of it.  I'm assuming that --enable-debug is given to the configure
   >    >    >> command, not to make.
   >    >    >>
   >    >    >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
   >    >    >> know and we can explore (2).  In that case, if gripe@cs is willing to
   >    >    >> do it, great; then I'll try to reproduce the problem.  But if I'm to
   >    >    >> do the build, I'd need explicit instructions on how to "make sure -g
   >    >    >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
   >    >    >> Also I didn't understand the comment about makedefs.  But I guess we
   >    >    >> can ignore (2) if (1) works.
   >    >    >>
   >    >    >> -- Matt
   >    >    >>    Cc: gcl-devel@..., gripe@...
   >    >    >>    From: Camm Maguire <camm@...>
   >    >    >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
   >    >    >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   >    >    >>    X-UTCS-Spam-Status: No, hits=-282 required=165
   >    >    >>
   >    >    >>    Greetings!  I suspect a missing signal block around some code that
   >    >    >>    needs protecting.  I've reprodced under gdb, but there are no
   >    >    >>    debugging symbols in the image.  [ Question for list -- have computers
   >    >    >>    now become so fast that -g should be included by default in all gcl
   >    >    >>    images? It used to slow down the compiler, don't know about now.  It
   >    >    >>    does make the image quite a bit bigger. ]
   >    >    >>
   >    >    >>    Ideally, you or someone else at the site might be so kind as to
   >    >    >>    rebuild atop
   >    >    >>
   >    >    >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
   >    >    >>    in addition
   >    >    >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
   >    >    >>    set to -g before configure and make.  Please make sure -g is included
   >    >    >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
   >    >    >>    and before make to include -g wherever one sees -O3 or -O
   >    >    >>
   >    >    >>    Would this be too much trouble?
   >    >    >>
   >    >    >>    Take care,
   >    >    >>
   >    >    >>    Matt Kaufmann <kaufmann@...> writes:
   >    >    >>
   >    >    >>    > Hi --
   >    >    >>    >
   >    >    >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
   >    >    >>    > suggested.  It's working great on 32-bit linux, but I've run into an
   >    >    >>    > issue for 64-bit linux.
   >    >    >>    >
   >    >    >>    > You can re-create the issue on a UT CS 64-bit linux machine as
   >    >    >>    > follows.
   >    >    >>    >
   >    >    >>    > Start up ACL2 built on GCL, as follows:
   >    >    >>    >
   >    >    >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
   >    >    >>    >
   >    >    >>    > Then issue these commands:
   >    >    >>    >
   >    >    >>    >   ; Just to slow down the output from the next form:
   >    >    >>    >   (trace$ rewrite)
   >    >    >>    >
   >    >    >>    >   ; ACL2 disables the debugger by default; this restores it:
   >    >    >>    >   (set-debugger-enable t)
   >    >    >>    >
   >    >    >>    >   ; This goes pretty fast but you'll have time to interrupt it:
   >    >    >>    >   (thm (equal (append (append x x) x) (append x x x)))
   >    >    >>    >
   >    >    >>    >   [Now quickly interrupt with control-c, and then :q from the break.
   >    >    >>    >    If the form above completes, just try it again.  Eventually I think
   >    >    >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >    >    >>    >
   >    >    >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
   >    >    >>    > follows, on lhug-0 (a 64-bit linux machine):
   >    >    >>    >
   >    >    >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
   >    >    >>    >
   >    >    >>    > where "my-fast-gcl" is a script containing:
   >    >    >>    >
   >    >    >>    > #!/bin/sh
   >    >    >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
   >    >    >>    >
   >    >    >>    > Also by the way, if you instead run the following on a 32-bit UT CS
   >    >    >>    > linux machine
   >    >    >>    >
   >    >    >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
   >    >    >>    >
   >    >    >>    > then you won't see the interrupt problem described above (or at least,
   >    >    >>    > I didn't, and I tried).
   >    >    >>    >
   >    >    >>    > Thanks --
   >    >    >>    > -- Matt
   >    >    >>    >
   >    >    >>    >
   >    >    >>    >
   >    >    >>    >
   >    >    >>
   >    >    >>    --
   >    >    >>    Camm Maguire        camm@...
   >    >    >>    ==========================================================================
   >    >    >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
   >    >    >>
   >    >    >>
   >    >    >>
   >    >    >>
   >    >    >
   >
   >
   >
   >

   --
   Camm Maguire        camm@...
   ==========================================================================
   "The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings!  Could you please post a sample C file, together with
preprocessed output?  cpp -I <gclsrc>/h foo.c should do.

For example, elt is complained about, but has a prototype in
cmpinclude.h as follows:

object elt();

Has the void generic argument list prototype changed its approval
status?

Take care,
--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings, and thanks!  OK, this is fixed now in branch 2.6.8pre of
cvs, and will be in cvs head soon.  Please let me know if you need a
reminder about how to get 2.6.8pre.

Take care,

Matt Kaufmann <kaufmann@...> writes:

> Hi --
>
> I was able to reproduce the error after building ACL2 a new debug copy
> of 64-bit gcl that the sysadmins built.  Same instructions as before,
> except for a slight change in the ACL2 executable directory.  Quoting
> from below, but updating the executable path (and fixing a misleading
> comment):
>
>   Start up ACL2 built on GCL, as follows:
>
>   /projects/acl2/v3-4-linux-64/fast-linux-gcl-saved_acl2
>
>   Then issue these commands:
>
>     ; Just to slow down the output from the thm form below:
>     (trace$ rewrite)
>
>     ; ACL2 disables the debugger by default; this restores it:
>     (set-debugger-enable t)
>
>     ; This goes pretty fast but you'll have time to interrupt it:
>     (thm (equal (append (append x x) x) (append x x x)))
>
>     [Now quickly interrupt with control-c, and then :q from the break.
>      If the form above completes, just try it again.  Eventually I think
>      you'll see a Lisp "fatal error" or even a "Segmentation fault".]
>
> It seems to take me about 3 to 5 THM calls to get the error, which
> looks like this:
>
>   ACL2 !>(thm (equal (append (append x x) x) (append x x x)))
>   [SGC off]
>   Error: Caught fatal error [memory may be damaged]
>   Fast links are on: do (si::use-fast-links nil) for debugging
>   Error signalled by ACL2_*1*_ACL2::THM-FN.
>   Broken at COND.  Type :H for Help.
>   ACL2[RAW LISP]>>
>
> -- Matt
>    Date: Mon, 23 Feb 2009 17:12:04 -0600
>    From: "David A. Kotz" <dkotz@...>
>    CC: camm@..., gripe@..., gcl-devel@...
>
>    I've replaced both of our 64bit flavors and the 32bit with debug-enabled
>    versions.  The 64s are in place now, and the 32 should rdist around
>    tonight.  I want to keep all of them in sync, even if we're only
>    investigating a problem in one.
>
>    - dave
>
>
>    Matt Kaufmann wrote:
>    > Thanks, Dave!  I really appreciate it.
>    >
>    > When I get the word from you, or when I see
>    > /lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
>    > top of it and try to reproduce the problem.
>    >
>    > Thanks again --
>    > -- Matt
>    >    Date: Mon, 23 Feb 2009 10:13:54 -0600
>    >    From: "David A. Kotz" <dkotz@...>
>    >    CC: Matt Kaufmann <kaufmann@...>, gripe@...,
>    >   gcl-devel@...
>    >
>    >    I'll rebuild it with the debug flag.
>    >
>    >    - dave
>    >
>    >
>    >    Camm Maguire wrote:
>    >    > Thanks!  Please let me know if you run into troubles here.
>    >    >
>    >    > Take care,
>    >    >
>    >    > Matt Kaufmann <kaufmann@...> writes:
>    >    >
>    >    >> Howdy --
>    >    >>
>    >    >> Thanks for the reply.
>    >    >>
>    >    >> If gripe@cs is willing to do (1), or to send me the exact configure
>    >    >> and make commands and source directory used so that I can do it
>    >    >> myself, then I'll try to reproduce the error by building ACL2 on top
>    >    >> of it.  I'm assuming that --enable-debug is given to the configure
>    >    >> command, not to make.
>    >    >>
>    >    >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
>    >    >> know and we can explore (2).  In that case, if gripe@cs is willing to
>    >    >> do it, great; then I'll try to reproduce the problem.  But if I'm to
>    >    >> do the build, I'd need explicit instructions on how to "make sure -g
>    >    >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
>    >    >> Also I didn't understand the comment about makedefs.  But I guess we
>    >    >> can ignore (2) if (1) works.
>    >    >>
>    >    >> -- Matt
>    >    >>    Cc: gcl-devel@..., gripe@...
>    >    >>    From: Camm Maguire <camm@...>
>    >    >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
>    >    >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
>    >    >>    X-UTCS-Spam-Status: No, hits=-282 required=165
>    >    >>
>    >    >>    Greetings!  I suspect a missing signal block around some code that
>    >    >>    needs protecting.  I've reprodced under gdb, but there are no
>    >    >>    debugging symbols in the image.  [ Question for list -- have computers
>    >    >>    now become so fast that -g should be included by default in all gcl
>    >    >>    images? It used to slow down the compiler, don't know about now.  It
>    >    >>    does make the image quite a bit bigger. ]
>    >    >>
>    >    >>    Ideally, you or someone else at the site might be so kind as to
>    >    >>    rebuild atop
>    >    >>
>    >    >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
>    >    >>    in addition
>    >    >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
>    >    >>    set to -g before configure and make.  Please make sure -g is included
>    >    >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
>    >    >>    and before make to include -g wherever one sees -O3 or -O
>    >    >>
>    >    >>    Would this be too much trouble?
>    >    >>
>    >    >>    Take care,
>    >    >>
>    >    >>    Matt Kaufmann <kaufmann@...> writes:
>    >    >>
>    >    >>    > Hi --
>    >    >>    >
>    >    >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
>    >    >>    > suggested.  It's working great on 32-bit linux, but I've run into an
>    >    >>    > issue for 64-bit linux.
>    >    >>    >
>    >    >>    > You can re-create the issue on a UT CS 64-bit linux machine as
>    >    >>    > follows.
>    >    >>    >
>    >    >>    > Start up ACL2 built on GCL, as follows:
>    >    >>    >
>    >    >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
>    >    >>    >
>    >    >>    > Then issue these commands:
>    >    >>    >
>    >    >>    >   ; Just to slow down the output from the next form:
>    >    >>    >   (trace$ rewrite)
>    >    >>    >
>    >    >>    >   ; ACL2 disables the debugger by default; this restores it:
>    >    >>    >   (set-debugger-enable t)
>    >    >>    >
>    >    >>    >   ; This goes pretty fast but you'll have time to interrupt it:
>    >    >>    >   (thm (equal (append (append x x) x) (append x x x)))
>    >    >>    >
>    >    >>    >   [Now quickly interrupt with control-c, and then :q from the break.
>    >    >>    >    If the form above completes, just try it again.  Eventually I think
>    >    >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
>    >    >>    >
>    >    >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
>    >    >>    > follows, on lhug-0 (a 64-bit linux machine):
>    >    >>    >
>    >    >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
>    >    >>    >
>    >    >>    > where "my-fast-gcl" is a script containing:
>    >    >>    >
>    >    >>    > #!/bin/sh
>    >    >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
>    >    >>    >
>    >    >>    > Also by the way, if you instead run the following on a 32-bit UT CS
>    >    >>    > linux machine
>    >    >>    >
>    >    >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
>    >    >>    >
>    >    >>    > then you won't see the interrupt problem described above (or at least,
>    >    >>    > I didn't, and I tried).
>    >    >>    >
>    >    >>    > Thanks --
>    >    >>    > -- Matt
>    >    >>    >
>    >    >>    >
>    >    >>    >
>    >    >>    >
>    >    >>
>    >    >>    --
>    >    >>    Camm Maguire        camm@...
>    >    >>    ==========================================================================
>    >    >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>    >    >>
>    >    >>
>    >    >>
>    >    >>
>    >    >
>
>
>
>

--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings!  There appears to be a gdb problem on lhug-0:

Program received signal SIGINT, Interrupt.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
0x00002aaaab9c8ab7 in ?? ()
(gdb)

Would anyone be so kind as to check this out for future debugging use?

Take care,

Matt Kaufmann <kaufmann@...> writes:

> Hi --
>
> I was able to reproduce the error after building ACL2 a new debug copy
> of 64-bit gcl that the sysadmins built.  Same instructions as before,
> except for a slight change in the ACL2 executable directory.  Quoting
> from below, but updating the executable path (and fixing a misleading
> comment):
>
>   Start up ACL2 built on GCL, as follows:
>
>   /projects/acl2/v3-4-linux-64/fast-linux-gcl-saved_acl2
>
>   Then issue these commands:
>
>     ; Just to slow down the output from the thm form below:
>     (trace$ rewrite)
>
>     ; ACL2 disables the debugger by default; this restores it:
>     (set-debugger-enable t)
>
>     ; This goes pretty fast but you'll have time to interrupt it:
>     (thm (equal (append (append x x) x) (append x x x)))
>
>     [Now quickly interrupt with control-c, and then :q from the break.
>      If the form above completes, just try it again.  Eventually I think
>      you'll see a Lisp "fatal error" or even a "Segmentation fault".]
>
> It seems to take me about 3 to 5 THM calls to get the error, which
> looks like this:
>
>   ACL2 !>(thm (equal (append (append x x) x) (append x x x)))
>   [SGC off]
>   Error: Caught fatal error [memory may be damaged]
>   Fast links are on: do (si::use-fast-links nil) for debugging
>   Error signalled by ACL2_*1*_ACL2::THM-FN.
>   Broken at COND.  Type :H for Help.
>   ACL2[RAW LISP]>>
>
> -- Matt
>    Date: Mon, 23 Feb 2009 17:12:04 -0600
>    From: "David A. Kotz" <dkotz@...>
>    CC: camm@..., gripe@..., gcl-devel@...
>
>    I've replaced both of our 64bit flavors and the 32bit with debug-enabled
>    versions.  The 64s are in place now, and the 32 should rdist around
>    tonight.  I want to keep all of them in sync, even if we're only
>    investigating a problem in one.
>
>    - dave
>
>
>    Matt Kaufmann wrote:
>    > Thanks, Dave!  I really appreciate it.
>    >
>    > When I get the word from you, or when I see
>    > /lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
>    > top of it and try to reproduce the problem.
>    >
>    > Thanks again --
>    > -- Matt
>    >    Date: Mon, 23 Feb 2009 10:13:54 -0600
>    >    From: "David A. Kotz" <dkotz@...>
>    >    CC: Matt Kaufmann <kaufmann@...>, gripe@...,
>    >   gcl-devel@...
>    >
>    >    I'll rebuild it with the debug flag.
>    >
>    >    - dave
>    >
>    >
>    >    Camm Maguire wrote:
>    >    > Thanks!  Please let me know if you run into troubles here.
>    >    >
>    >    > Take care,
>    >    >
>    >    > Matt Kaufmann <kaufmann@...> writes:
>    >    >
>    >    >> Howdy --
>    >    >>
>    >    >> Thanks for the reply.
>    >    >>
>    >    >> If gripe@cs is willing to do (1), or to send me the exact configure
>    >    >> and make commands and source directory used so that I can do it
>    >    >> myself, then I'll try to reproduce the error by building ACL2 on top
>    >    >> of it.  I'm assuming that --enable-debug is given to the configure
>    >    >> command, not to make.
>    >    >>
>    >    >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
>    >    >> know and we can explore (2).  In that case, if gripe@cs is willing to
>    >    >> do it, great; then I'll try to reproduce the problem.  But if I'm to
>    >    >> do the build, I'd need explicit instructions on how to "make sure -g
>    >    >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
>    >    >> Also I didn't understand the comment about makedefs.  But I guess we
>    >    >> can ignore (2) if (1) works.
>    >    >>
>    >    >> -- Matt
>    >    >>    Cc: gcl-devel@..., gripe@...
>    >    >>    From: Camm Maguire <camm@...>
>    >    >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
>    >    >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
>    >    >>    X-UTCS-Spam-Status: No, hits=-282 required=165
>    >    >>
>    >    >>    Greetings!  I suspect a missing signal block around some code that
>    >    >>    needs protecting.  I've reprodced under gdb, but there are no
>    >    >>    debugging symbols in the image.  [ Question for list -- have computers
>    >    >>    now become so fast that -g should be included by default in all gcl
>    >    >>    images? It used to slow down the compiler, don't know about now.  It
>    >    >>    does make the image quite a bit bigger. ]
>    >    >>
>    >    >>    Ideally, you or someone else at the site might be so kind as to
>    >    >>    rebuild atop
>    >    >>
>    >    >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
>    >    >>    in addition
>    >    >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
>    >    >>    set to -g before configure and make.  Please make sure -g is included
>    >    >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
>    >    >>    and before make to include -g wherever one sees -O3 or -O
>    >    >>
>    >    >>    Would this be too much trouble?
>    >    >>
>    >    >>    Take care,
>    >    >>
>    >    >>    Matt Kaufmann <kaufmann@...> writes:
>    >    >>
>    >    >>    > Hi --
>    >    >>    >
>    >    >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
>    >    >>    > suggested.  It's working great on 32-bit linux, but I've run into an
>    >    >>    > issue for 64-bit linux.
>    >    >>    >
>    >    >>    > You can re-create the issue on a UT CS 64-bit linux machine as
>    >    >>    > follows.
>    >    >>    >
>    >    >>    > Start up ACL2 built on GCL, as follows:
>    >    >>    >
>    >    >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
>    >    >>    >
>    >    >>    > Then issue these commands:
>    >    >>    >
>    >    >>    >   ; Just to slow down the output from the next form:
>    >    >>    >   (trace$ rewrite)
>    >    >>    >
>    >    >>    >   ; ACL2 disables the debugger by default; this restores it:
>    >    >>    >   (set-debugger-enable t)
>    >    >>    >
>    >    >>    >   ; This goes pretty fast but you'll have time to interrupt it:
>    >    >>    >   (thm (equal (append (append x x) x) (append x x x)))
>    >    >>    >
>    >    >>    >   [Now quickly interrupt with control-c, and then :q from the break.
>    >    >>    >    If the form above completes, just try it again.  Eventually I think
>    >    >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
>    >    >>    >
>    >    >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
>    >    >>    > follows, on lhug-0 (a 64-bit linux machine):
>    >    >>    >
>    >    >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
>    >    >>    >
>    >    >>    > where "my-fast-gcl" is a script containing:
>    >    >>    >
>    >    >>    > #!/bin/sh
>    >    >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
>    >    >>    >
>    >    >>    > Also by the way, if you instead run the following on a 32-bit UT CS
>    >    >>    > linux machine
>    >    >>    >
>    >    >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
>    >    >>    >
>    >    >>    > then you won't see the interrupt problem described above (or at least,
>    >    >>    > I didn't, and I tried).
>    >    >>    >
>    >    >>    > Thanks --
>    >    >>    > -- Matt
>    >    >>    >
>    >    >>    >
>    >    >>    >
>    >    >>    >
>    >    >>
>    >    >>    --
>    >    >>    Camm Maguire        camm@...
>    >    >>    ==========================================================================
>    >    >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>    >    >>
>    >    >>
>    >    >>
>    >    >>
>    >    >
>
>
>
>

--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Matt Kaufmann]

Hi --

Regarding:

>> Greetings, and thanks!  OK, this is fixed now in branch 2.6.8pre of
>> cvs, and will be in cvs head soon.  Please let me know if you need a
>> reminder about how to get 2.6.8pre.

I assume that the following is it (and is what our sysadmins will use
for their build):

export CVS_RSH=ssh # or, if using csh: setenv CVS_RSH ssh
cvs -d:pserver:anoncvs@...:/sources/gcl co -r Version_2_6_8pre -d gcl-2.6.8pre gcl

I'm also assuming that they don't have to wait on the gdb issue before
rebuilding (feel free to correct me!).

Thanks --
-- Matt
   Cc: dkotz@..., gripe@..., gcl-devel@...
   From: Camm Maguire <camm@...>
   Date: Thu, 26 Feb 2009 13:44:34 -0500
   X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   X-UTCS-Spam-Status: No, hits=-282 required=165

   Greetings!  There appears to be a gdb problem on lhug-0:

   Program received signal SIGINT, Interrupt.
   Cannot remove breakpoints because program is no longer writable.
   It might be running in another process.
   Further execution is probably impossible.
   0x00002aaaab9c8ab7 in ?? ()
   (gdb)

   Would anyone be so kind as to check this out for future debugging use?

   Take care,

   Matt Kaufmann <kaufmann@...> writes:

   > Hi --
   >
   > I was able to reproduce the error after building ACL2 a new debug copy
   > of 64-bit gcl that the sysadmins built.  Same instructions as before,
   > except for a slight change in the ACL2 executable directory.  Quoting
   > from below, but updating the executable path (and fixing a misleading
   > comment):
   >
   >   Start up ACL2 built on GCL, as follows:
   >
   >   /projects/acl2/v3-4-linux-64/fast-linux-gcl-saved_acl2
   >
   >   Then issue these commands:
   >
   >     ; Just to slow down the output from the thm form below:
   >     (trace$ rewrite)
   >
   >     ; ACL2 disables the debugger by default; this restores it:
   >     (set-debugger-enable t)
   >
   >     ; This goes pretty fast but you'll have time to interrupt it:
   >     (thm (equal (append (append x x) x) (append x x x)))
   >
   >     [Now quickly interrupt with control-c, and then :q from the break.
   >      If the form above completes, just try it again.  Eventually I think
   >      you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >
   > It seems to take me about 3 to 5 THM calls to get the error, which
   > looks like this:
   >
   >   ACL2 !>(thm (equal (append (append x x) x) (append x x x)))
   >   [SGC off]
   >   Error: Caught fatal error [memory may be damaged]
   >   Fast links are on: do (si::use-fast-links nil) for debugging
   >   Error signalled by ACL2_*1*_ACL2::THM-FN.
   >   Broken at COND.  Type :H for Help.
   >   ACL2[RAW LISP]>>
   >
   > -- Matt
   >    Date: Mon, 23 Feb 2009 17:12:04 -0600
   >    From: "David A. Kotz" <dkotz@...>
   >    CC: camm@..., gripe@..., gcl-devel@...
   >
   >    I've replaced both of our 64bit flavors and the 32bit with debug-enabled
   >    versions.  The 64s are in place now, and the 32 should rdist around
   >    tonight.  I want to keep all of them in sync, even if we're only
   >    investigating a problem in one.
   >
   >    - dave
   >
   >
   >    Matt Kaufmann wrote:
   >    > Thanks, Dave!  I really appreciate it.
   >    >
   >    > When I get the word from you, or when I see
   >    > /lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
   >    > top of it and try to reproduce the problem.
   >    >
   >    > Thanks again --
   >    > -- Matt
   >    >    Date: Mon, 23 Feb 2009 10:13:54 -0600
   >    >    From: "David A. Kotz" <dkotz@...>
   >    >    CC: Matt Kaufmann <kaufmann@...>, gripe@...,
   >    >   gcl-devel@...
   >    >
   >    >    I'll rebuild it with the debug flag.
   >    >
   >    >    - dave
   >    >
   >    >
   >    >    Camm Maguire wrote:
   >    >    > Thanks!  Please let me know if you run into troubles here.
   >    >    >
   >    >    > Take care,
   >    >    >
   >    >    > Matt Kaufmann <kaufmann@...> writes:
   >    >    >
   >    >    >> Howdy --
   >    >    >>
   >    >    >> Thanks for the reply.
   >    >    >>
   >    >    >> If gripe@cs is willing to do (1), or to send me the exact configure
   >    >    >> and make commands and source directory used so that I can do it
   >    >    >> myself, then I'll try to reproduce the error by building ACL2 on top
   >    >    >> of it.  I'm assuming that --enable-debug is given to the configure
   >    >    >> command, not to make.
   >    >    >>
   >    >    >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
   >    >    >> know and we can explore (2).  In that case, if gripe@cs is willing to
   >    >    >> do it, great; then I'll try to reproduce the problem.  But if I'm to
   >    >    >> do the build, I'd need explicit instructions on how to "make sure -g
   >    >    >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
   >    >    >> Also I didn't understand the comment about makedefs.  But I guess we
   >    >    >> can ignore (2) if (1) works.
   >    >    >>
   >    >    >> -- Matt
   >    >    >>    Cc: gcl-devel@..., gripe@...
   >    >    >>    From: Camm Maguire <camm@...>
   >    >    >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
   >    >    >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   >    >    >>    X-UTCS-Spam-Status: No, hits=-282 required=165
   >    >    >>
   >    >    >>    Greetings!  I suspect a missing signal block around some code that
   >    >    >>    needs protecting.  I've reprodced under gdb, but there are no
   >    >    >>    debugging symbols in the image.  [ Question for list -- have computers
   >    >    >>    now become so fast that -g should be included by default in all gcl
   >    >    >>    images? It used to slow down the compiler, don't know about now.  It
   >    >    >>    does make the image quite a bit bigger. ]
   >    >    >>
   >    >    >>    Ideally, you or someone else at the site might be so kind as to
   >    >    >>    rebuild atop
   >    >    >>
   >    >    >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
   >    >    >>    in addition
   >    >    >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
   >    >    >>    set to -g before configure and make.  Please make sure -g is included
   >    >    >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
   >    >    >>    and before make to include -g wherever one sees -O3 or -O
   >    >    >>
   >    >    >>    Would this be too much trouble?
   >    >    >>
   >    >    >>    Take care,
   >    >    >>
   >    >    >>    Matt Kaufmann <kaufmann@...> writes:
   >    >    >>
   >    >    >>    > Hi --
   >    >    >>    >
   >    >    >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
   >    >    >>    > suggested.  It's working great on 32-bit linux, but I've run into an
   >    >    >>    > issue for 64-bit linux.
   >    >    >>    >
   >    >    >>    > You can re-create the issue on a UT CS 64-bit linux machine as
   >    >    >>    > follows.
   >    >    >>    >
   >    >    >>    > Start up ACL2 built on GCL, as follows:
   >    >    >>    >
   >    >    >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
   >    >    >>    >
   >    >    >>    > Then issue these commands:
   >    >    >>    >
   >    >    >>    >   ; Just to slow down the output from the next form:
   >    >    >>    >   (trace$ rewrite)
   >    >    >>    >
   >    >    >>    >   ; ACL2 disables the debugger by default; this restores it:
   >    >    >>    >   (set-debugger-enable t)
   >    >    >>    >
   >    >    >>    >   ; This goes pretty fast but you'll have time to interrupt it:
   >    >    >>    >   (thm (equal (append (append x x) x) (append x x x)))
   >    >    >>    >
   >    >    >>    >   [Now quickly interrupt with control-c, and then :q from the break.
   >    >    >>    >    If the form above completes, just try it again.  Eventually I think
   >    >    >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >    >    >>    >
   >    >    >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
   >    >    >>    > follows, on lhug-0 (a 64-bit linux machine):
   >    >    >>    >
   >    >    >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
   >    >    >>    >
   >    >    >>    > where "my-fast-gcl" is a script containing:
   >    >    >>    >
   >    >    >>    > #!/bin/sh
   >    >    >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
   >    >    >>    >
   >    >    >>    > Also by the way, if you instead run the following on a 32-bit UT CS
   >    >    >>    > linux machine
   >    >    >>    >
   >    >    >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
   >    >    >>    >
   >    >    >>    > then you won't see the interrupt problem described above (or at least,
   >    >    >>    > I didn't, and I tried).
   >    >    >>    >
   >    >    >>    > Thanks --
   >    >    >>    > -- Matt
   >    >    >>    >
   >    >    >>    >
   >    >    >>    >
   >    >    >>    >
   >    >    >>
   >    >    >>    --
   >    >    >>    Camm Maguire        camm@...
   >    >    >>    ==========================================================================
   >    >    >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
   >    >    >>
   >    >    >>
   >    >    >>
   >    >    >>
   >    >    >
   >
   >
   >
   >

   --
   Camm Maguire        camm@...
   ==========================================================================
   "The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Matt Kaufmann]

Hi --

Perhaps Camm Maguire is done with the debug versions of GCL at UT CS,
in which case you might be willing to build non-debug versions, which
run faster.  In particular, here is a comparison of times for an ACL2
regression run using the debug version vs. one using a version built
with the same configure command except without --enable-debug (in my
own space, /projects/acl2/lisps/gcl/gcl-2.6.8pre/bin/gcl):

15308.228u 587.400s 49:53.88 530.9% 0+0k 233800+1855104io 207pf+0w
11424.237u 616.798s 35:43.40 561.7% 0+0k 159568+1728048io 200pf+0w

This probably isn't important for the novice ACL2 users in J Moore's
class this semester, but perhaps someone else at UT CS would benefit
from better GCL performance.

Thanks --
-- Matt
   Date: Wed, 25 Feb 2009 14:10:58 -0600
   From: "David A. Kotz" <dkotz@...>
   CC: camm@..., gripe@..., gcl-devel@...

   ./configure --prefix=/lusr/opt/gcl-2.6.8pre \
            --disable-statsysbfd --enable-locbfd \
            --enable-ihssize=2097110             \
            --enable-vssize=2097110              \
            --enable-maxpage=524288              \
            --enable-holediv=100                    \
            --enable-debug




   Matt Kaufmann wrote:
   > Great!  Thank you.  Dave, if you send me your build instructions, I'll
   > forward them along since you're (I'm guessing) not on the gcl-devel
   > list, which only allows posts from members.
   >
   > Thanks --
   > -- Matt
   >    Cc: dkotz@..., gripe@..., gcl-devel@...
   >    From: Camm Maguire <camm@...>
   >    Date: Wed, 25 Feb 2009 15:03:41 -0500
   >    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   >    X-UTCS-Spam-Status: No, hits=-282 required=165
   >
   >    Greetings!  OK, suprisingly enough I think I might have indirectly
   >    deduced what is going on.  It is verifiably independent of SGC, but
   >    appears related to 64bit only by the enhanced time window possible in
   >    which to receive SIGINT.
   >
   >    In short, could you please send me (and post to gcl-devel) the
   >    instructions for rebuilding your source again against a patched gcl
   >    tree for testing.
   >
   >    This does bring up the legacy gcl signal handling code, which is quite
   >    clever given the age in which it was developed, but has since been
   >    made somewhat obsolete by recent system developments, at least on
   >    Linux.
   >
   >    The GCL strategy is to maintain global variables tracking pending and
   >    blcked signals, and to loop over alarm(1) until the unblocking code
   >    snippet is executed.  (i.e. BEGIN_NO_INTERRUPT and END_NO_INTERRUPT,
   >    which essentially set signals_allowed to 0 and restores the previous
   >    value respectively).  Nowadays, bracketing the code needing protection
   >    directly with sigprocmask is more typical.  Heaven knows what
   >    portability issues are involved in making this change.
   >
   >    The bug appears to be that critical GC code is not protected against
   >    interrupts and subsequent possible longjumps.  Specifically,
   >    add_page_to_freelist is apparently allowing partially initialized
   >    freelists to escape.  An immediate fix would be at hand in this case,
   >    but more systematically we need to review the areas this protection is
   >    required and come up with a decent centralization policy.  I don't
   >    think there is any reason to clock signals other that object creation,
   >    gc, and anything modifying tm_table.  Other thoughts most welcome.
   >
   >    Take care,
   >
   >
   >
   >    Matt Kaufmann <kaufmann@...> writes:
   >
   >    > Hi --
   >    >
   >    > I was able to reproduce the error after building ACL2 a new debug copy
   >    > of 64-bit gcl that the sysadmins built.  Same instructions as before,
   >    > except for a slight change in the ACL2 executable directory.  Quoting
   >    > from below, but updating the executable path (and fixing a misleading
   >    > comment):
   >    >
   >    >   Start up ACL2 built on GCL, as follows:
   >    >
   >    >   /projects/acl2/v3-4-linux-64/fast-linux-gcl-saved_acl2
   >    >
   >    >   Then issue these commands:
   >    >
   >    >     ; Just to slow down the output from the thm form below:
   >    >     (trace$ rewrite)
   >    >
   >    >     ; ACL2 disables the debugger by default; this restores it:
   >    >     (set-debugger-enable t)
   >    >
   >    >     ; This goes pretty fast but you'll have time to interrupt it:
   >    >     (thm (equal (append (append x x) x) (append x x x)))
   >    >
   >    >     [Now quickly interrupt with control-c, and then :q from the break.
   >    >      If the form above completes, just try it again.  Eventually I think
   >    >      you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >    >
   >    > It seems to take me about 3 to 5 THM calls to get the error, which
   >    > looks like this:
   >    >
   >    >   ACL2 !>(thm (equal (append (append x x) x) (append x x x)))
   >    >   [SGC off]
   >    >   Error: Caught fatal error [memory may be damaged]
   >    >   Fast links are on: do (si::use-fast-links nil) for debugging
   >    >   Error signalled by ACL2_*1*_ACL2::THM-FN.
   >    >   Broken at COND.  Type :H for Help.
   >    >   ACL2[RAW LISP]>>
   >    >
   >    > -- Matt
   >    >    Date: Mon, 23 Feb 2009 17:12:04 -0600
   >    >    From: "David A. Kotz" <dkotz@...>
   >    >    CC: camm@..., gripe@..., gcl-devel@...
   >    >
   >    >    I've replaced both of our 64bit flavors and the 32bit with debug-enabled
   >    >    versions.  The 64s are in place now, and the 32 should rdist around
   >    >    tonight.  I want to keep all of them in sync, even if we're only
   >    >    investigating a problem in one.
   >    >
   >    >    - dave
   >    >
   >    >
   >    >    Matt Kaufmann wrote:
   >    >    > Thanks, Dave!  I really appreciate it.
   >    >    >
   >    >    > When I get the word from you, or when I see
   >    >    > /lusr/opt/gcl-2.6.8pre/bin/gcl updated on lhug-0, I'll rebuild ACL2 on
   >    >    > top of it and try to reproduce the problem.
   >    >    >
   >    >    > Thanks again --
   >    >    > -- Matt
   >    >    >    Date: Mon, 23 Feb 2009 10:13:54 -0600
   >    >    >    From: "David A. Kotz" <dkotz@...>
   >    >    >    CC: Matt Kaufmann <kaufmann@...>, gripe@...,
   >    >    >   gcl-devel@...
   >    >    >
   >    >    >    I'll rebuild it with the debug flag.
   >    >    >
   >    >    >    - dave
   >    >    >
   >    >    >
   >    >    >    Camm Maguire wrote:
   >    >    >    > Thanks!  Please let me know if you run into troubles here.
   >    >    >    >
   >    >    >    > Take care,
   >    >    >    >
   >    >    >    > Matt Kaufmann <kaufmann@...> writes:
   >    >    >    >
   >    >    >    >> Howdy --
   >    >    >    >>
   >    >    >    >> Thanks for the reply.
   >    >    >    >>
   >    >    >    >> If gripe@cs is willing to do (1), or to send me the exact configure
   >    >    >    >> and make commands and source directory used so that I can do it
   >    >    >    >> myself, then I'll try to reproduce the error by building ACL2 on top
   >    >    >    >> of it.  I'm assuming that --enable-debug is given to the configure
   >    >    >    >> command, not to make.
   >    >    >    >>
   >    >    >    >> Then if if I can't reproduce the problem, I'll let you and gripe@cs
   >    >    >    >> know and we can explore (2).  In that case, if gripe@cs is willing to
   >    >    >    >> do it, great; then I'll try to reproduce the problem.  But if I'm to
   >    >    >    >> do the build, I'd need explicit instructions on how to "make sure -g
   >    >    >    >> is included in the gcc calls"; maybe I need to do some setq in Lisp?
   >    >    >    >> Also I didn't understand the comment about makedefs.  But I guess we
   >    >    >    >> can ignore (2) if (1) works.
   >    >    >    >>
   >    >    >    >> -- Matt
   >    >    >    >>    Cc: gcl-devel@..., gripe@...
   >    >    >    >>    From: Camm Maguire <camm@...>
   >    >    >    >>    Date: Fri, 20 Feb 2009 20:58:49 -0500
   >    >    >    >>    X-SpamAssassin-Status: No, hits=-2.6 required=5.0
   >    >    >    >>    X-UTCS-Spam-Status: No, hits=-282 required=165
   >    >    >    >>
   >    >    >    >>    Greetings!  I suspect a missing signal block around some code that
   >    >    >    >>    needs protecting.  I've reprodced under gdb, but there are no
   >    >    >    >>    debugging symbols in the image.  [ Question for list -- have computers
   >    >    >    >>    now become so fast that -g should be included by default in all gcl
   >    >    >    >>    images? It used to slow down the compiler, don't know about now.  It
   >    >    >    >>    does make the image quite a bit bigger. ]
   >    >    >    >>
   >    >    >    >>    Ideally, you or someone else at the site might be so kind as to
   >    >    >    >>    rebuild atop
   >    >    >    >>
   >    >    >    >>    1) a gcl build with --enable-debug.  If this does not reproduce, then
   >    >    >    >>    in addition
   >    >    >    >>    2) rebuild atop a standard gcl with the CFLAGS environment variable
   >    >    >    >>    set to -g before configure and make.  Please make sure -g is included
   >    >    >    >>    in the gcc calls.  Otherwise, makedefs can be modified after configure
   >    >    >    >>    and before make to include -g wherever one sees -O3 or -O
   >    >    >    >>
   >    >    >    >>    Would this be too much trouble?
   >    >    >    >>
   >    >    >    >>    Take care,
   >    >    >    >>
   >    >    >    >>    Matt Kaufmann <kaufmann@...> writes:
   >    >    >    >>
   >    >    >    >>    > Hi --
   >    >    >    >>    >
   >    >    >    >>    > The sysadmins here at UT CS have built GCL 2.6.8pre from CVS as you
   >    >    >    >>    > suggested.  It's working great on 32-bit linux, but I've run into an
   >    >    >    >>    > issue for 64-bit linux.
   >    >    >    >>    >
   >    >    >    >>    > You can re-create the issue on a UT CS 64-bit linux machine as
   >    >    >    >>    > follows.
   >    >    >    >>    >
   >    >    >    >>    > Start up ACL2 built on GCL, as follows:
   >    >    >    >>    >
   >    >    >    >>    > /projects/acl2/v3-4-linux/fast-linux-gcl-saved_acl2
   >    >    >    >>    >
   >    >    >    >>    > Then issue these commands:
   >    >    >    >>    >
   >    >    >    >>    >   ; Just to slow down the output from the next form:
   >    >    >    >>    >   (trace$ rewrite)
   >    >    >    >>    >
   >    >    >    >>    >   ; ACL2 disables the debugger by default; this restores it:
   >    >    >    >>    >   (set-debugger-enable t)
   >    >    >    >>    >
   >    >    >    >>    >   ; This goes pretty fast but you'll have time to interrupt it:
   >    >    >    >>    >   (thm (equal (append (append x x) x) (append x x x)))
   >    >    >    >>    >
   >    >    >    >>    >   [Now quickly interrupt with control-c, and then :q from the break.
   >    >    >    >>    >    If the form above completes, just try it again.  Eventually I think
   >    >    >    >>    >    you'll see a Lisp "fatal error" or even a "Segmentation fault".]
   >    >    >    >>    >
   >    >    >    >>    > By the way, I built /projects/acl2/v3-4-linux/fast-linux-gcl as
   >    >    >    >>    > follows, on lhug-0 (a 64-bit linux machine):
   >    >    >    >>    >
   >    >    >    >>    > rm -f TAGS ; mv make-fast-gcl.log make-fast-gcl.old.log ; (time nice make PREFIX=fast-linux-gcl- LISP=my-fast-gcl) >& make-fast-gcl.log&
   >    >    >    >>    >
   >    >    >    >>    > where "my-fast-gcl" is a script containing:
   >    >    >    >>    >
   >    >    >    >>    > #!/bin/sh
   >    >    >    >>    > /lusr/opt/gcl-2.6.8pre/bin/gcl -eval "(defparameter user::*fast-acl2-gcl-build* t)" $*
   >    >    >    >>    >
   >    >    >    >>    > Also by the way, if you instead run the following on a 32-bit UT CS
   >    >    >    >>    > linux machine
   >    >    >    >>    >
   >    >    >    >>    > /projects/acl2/v3-4-linux/gcl-saved_acl2
   >    >    >    >>    >
   >    >    >    >>    > then you won't see the interrupt problem described above (or at least,
   >    >    >    >>    > I didn't, and I tried).
   >    >    >    >>    >
   >    >    >    >>    > Thanks --
   >    >    >    >>    > -- Matt
   >    >    >    >>    >
   >    >    >    >>    >
   >    >    >    >>    >
   >    >    >    >>    >
   >    >    >    >>
   >    >    >    >>    --
   >    >    >    >>    Camm Maguire        camm@...
   >    >    >    >>    ==========================================================================
   >    >    >    >>    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
   >    >    >    >>
   >    >    >    >>
   >    >    >    >>
   >    >    >    >>
   >    >    >    >
   >    >
   >    >
   >    >
   >    >
   >
   >    --
   >    Camm Maguire        camm@...
   >    ==========================================================================
   >    "The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings, and thanks!  OK I think this is fixed now in both
branches.  Here is the 2.6.8pre patch to read.d:

@@ -638,7 +646,7 @@
 static void
 Lleft_parenthesis_reader()
 {
- object in, c, x;
+ object in, x;
  object *p;
 
  check_arg(2);
@@ -654,18 +662,17 @@
  if (dot_flag) {
  if (p == &vs_head)
  FEerror("A dot appeared after a left parenthesis.", 0);
+ delimiting_char = code_char(')');
  in_list_flag = TRUE;
  *p = read_object(in);
  if (dot_flag)
  FEerror("Two dots appeared consecutively.", 0);
- c = read_char(in);
- while (cat(c) == cat_whitespace)
- c = read_char(in);
- if (char_code(c) != ')')
- FEerror("A dot appeared before a right parenthesis.", 0);
- else if (PP0>P0) PP0--; /* should be the only other place
-   outside of read_object where
-           closing parens are read */
+ if (*p==OBJNULL)
+ FEerror("Object missing after dot.", 0);
+ delimiting_char = code_char(')');
+ in_list_flag = TRUE;
+ if (read_object(in)!=OBJNULL)
+        FEerror("Two objects after dot.",0);
  goto ENDUP;
  }
  vs_push(x);

Take care,
--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel

[Camm Maguire-2]

Greetings!  Forgot to change the subject on the last mail.  That
should have referred to Matt's reader error report.

Please let me know if problems persist.

Take care,
--
Camm Maguire        camm@...
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
Gcl-devel@...
http://lists.gnu.org/mailman/listinfo/gcl-devel