clisp-devel — closed list for developers and testers

New Swedish PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'clisp' has been submitted
by the Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/clisp/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/clisp.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: new command-line option -nextgc-factor

[Bruno H. <br...@cl...>]

Don Cohen wrote:
> I just did hg pull and I don't see this new option.
> Am I using the right repository?  Is there a delay?
> 
>  [don@localhost clisp]$ hg pull

Always use "hg pull --update".

Bruno

[1] https://stackoverflow.com/questions/19270303/why-do-i-need-hg-update-after-hg-pull-while-in-git-im-doing-only-git-pull

new command-line option -nextgc-factor

[<don...@is...>]

I just did hg pull and I don't see this new option.
Am I using the right repository?  Is there a delay?

 [don@localhost clisp]$ hg pull
 pulling from http://hg.code.sf.net/p/clisp/clisp
 searching for changes
 no changes found
 [don@localhost clisp]$ find . -type f -exec fgrep -il nextgc-factor {} \;
 [don@localhost clisp]$  

new command-line option -nextgc-factor

[<don...@is...>]

Bruno Haible writes:

 > For debugging GC problems, I have added a new option -nextgc-factor.
 > It is a factor that gets applied to the amount of space that can be
 > consumed before the next GC is triggered.
...
 > I don't want to document this option, because the default GC frequency
 > is completely sufficient for the average user.

You do have a section on debugging (also gc) in impnotes.
Why not include what you wrote in this message there?
And in the doc for command line arguments refer to
the appropriate section of impnotes.

clisp-cvs Digest, Vol 77, Issue 4

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: Update Swedish translation.
      (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Mon, 29 May 2017 08:39:59 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Update Swedish translation.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/77324311b0b8
changeset: 15918:77324311b0b88cb155b380fec17d95b02ab68da5
user:      Bruno Haible <br...@cl...>
date:      2017-05-29 10:39:43 +0200
description:
Update Swedish translation.

diffstat:

 src/ChangeLog          |    6 +
 src/po/clisplow_sv.gmo |  Bin 
 src/po/clisplow_sv.po  |   72 +-
 src/po/sv.gmo          |  Bin 
 src/po/sv.po           |  979 +++++++++++++++++++++++++-----------------------
 5 files changed, 544 insertions(+), 513 deletions(-)



------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

Subject: Digest Footer

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


------------------------------

End of clisp-cvs Digest, Vol 77, Issue 4
****************************************

Re: crashing socket tests

[Bruno H. <br...@cl...>]

Hi Vladimir,

> > Stream record looks ok but encoding object is not getting marked during GC.
> >
> 
> 
> The problem is GC mark phase.
> 
> Streams with strmtype equal to Rectype_Weakpointer or Rectype_Weakpointer
> are not getting marked since SXrecord_nonweak_length() returns 0 for them!
> ...
> strmtype = 0x11, strmflags = 0x41, reclength = 0x15, recxlength = 0x60,
> ...
> (gdb) p /x Rectype_Weakpointer
> $34 = 0x11

Thank you!!!! I'm so glad that we'll be able to put this terrible bug to rest.

Similarly in the situation that I'm debugging:
(gdb) print (int)enum_strmtype_twoway_socket
$1 = 20
(gdb) print (int)Rectype_Weakpointer
$2 = 20

This explains why you were seeing the problem on a stream of type
enum_strmtype_socket, while I was seeing it on a stream of type
enum_strmtype_twoway_socket.

Bruno

Re: crashing socket tests

[Vladimir T. <vtz...@gm...>]

Hi Bruno,

On Sun, May 28, 2017 at 5:20 PM, Vladimir Tzankov <vtz...@gm...>
wrote:

> > The stream object has been moved due to compaction but strm_encoding has
>> > either not moved (unlikely - its heap has shrunk) or has not been
>> updated.
>>
>> I'd also guess that it has not been updated. Is the reclength of the
>> stream appropriate? Has the reclength been changed since the
>> allocate_stream
>> call?
>>
>
> Stream record looks ok but encoding object is not getting marked during GC.
>


The problem is GC mark phase.

Streams with strmtype equal to Rectype_Weakpointer or Rectype_Weakpointer
are not getting marked since SXrecord_nonweak_length() returns 0 for them!

Here is gdb output for this case:

(gdb) p /x *(Stream)0xb0000005ac0
$32 = {header = {_GCself = 0xb0000005ac0, flags = {0xb0000005ac0}},
strmtype = 0x11, strmflags = 0x41, reclength = 0x15, recxlength = 0x60,
strm_rd_by = 0x464b98,
  strm_rd_by_array = 0x464b80, strm_wr_by = 0x464b68, strm_wr_by_array =
0x464b50, strm_rd_ch = 0x462df0, strm_pk_ch = 0x45af68, strm_rd_ch_array =
0x462918,
  strm_rd_ch_last = 0x2000000000a, strm_wr_ch = 0x464b08, strm_wr_ch_array
= 0x464af0, strm_wr_ch_npnl = 0x464b08, strm_wr_ch_array_npnl = 0x464af0,
  strm_wr_ch_lpos = 0x200000000000, strm_other = 0xb0000005b38}
(gdb) p /x *(Record)0xb0000005ac0
$33 = {header = {_GCself = 0xb0000005ac0, flags = {0xb0000005ac0}}, rectype
= 0x11, recflags = 0x41, reclength = 0x6015, recdata = 0xb0000005ad0}
(gdb) p /x Rectype_Weakpointer
$34 = 0x11

And SXrecord_nonweak_length() explicitly uses Record_type() to check for
weak pointers.

This also explains why I experience this only in non-libffcall builds. With
DYNAMIC_FFI, Rectype_Weakpointer is 0x14 because of the three additional
FFI record types.

New Swedish PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'clisp' has been submitted
by the Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/clisp/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/clisp.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: crashing socket tests

[Bruno H. <br...@cl...>]

> Meanwhile, I'm seeing a different crash (in a build-porting64-gcc-debug_gcsafety
> build with -DOLD_GC), but also related to socket streams:
> 
> 
> (MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER))) (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL "(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL :INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO (SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO) (SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE "bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR) (PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE))))
> STACK size: 98238 [0x300000bfe00 0x30000000010]
> 
> [../src/stream.d:6199] [OS-STREAM-ERROR]: OS-STREAM-ERROR(104): Connection reset by peer
> Makefile:25: die Regel für Ziel „tests“ scheiterte

The reason here seems to be a stream of type enum_strmtype_twoway_socket, of
the correct reclength, where the last element, ->strm_twoway_socket_output,
has not been updated by GC. Whereas the second-to-last element,
->strm_twoway_socket_input has been updated.

Bruno

Re: crashing socket tests

[Vladimir T. <vtz...@gm...>]

>
> > The stream object has been moved due to compaction but strm_encoding has
> > either not moved (unlikely - its heap has shrunk) or has not been
> updated.
>
> I'd also guess that it has not been updated. Is the reclength of the
> stream appropriate? Has the reclength been changed since the
> allocate_stream
> call?
>

Stream record looks ok but encoding object is not getting marked during GC.

new command-line option -nextgc-factor

[Bruno H. <br...@cl...>]

Hi all,

For debugging GC problems, I have added a new option -nextgc-factor.
It is a factor that gets applied to the amount of space that can be
consumed before the next GC is triggered.

Setting it to large values can inhibit GC for a long time:

$ ./lisp.run -q -M lispinit.mem -nextgc-factor 1e9
[1]> (time (setq a (make-array 1000000) b nil))
Real time: 0.038371 sec.
Run time: 0.04 sec.
Space: 8000016 Bytes
NIL
[2]> (room)

Number of garbage collections:                0
Bytes freed by GC:                            0
Time spent in GC:                           0.0 sec
Bytes permanently allocated:            158,480
Bytes currently in use:              11,107,792
Bytes available until next GC: 1,536,935,991,966,080
11107792 ;
1536935991966080 ;
158480 ;
0 ;
0 ;
0

Setting it to small values can make GCs much more frequent:

$ ./lisp.run -q -M lispinit.mem -nextgc-factor 0.001
[1]> (room)

Number of garbage collections:               16
Bytes freed by GC:                       44,648
Time spent in GC:                         1.112 sec
Bytes permanently allocated:            158,480
Bytes currently in use:               3,056,200
Bytes available until next GC:               71
3056200 ;
71 ;
158480 ;
16 ;
44648 ;
1112000
[2]> (time (setq a (make-list 1000) b nil))
Real time: 0.687479 sec.
Run time: 0.688 sec.
Space: 16000 Bytes
GC: 10, GC time: 0.688 sec.
NIL


I don't want to document this option, because the default GC frequency
is completely sufficient for the average user.

Bruno

clisp-cvs Digest, Vol 77, Issue 3

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: Prepare for new frame info byte values.
      (cli...@li...)
   2. clisp: Prepare for new frame info byte values.
      (cli...@li...)
   3. clisp: New frame type CHANDLER.
      (cli...@li...)
   4. clisp: Put only valid pointers into the FRAME_(frame_SP) of a
      CH... (cli...@li...)
   5. clisp: Don't put arbitrary C function pointers onto the
      STACK. (cli...@li...)
   6. clisp: Add check of make_machine_code argument.
      (cli...@li...)
   7. clisp: Update to the newest gnulib, and import module
      'c-strtod'. (cli...@li...)
   8. clisp: New command line option -nextgc-factor (undocumented).
      (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Sat, 27 May 2017 19:22:05 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Prepare for new frame info byte values.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/3a7c3ccd37bb
changeset: 15910:3a7c3ccd37bbc3e472a0d3f879549af89c291796
user:      Bruno Haible <br...@cl...>
date:      2017-05-27 12:12:53 +0200
description:
Prepare for new frame info byte values.

diffstat:

 src/ChangeLog         |  12 ++++++++++++
 src/debug.d           |   8 ++++----
 src/eval.d            |   2 +-
 src/lispbibl.d        |  50 ++++++++++++++++++++++++++++----------------------
 src/spvw_garcol.d     |   2 +-
 src/spvw_garcol_old.d |   2 +-
 src/spvw_update.d     |   2 +-
 7 files changed, 48 insertions(+), 30 deletions(-)



------------------------------

Message: 2
Date: Sat, 27 May 2017 19:22:07 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Prepare for new frame info byte values.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/56eaa4ab84a0
changeset: 15911:56eaa4ab84a075bff305ff81c81c154ab5b708fc
user:      Bruno Haible <br...@cl...>
date:      2017-05-27 17:09:44 +0200
description:
Prepare for new frame info byte values.

diffstat:

 src/ChangeLog  |  13 +++++++++++
 src/debug.d    |  18 ++++++++++++++-
 src/eval.d     |   6 ++--
 src/lispbibl.d |  66 +++++++++++++++++++++++++++------------------------------
 4 files changed, 63 insertions(+), 40 deletions(-)



------------------------------

Message: 3
Date: Sat, 27 May 2017 19:22:08 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: New frame type CHANDLER.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/6a5acbe357f8
changeset: 15912:6a5acbe357f8a5d97dec313934d4f072935cb9a1
user:      Bruno Haible <br...@cl...>
date:      2017-05-27 18:42:36 +0200
description:
New frame type CHANDLER.

diffstat:

 src/ChangeLog         |   28 +++++++++++
 src/eval.d            |   11 ++--
 src/io.d              |    9 ++-
 src/lispbibl.d        |  122 ++++++++++++++++++++++++++-----------------------
 src/pathname.d        |   14 ++--
 src/spvw_garcol.d     |    9 ++-
 src/spvw_garcol_old.d |    9 ++-
 src/spvw_update.d     |    9 ++-
 src/stream.d          |   30 ++++++------
 9 files changed, 143 insertions(+), 98 deletions(-)



------------------------------

Message: 4
Date: Sat, 27 May 2017 19:22:10 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Put only valid pointers into the FRAME_(frame_SP) of a
	CH...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/084199c06424
changeset: 15913:084199c06424d252f7e13acdfbb076658b5073a7
user:      Bruno Haible <br...@cl...>
date:      2017-05-27 20:43:41 +0200
description:
Put only valid pointers into the FRAME_(frame_SP) of a CHANDLER frame.

diffstat:

 src/ChangeLog  |   9 +++++++++
 src/io.d       |  13 +++++++++----
 src/lispbibl.d |   2 +-
 src/pathname.d |  12 +++++++-----
 4 files changed, 26 insertions(+), 10 deletions(-)



------------------------------

Message: 5
Date: Sat, 27 May 2017 19:22:11 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Don't put arbitrary C function pointers onto the
	STACK.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/57e0d174fd9a
changeset: 15914:57e0d174fd9acb976e87c3138f472d4d8cd995a5
user:      Bruno Haible <br...@cl...>
date:      2017-05-27 21:16:46 +0200
description:
Don't put arbitrary C function pointers onto the STACK.

diffstat:

 src/ChangeLog |   9 +++++++++
 src/list.d    |  42 ++++++++++++++++++++----------------------
 2 files changed, 29 insertions(+), 22 deletions(-)



------------------------------

Message: 6
Date: Sat, 27 May 2017 19:22:13 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Add check of make_machine_code argument.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/0811d6f2b63a
changeset: 15915:0811d6f2b63a343f3495571ca57c6a77738cbff3
user:      Bruno Haible <br...@cl...>
date:      2017-05-27 21:20:12 +0200
description:
Add check of make_machine_code argument.

diffstat:

 src/ChangeLog  |  11 +++++++++++
 src/lispbibl.d |  22 +++++++++++++++++-----
 src/spvw.d     |   8 ++++----
 3 files changed, 32 insertions(+), 9 deletions(-)



------------------------------

Message: 7
Date: Sun, 28 May 2017 12:11:48 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Update to the newest gnulib, and import module
	'c-strtod'.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/13b820550816
changeset: 15916:13b820550816aca6305b025ff9c90bdf0aea96d5
user:      Bruno Haible <br...@cl...>
date:      2017-05-28 13:43:24 +0200
description:
Update to the newest gnulib, and import module 'c-strtod'.

diffstat:

 Makefile.devel               |     2 +-
 modules/oracle/configure     |   115 ++-
 src/ChangeLog                |    13 +
 src/aclocal.m4               |   762 +++++++++++++----
 src/build-aux/config.guess   |     8 +-
 src/build-aux/config.sub     |     6 +-
 src/config.h.in              |    85 +-
 src/configure                |  1831 ++++++++++++++++++++++++-----------------
 src/gllib/Makefile.am        |    79 +-
 src/gllib/Makefile.in        |   137 ++-
 src/gllib/c-strtod.c         |   112 ++
 src/gllib/c-strtod.h         |    45 +
 src/gllib/close.c            |     4 +-
 src/gllib/dup2.c             |    44 +-
 src/gllib/fd-hook.c          |     2 +-
 src/gllib/fd-hook.h          |     2 +-
 src/gllib/filename.h         |    54 +
 src/gllib/fnmatch.c          |     8 +
 src/gllib/fnmatch_loop.c     |     8 +-
 src/gllib/gettext.h          |     5 +-
 src/gllib/gettimeofday.c     |   154 +-
 src/gllib/intprops.h         |    71 +-
 src/gllib/ioctl.c            |     6 +-
 src/gllib/localcharset.c     |     8 +-
 src/gllib/localtime-buffer.c |    58 +
 src/gllib/localtime-buffer.h |    27 +
 src/gllib/malloc.c           |    56 +
 src/gllib/mbrtowc.c          |    11 +-
 src/gllib/mbsinit.c          |    34 +-
 src/gllib/mktime.c           |    66 +-
 src/gllib/msvc-nothrow.c     |     4 +-
 src/gllib/regex_internal.h   |     1 +
 src/gllib/select.c           |     6 +-
 src/gllib/sockets.c          |     6 +-
 src/gllib/sockets.h          |    12 +-
 src/gllib/stat-w32.c         |   415 +++++++++
 src/gllib/stat-w32.h         |    37 +
 src/gllib/stat.c             |   419 ++++++++-
 src/gllib/strdup.c           |    54 +
 src/gllib/strerror_r.c       |   114 ++-
 src/gllib/strftime.c         |    13 +-
 src/gllib/sys_stat.in.h      |   182 +++-
 src/gllib/sys_types.in.h     |    42 +
 src/gllib/time.in.h          |    57 +-
 src/gllib/time_rz.c          |    15 +-
 src/gllib/tzset.c            |    83 +
 src/gllib/unistd.in.h        |    48 +-
 src/gllib/vma-iter.c         |    38 +-
 src/gllib/vma-iter.h         |     2 +-
 src/gllib/w32sock.h          |     6 +-
 src/gllib/wchar.in.h         |    44 +-
 src/gllib/wctype.in.h        |    22 +-
 src/glm4/c-strtod.m4         |    49 +
 src/glm4/close.m4            |    12 +-
 src/glm4/gettimeofday.m4     |    36 +-
 src/glm4/gnulib-cache.m4     |     3 +-
 src/glm4/gnulib-comp.m4      |    52 +-
 src/glm4/iconv.m4            |    34 +-
 src/glm4/include_next.m4     |     5 +-
 src/glm4/intldir.m4          |     6 +-
 src/glm4/largefile.m4        |    21 +-
 src/glm4/localtime-buffer.m4 |    21 +
 src/glm4/malloc.m4           |   101 ++
 src/glm4/mktime.m4           |    65 +-
 src/glm4/progtest.m4         |     4 +-
 src/glm4/stat.m4             |   104 +-
 src/glm4/strdup.m4           |    36 +
 src/glm4/strerror_r.m4       |    26 +-
 src/glm4/strftime.m4         |     8 +-
 src/glm4/sys_stat_h.m4       |    18 +-
 src/glm4/sys_time_h.m4       |     3 +-
 src/glm4/sys_types_h.m4      |    10 +-
 src/glm4/time_h.m4           |    12 +-
 src/glm4/time_rz.m4          |     3 +-
 src/glm4/timegm.m4           |     6 +-
 src/glm4/tzset.m4            |    81 +
 src/glm4/unistd_h.m4         |     9 +-
 src/glm4/wchar_h.m4          |     9 +-
 src/glm4/wctype_h.m4         |     4 +-
 src/glm4/wint_t.m4           |    14 +-
 80 files changed, 4643 insertions(+), 1542 deletions(-)



------------------------------

Message: 8
Date: Sun, 28 May 2017 12:11:49 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: New command line option -nextgc-factor (undocumented).
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/38e4743b1df5
changeset: 15917:38e4743b1df50eac7b4c74ed9e8f8783dcf3dafa
user:      Bruno Haible <br...@cl...>
date:      2017-05-28 14:11:25 +0200
description:
New command line option -nextgc-factor (undocumented).

diffstat:

 src/ChangeLog         |  13 +++++++++++++
 src/spvw.d            |  19 ++++++++++++++++++-
 src/spvw_garcol.d     |  20 ++++++++++++++------
 src/spvw_garcol_old.d |  20 ++++++++++++++------
 src/spvw_global.d     |   3 +++
 src/spvw_global_old.d |   3 +++
 6 files changed, 65 insertions(+), 13 deletions(-)



------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

Subject: Digest Footer

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


------------------------------

End of clisp-cvs Digest, Vol 77, Issue 3
****************************************

New Swedish PO file for 'clisp' (version 2.48-pre1)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'clisp' has been submitted
by the Swedish team of translators.  The file is available at:

    http://translationproject.org/latest/clisp/sv.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/clisp/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/clisp.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

Re: newcomers

[Bruno H. <br...@cl...>]

Hi Vladimir,

> Related issue is the barrier to entry for newcomers. Having so many build
> options and the dense codebase cause frustration to people interested to
> get involved. I don't know what is the solution for this but it's
> definitely a problem.

"Dense codebase" is equivalent to "software that does complex things".
If people want something less dense, they can look at interpreter-only
implementations, SIOD, or similar.

One approach that I've tried is modularization (libiconv, libsigsegv,
libffcall are outside clisp now; clisp has its own module system). Maybe
this modularization should be pushed further? Possibly every module should
be accompanied with unit tests?

Another thing is that many people don't like #if; they prefer abstractions.
In some places we have abstractions with possibly more than 1 implementation
(e.g. HASHSET in spvw_circ.d); maybe this should be coupled with a consistent
coding style (.h and .c files for specification and implementation,
respectively)?

Do people feel the same ("dense codebase", "frustration") only about the
C part of clisp, or also about the *.lisp files?

> Normal users are also affected - people try something and submit bug
> reports without reading http://www.clisp.org/impnotes/clisp.html#bugs and
> following conversation is about 'clisp --version', build options, etc.
> Probably having binary releases is the 'good enough' solution for this.

I don't think one can do anything about this, other than to remind the
users what information to provide.
Different OSes have different support for mmap, __thread, system calls, etc.
- therefore invariably the builds on different OSes will end up using
different code paths.

Or should we hook into 'apport', so that the details get collected
automatically?

It today's world, it's most often not the developers of a package who
make the binary releases, but the distributors [1]. We can talk with them
but we will never get them to distribute the same binaries.

Bruno

[1] https://repology.org/metapackage/clisp/versions

Re: crashing socket tests

[Bruno H. <br...@cl...>]

Hi Vladimir,

> And here is the output in gdb:
> 
> [1]> (describe nil)
> ...
> BEFORE: STREAM: 0xb0000005ac0, ENCODING: 0xc000001a280
> AFTER: STREAM: 0xb0000005ac0, ENCODING: 0xc000001a280
> ... /* VTZ: plenty of the above */
> BEFORE: STREAM: 0xb0000005ac0, ENCODING: 0xc000001a280
> AFTER: STREAM: 0xb0000005ac0, ENCODING: 0xc000001a280
> PERFORM GC: 0 /*VTZ: first GC run */
> BEFORE: STREAM: 0xb0000001780, ENCODING: 0xc000001a280
> 
> *** - handle_fault error2 ! address = 0xc000001a2b8 not in
> [0xc0000000000,0xc00000179f0) !

Oh, you are really getting closer!

> The stream object has been moved due to compaction but strm_encoding has
> either not moved (unlikely - its heap has shrunk) or has not been updated.

I'd also guess that it has not been updated. Is the reclength of the
stream appropriate? Has the reclength been changed since the allocate_stream
call?

Meanwhile, I'm seeing a different crash (in a build-porting64-gcc-debug_gcsafety
build with -DOLD_GC), but also related to socket streams:


(MULTIPLE-VALUE-BIND (RUN ARGS) (CMD-ARGS) (LET ((SE (SOCKET-SERVER))) (RUN-PROGRAM RUN :ARGUMENTS (APPEND ARGS (LIST "-q" "-q" "-x" (FORMAT NIL "(close (socket:socket-connect ~D))" (SOCKET-SERVER-PORT SE)))) :WAIT NIL :INPUT NIL :OUTPUT NIL) (UNWIND-PROTECT (WITH-OPEN-STREAM (SO (SOCKET-ACCEPT SE)) (LIST (SOCKET-STATUS SO) (WRITE-LINE "foo" SO) (SOCKET-STATUS SO) (CHECK-OS-ERROR (READ-CHAR SO) (:ECONNRESET 104)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (CHECK-OS-ERROR (WRITE-LINE "bar" SO) (:EPIPE 32)) (NULL (MEMBER (SOCKET-STATUS SO) '(:EOF :APPEND))) (HANDLER-CASE (READ-CHAR SO) (END-OF-FILE (C) (PRINC 'READ-CHAR) (PRINC-ERROR C) 'END-OF-FILE)))) (SOCKET-SERVER-CLOSE SE))))
STACK size: 98238 [0x300000bfe00 0x30000000010]

[../src/stream.d:6199] [OS-STREAM-ERROR]: OS-STREAM-ERROR(104): Connection reset by peer
Makefile:25: die Regel für Ziel „tests“ scheiterte


And gdb says:

#0  0x000000000056bb30 in ngci_pointable (obj=...) at ../src/lispbibl.d:7402
#1  0x00000000005c3c23 in stream_isbuffered_low (stream=..., avail=0x7ffcea564a18) at ../src/stream.d:17919
#2  0x00000000005ae115 in handle_set (socket=..., readfds=0x7ffcea564b70, writefds=0x7ffcea564bf0, errorfds=0x7ffcea564c70, need_new_list=0x0, 
    non_empty_buffers_p=0x7ffcea564aed) at ../src/stream.d:14401
#3  0x00000000005af029 in C_socket_status () at ../src/stream.d:14517

Re: OLD_GC

[Vladimir T. <vtz...@gm...>]

I understand this and it's the right approach, imo.
Now as I re-read, my statement may sound as if I'm kind of offended -
definitely not the case :).

Related issue is the barrier to entry for newcomers. Having so many build
options and the dense codebase cause frustration to people interested to
get involved. I don't know what is the solution for this but it's
definitely a problem.

Normal users are also affected - people try something and submit bug
reports without reading http://www.clisp.org/impnotes/clisp.html#bugs and
following conversation is about 'clisp --version', build options, etc.
Probably having binary releases is the 'good enough' solution for this.



On Sat, May 27, 2017 at 10:41 PM, Bruno Haible <br...@cl...> wrote:

> Hi Vladimir,
>
> > I see you've added OLD_GC to revert to pre-MT GC. While adding MT stuff I
> > tried hard to keep everything "as is" in single thread builds.
>
> This is good, and I appreciate it. The principle is that any complex
> feature
> should have a simple substitute, so that we can isolate bugs by trying
> to reproduce them in various configurations. This is the idea behind
> ENABLE_UNICODE, NO_GENERATIONAL_GC, NO_GETTEXT, and so on.
>
> For the GC, there's not only your existing (past) changes. There's also
> new algorithm alternatives that we may implement in the future, such as
>   - a "1 page per object" model, that may be useful with valgrind,
>   - a "1 new generation per thread" structure, that would make the
>     allocation of a new object in MT lock-less in most cases,
>   - a possible parallel or incremental GC,...
> The OLD_GC is meant as a reference point, to make it easier to
> distinguish bugs due to new GC changes from bugs outside the GC.
> The DEBUG_GCSAFETY instrumentation catches a number of bugs of the
> latter category, but not all.
>
> Bruno
>
>

Re: OLD_GC

[Bruno H. <br...@cl...>]

Hi Vladimir,

> I see you've added OLD_GC to revert to pre-MT GC. While adding MT stuff I
> tried hard to keep everything "as is" in single thread builds.

This is good, and I appreciate it. The principle is that any complex feature
should have a simple substitute, so that we can isolate bugs by trying
to reproduce them in various configurations. This is the idea behind
ENABLE_UNICODE, NO_GENERATIONAL_GC, NO_GETTEXT, and so on.

For the GC, there's not only your existing (past) changes. There's also
new algorithm alternatives that we may implement in the future, such as
  - a "1 page per object" model, that may be useful with valgrind,
  - a "1 new generation per thread" structure, that would make the
    allocation of a new object in MT lock-less in most cases,
  - a possible parallel or incremental GC,...
The OLD_GC is meant as a reference point, to make it easier to
distinguish bugs due to new GC changes from bugs outside the GC.
The DEBUG_GCSAFETY instrumentation catches a number of bugs of the
latter category, but not all.

Bruno

Re: crashing socket tests

[Bruno H. <br...@cl...>]

> 1) In build-porting64-gcc-portability
> 
> This is a build with
> 
> $ grep '\(SPVW_\|GENERA\)' lispbibl.h
> #define NO_GENERATIONAL_GC 1
> #define SPVW_MIXED 
> #define SPVW_PAGES 
> 
> Here I get a crash in "make check-tests"
> 
> (TEST-FLOAT-IO-CONSISTENCY :FROM 1.0s-30 :BY 10 :TO 1.0s30 :REPEAT 100)
> Makefile:25: recipe for target 'tests' failed
> make[1]: *** [tests] Segmentation fault (core dumped)

I've fixed this one now.

The recipe to reproduce it was:

- Use the build-porting64-gcc-debug_gcsafety build,
  with modified CFLAGS: Originally
  CFLAGS = ... -ggdb -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DDEBUG_GCSAFETY -DENABLE_UNICODE -DDYNAMIC_FFI
  Add to CFLAGS for MIXED_BLOCKS or MIXED_PAGES memory model: -DNO_ADDRESS_SPACE_ASSUMPTIONS

- Run ./clisp and enter:

(defun test-float-io-consistency (&key from to by repeat)
  (loop :for max = from :then (* by max) :while (< max to) :nconc
    (loop :repeat repeat :for x = (random max)
      :for y = (if (zerop (random 2)) x (- x))
      :unless (= y (read-from-string (prin1-to-string y)))
      :collect (cons y (multiple-value-list (integer-decode-float y))))))
(compile *)

(test-float-io-consistency :from 1s-30 :by 10 :to 1s30 :repeat 1000)

It crashes in the GC because make_machine_code is being invoked on a function
pointer that does not have the necessary alignment.

I've now
  - added a check to make_machine_code (if SAFETY >= 2),
  - eliminated the wrong invocations of make_machine_code.

Bruno

Re: crashing socket tests

[Vladimir T. <vtz...@gm...>]

Hi Bruno,

On Sat, May 27, 2017 at 12:14 AM, Vladimir Tzankov <vtz...@gm...>
wrote:

> There was no GC run since the startup (double checked it) so it should not
>> be GC safety issue.
>>
>
> Actually I was wrong in my double checking :(.
> This happens after the first GC. Would classify it as GC safety issue now.
>

I see you've added OLD_GC to revert to pre-MT GC. While adding MT stuff I
tried hard to keep everything "as is" in single thread builds.

Back to the issue - I experience the same problem with OLD_GC
enabled. After adding some debug logging (see the diff below) I observe
strm_encoding of the stream object is not getting updated during the GC.
This is SINGLEMAP_MEMORY with OLD_GC.

vtz@debian:~/clisp/src$ hg diff .
diff -r d573e8e54c34 src/spvw_garcol_old.d
--- a/src/spvw_garcol_old.d Fri May 26 19:24:49 2017 +0200
+++ b/src/spvw_garcol_old.d Thu May 25 06:00:37 2017 +0300
@@ -1493,6 +1493,7 @@
 /* perform normal Garbage Collection: */
 local void gar_col_normal (void)
 {
+  printf("PERFORM GC: %d\n", gc_count);
   var uintM gcstart_space;      /* occupied memory at GC-start */
   var uintM gcend_space;        /* occupied memory at GC-end */
   var object all_weakpointers;  /* list of active Weak-pointers */
diff -r d573e8e54c34 src/stream.d
--- a/src/stream.d Fri May 26 19:24:49 2017 +0200
+++ b/src/stream.d Thu May 25 06:00:37 2017 +0300
@@ -6651,8 +6651,10 @@
     var uintL available = endvalid - BufferedStream_index(stream);
     var const uintB* bptr = bufferptr;
     var chart* cptr = &c;
+    printf("BEFORE: STREAM: %p, ENCODING: %p\n", stream, encoding);
     Encoding_mbstowcs(encoding)
       (encoding,stream,&bptr,bufferptr+available,&cptr,&c+1);
+    printf("AFTER: STREAM: %p, ENCODING: %p\n", stream, encoding);
     if (cptr == &c+1) {
       var uintL n = bptr-bufferptr;
       /* increment index and position */


And here is the output in gdb:

[1]> (describe nil)
...
BEFORE: STREAM: 0xb0000005ac0, ENCODING: 0xc000001a280
AFTER: STREAM: 0xb0000005ac0, ENCODING: 0xc000001a280
... /* VTZ: plenty of the above */
BEFORE: STREAM: 0xb0000005ac0, ENCODING: 0xc000001a280
AFTER: STREAM: 0xb0000005ac0, ENCODING: 0xc000001a280
PERFORM GC: 0 /*VTZ: first GC run */
BEFORE: STREAM: 0xb0000001780, ENCODING: 0xc000001a280

*** - handle_fault error2 ! address = 0xc000001a2b8 not in
[0xc0000000000,0xc00000179f0) !
Breakpoint 1, sigsegv_handler_failed (address=address@entry=0xc000001a2b8)
at ../src/spvw_sigsegv.d:64
64  fputc('\n',stderr);
(gdb) p /x mem.heaps[0x0b]
$1 = {pages = {start = 0xb0000000000, end = 0xb0000001a60, gcpriv =
{firstmarked = 0xb0000001000, l = 0xb0000001000, d = 0xb0000001000, next =
0xb0000001000}},
  heap_limit = 0xb0000002000, heap_hardlimit = 0xc0000000000,
heap_gen0_start = 0xb0000000000, heap_gen0_end = 0xb0000000d80,
heap_gen1_start = 0xb0000001000,
  physpages = 0x83aff0}
(gdb) p /x mem.heaps[0x0c]
$2 = {pages = {start = 0xc0000000000, end = 0xc00000183a8, gcpriv =
{firstmarked = 0xc0000018000, l = 0xc0000018000, d = 0xc0000018000, next =
0xc0000018000}},
  heap_limit = 0xc0000019000, heap_hardlimit = 0xd0000000000,
heap_gen0_start = 0xc0000000000, heap_gen0_end = 0xc00000179f0,
heap_gen1_start = 0xc0000018000,
  physpages = 0x83ca10}

The stream object has been moved due to compaction but strm_encoding has
either not moved (unlikely - its heap has shrunk) or has not been updated.

clisp-cvs Digest, Vol 77, Issue 2

[<cli...@li...>]

Send clisp-cvs mailing list submissions to
	cli...@li...

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/clisp-cvs
or, via email, send a message with subject or body 'help' to
	cli...@li...

You can reach the person managing the list at
	cli...@li...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clisp-cvs digest..."


CLISP CVS commits for today

Today's Topics:

   1. clisp: Reinstall the old GC from clisp-2.47.
      (cli...@li...)
   2. clisp: Optimize unneeded code when SIGCLD is not defined.
      (cli...@li...)
   3. clisp: Allow regular testing of SPVW_PURE_PAGES memory
      management. (cli...@li...)
   4. clisp: Allow regular testing of memory management with
      limited m... (cli...@li...)


----------------------------------------------------------------------

Message: 1
Date: Fri, 26 May 2017 17:31:13 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Reinstall the old GC from clisp-2.47.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/f50238f0f995
changeset: 15906:f50238f0f9953a7cd614c7026bbe5a337665e35e
user:      Bruno Haible <br...@cl...>
date:      2017-05-26 18:33:25 +0200
description:
Reinstall the old GC from clisp-2.47.

This should provide a reference point when hunting down GC bugs.

diffstat:

 Makefile.devel          |    16 +-
 src/ChangeLog           |    30 +
 src/lispbibl.d          |     9 +-
 src/makemake.in         |     2 +-
 src/spvw.d              |    37 +-
 src/spvw_allocate_old.d |   759 ++++++++++++++++++
 src/spvw_circ_old.d     |  1913 +++++++++++++++++++++++++++++++++++++++++++++++
 src/spvw_fault_old.d    |   271 ++++++
 src/spvw_garcol_old.d   |    31 +-
 src/spvw_genera1_old.d  |  1218 +++++++++++++++++++++++++++++
 src/spvw_genera3_old.d  |    74 +
 src/spvw_global_old.d   |   484 +++++++++++
 src/spvw_heap_old.d     |   144 +++
 src/spvw_memfile.d      |    23 +-
 src/spvw_space.d        |     2 +-
 src/spvw_typealloc.d    |     2 +-
 16 files changed, 4978 insertions(+), 37 deletions(-)



------------------------------

Message: 2
Date: Fri, 26 May 2017 17:31:14 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Optimize unneeded code when SIGCLD is not defined.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/301943720553
changeset: 15907:301943720553273d6a97fb1a07e50341753896a0
user:      Bruno Haible <br...@cl...>
date:      2017-05-26 15:13:20 +0200
description:
Optimize unneeded code when SIGCLD is not defined.

diffstat:

 src/ChangeLog     |  6 ++++++
 src/spvw_sigcld.d |  7 ++++---
 2 files changed, 10 insertions(+), 3 deletions(-)



------------------------------

Message: 3
Date: Fri, 26 May 2017 17:31:16 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Allow regular testing of SPVW_PURE_PAGES memory
	management.
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/1c8401b465bc
changeset: 15908:1c8401b465bc67df71f80fcb0d7fb34b82f09de2
user:      Bruno Haible <br...@cl...>
date:      2017-05-26 18:27:32 +0200
description:
Allow regular testing of SPVW_PURE_PAGES memory management.

diffstat:

 Makefile.devel |  56 ++++++++++++++++++++++++++++++++++++++++++++------------
 src/ChangeLog  |  18 ++++++++++++++++++
 src/lispbibl.d |  12 ++++++++++--
 3 files changed, 72 insertions(+), 14 deletions(-)



------------------------------

Message: 4
Date: Fri, 26 May 2017 17:31:17 +0000
From: cli...@li...
To: cli...@li...
Subject: clisp: Allow regular testing of memory management with
	limited m...
Message-ID:
	<hg....@sf...>
	
Content-Type: text/plain; charset="us-ascii"

details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/d573e8e54c34
changeset: 15909:d573e8e54c34c8a2b46877a877d81efcb1b7d60e
user:      Bruno Haible <br...@cl...>
date:      2017-05-26 19:24:49 +0200
description:
Allow regular testing of memory management with limited memory size.

diffstat:

 Makefile.devel        |  32 ++++++++++++++++++++++++++++++++
 modules/asdf/Makefile |   2 +-
 src/ChangeLog         |   8 ++++++++
 3 files changed, 41 insertions(+), 1 deletions(-)



------------------------------

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

------------------------------

Subject: Digest Footer

_______________________________________________
clisp-cvs mailing list
cli...@li...
https://lists.sourceforge.net/lists/listinfo/clisp-cvs


------------------------------

End of clisp-cvs Digest, Vol 77, Issue 2
****************************************

Re: libffcall and selinux

[<don...@is...>]

output from make check:

(STRINGP (WITH-OUTPUT-TO-STRING (S) (DESCRIBE NIL S)))
;; connecting to "http://clisp.org/impnotes/id-href.map"...connected...HTTP/1.1 200 OK...74,909 bytes
;; SYSTEM::GET-STRING-MAP(#<IO INPUT-BUFFERED SOCKET-STREAM CHARACTER clisp.org:80>)...Makefile:25: recipe for target 'tests' failed
make[1]: *** [tests] Segmentation fault (core dumped)

corresponding output in system log

 > > > May 25 12:10:41 localhost audit: ANOM_ABEND auid=0 uid=0 gid=0 ses=3
 > > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=11356
 > > comm="lisp.run" exe="/home/don/hg/clisp/build-dir/lisp.run" sig=11
 > > > May 25 12:10:41 localhost kernel: lisp.run[11356]: segfault at
 > > b000000b1f1 ip 00000000004bdeb4 sp 00007ffd4d6b82f0 error 4 in
 > > lisp.run[400000+2c1000]
 > > > May 25 12:10:42 localhost abrt-hook-ccpp: Process 11356 (lisp.run) of
 > > user 0 killed by SIGSEGV - dumping core
 > > >
 > > > I'm guessing this is related to the problem you're now working on,
 > > > but not related to selinux.
 > >

 > On Fri, May 26, 2017 at 12:28 AM, Bruno Haible <br...@cl...> wrote:
 > 
 > > Yes, nearly everyone on Linux/x86_64 is seeing this (or a similar) crash.

Vladimir Tzankov writes:

 > OSX(x86_64) as well.
 > And again I'll emphasise I experience this only on non-ffi builds. It is
 > consistently reproducible - have to find time to go after it.

Then this one is different, cause it DOES include FFI:

[root@localhost build-dir]# full/lisp.run -M full/lispinit.mem
STACK size: 98238 [0x300000bfe00 0x30000000010]
...
Type :h and hit Enter for context help.

[1]> *features*
(:RAWSOCK :READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS :MOP
 :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER :LOGICAL-PATHNAMES :SOCKETS
 :GENERIC-STREAMS :SCREEN :FFI :GETTEXT :UNICODE :BASE-CHAR=CHARACTER
 :WORD-SIZE=64 :PC386 :UNIX)
[2]> 

Re: crashing socket tests

[Vladimir T. <vtz...@gm...>]

>
> There was no GC run since the startup (double checked it) so it should not
> be GC safety issue.
>

Actually I was wrong in my double checking :(.
This happens after the first GC. Would classify it as GC safety issue now.

Re: libffcall and selinux

[Vladimir T. <vtz...@gm...>]

On Fri, May 26, 2017 at 12:28 AM, Bruno Haible <br...@cl...> wrote:

> Hi Don,
>
> > May 25 12:10:41 localhost audit: ANOM_ABEND auid=0 uid=0 gid=0 ses=3
> subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=11356
> comm="lisp.run" exe="/home/don/hg/clisp/build-dir/lisp.run" sig=11
> > May 25 12:10:41 localhost kernel: lisp.run[11356]: segfault at
> b000000b1f1 ip 00000000004bdeb4 sp 00007ffd4d6b82f0 error 4 in
> lisp.run[400000+2c1000]
> > May 25 12:10:42 localhost abrt-hook-ccpp: Process 11356 (lisp.run) of
> user 0 killed by SIGSEGV - dumping core
> >
> > I'm guessing this is related to the problem you're now working on,
> > but not related to selinux.
>
> Yes, nearly everyone on Linux/x86_64 is seeing this (or a similar) crash.
>

OSX(x86_64) as well.
And again I'll emphasise I experience this only on non-ffi builds. It is
consistently reproducible - have to find time to go after it.

Re: libffcall and selinux

[<don...@is...>]

Bruno Haible writes:

 > Yes, nearly everyone on Linux/x86_64 is seeing this (or a similar)
 > crash.

When did this start?

 > > make -k check also shows
 > >  > form: (nth-prime 150)
 > > 
 > > *** - Program stack overflow. RESET
 > 
 > Now this means that the default stack size is quite small. What's
 > the result of

 > $ ulimit -a | grep stack
 > ? For me, it's:
 > stack size              (kbytes, -s) 8192

the current limit (8515) seems to be as high as I can set it.
You consider that to be small?  

 > > Let me know if I can do anything else useful with this VM before 
 > > I turn it off.
 > 
 > Yes, it would be useful to enable SELinux checks (at least those
 > that smell like related to "restricted mprotect" or like "write xor
 > execute" or similar, and see how clisp behaves with these checks
 > enabled.

I don't understand selinux very well.
And I'm also not sure I understand what you're looking for, but
here's an attempt.  Let me know if it gives you any better ideas.

It seems like there are all sorts of policies that one COULD write,
one that is installed in a given distribution, and the one that comes
with Fedora-Server-dvd-x86_64-25-1.3 is the one I initially tested.
That policy does seem to me to have some strange features, though.
Just looking at 
 getsebool -a | grep selinuxuser
I see
 selinuxuser_execheap --> off
which is what causes the AVC denial in configuring ffcall.
(I verified that by turning it on and redoing config.)

This is described as follows at
 https://mgrepl.fedorapeople.org/man_selinux/Fedora18/user.html

 If you want to allow unconfined executables to make their heap memory
 executable. Doing this is a really bad idea. Probably indicates a
 badly coded executable, but could indicate an attack. This executable
 should be reported in bugzilla, you must turn on the
 selinuxuser_execheap boolean.
 setsebool -P selinuxuser_execheap 1

However, getsebool also shows
 selinuxuser_execstack --> on

 If you want to allow unconfined executables to make their stack
 executable. This should never, ever be necessary. Probably indicates
 a badly coded executable, but could indicate an attack. This
 executable should be reported in bugzilla, you must turn on the
 selinuxuser_execstack boolean.
 setsebool -P selinuxuser_execstack 1

I don't understand why that one is on by default.
But when I turn it off and do make -k check for clisp I don't see
any AVC denials.

 selinuxuser_execmod --> on

 If you want to allow all unconfined executables to use libraries
 requiring text relocation that are not labeled textrel_shlib_t, you
 must turn on the selinuxuser_execmod boolean.
 setsebool -P selinuxuser_execmod 1 

I don't quite follow all that, but again, turning it off doesn't
cause any AVC dnials in clisp make -k check.

I don't see any booleans with protect (or even prot) in the name.

Re: primitive integer types

[Bruno H. <br...@cl...>]

Hi Daniel,

> The real solution is to use the fixed width integer types provided by the
> (C99 and newer) standard (int32_t and int64_t). ...
> 
> I'll look whether I can polish the changes to a complete patch next week,

Will this patch be using gnulib's <stdint.h> replacement that clisp already
makes use of?
https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html

I think the tricky part is to ensure that the generated clisp.h can be used
by any compiler that runs on the same platform and produces code for the
same ABI. (e.g. on Solaris, "gcc -m64" and "cc -xarch=generic64").

Bruno