clisp-devel — closed list for developers and testers

Re: Timing bug?

[Sam S. <sd...@gn...>]

> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2012-09-22 07:32:31 +0200]:
>
>      NEVER USE FLOATING POINT NUMBERS.

This is too drastic, IMNSHO.

A programmer has to understand them,
avoid them when possible,
and use them when necessary.
E.g., inverting an 1000x1000 integer matrix in rationals will take
forever and run out of memory. Doing the same in floats using the
standard linear algebra packages (R/Octave/&c) is instantaneous.

The basic advice, IMHO, should be "stay in one realm": use only integers
or only floats throughout your calculations.

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 12.04 (precise) X 11.0.11103000
http://www.childpsy.net/ http://jihadwatch.org http://palestinefacts.org
http://www.PetitionOnline.com/tap12009/ http://openvotingconsortium.org
Computers are like air conditioners: they don't work with open windows!

Re: Timing bug?

[Pascal J. B. <pj...@in...>]

Matthew Stickney <mts...@gm...> writes:

> Hi,
>
> I've come across a strange performance problem with CLISP 2.49 while
> working on a project today. I have the following function, simplified
> from some code for doing IO with timeouts (is there a better way to do
> this than polling?):
>
> (defun poll-test ()
>   (let ((deadline (+ (get-internal-real-time)
>                           (* .5 internal-time-units-per-second))))
>     (loop while (<= (get-internal-real-time) deadline)
>        do (sleep 0.01))))
>
> Most of the time the loop is never run, which is surprising (is there
> really a .5 second lag between computing/storing the deadline value

You don't want .5 second lag, you want 1/2 second lag.

.5 is read as a floating point number of type specified by
*read-default-float-format* which is single float by default.
Therefore deadline will be a number with 6 decimal digits of precision,
and of the order of 1e15 currently.  Therefore it will be on the order
of 1e9 seconds in the future.

Read that:

    http://www.exploringbinary.com/the-four-stages-of-floating-point-competence/  
    What Every Computer Scientist Should Know About Floating-Point Arithmetic
    http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
    http://portal.acm.org/citation.cfm?id=103163
    http://focus.hut.fi/docs/WorkShop/common/ug/goldberg1.doc.html

and reach the same conclusion as I have: 

     NEVER USE FLOATING POINT NUMBERS.


If you near real numbers, integrate such a library:

    RealLib3:
    http://www.brics.dk/~barnie/RealLib/


Also, about time, have a look at:

http://unix4lyfe.org/time/
http://naggum.no/lugm-time.html
http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time-wisdom



> Is this a bug? 

Yes.


> Is my system (or code) broken? 

No.


> Is this just my scheduler going crazy?

No.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

Timing bug?

[Matthew S. <mts...@gm...>]

Hi,

I've come across a strange performance problem with CLISP 2.49 while
working on a project today. I have the following function, simplified
from some code for doing IO with timeouts (is there a better way to do
this than polling?):

(defun poll-test ()
  (let ((deadline (+ (get-internal-real-time)
                          (* .5 internal-time-units-per-second))))
    (loop while (<= (get-internal-real-time) deadline)
       do (sleep 0.01))))

Most of the time the loop is never run, which is surprising (is there
really a .5 second lag between computing/storing the deadline value
and the first loop iteration?), but understandable. When the loop does
run, however, the function takes an awfully long time to complete
(real time), but uses relatively little cpu time:

CL-USER> (time (poll-test))
Real time: 46.03638 sec.
Run time: 0.27196 sec.
Space: 211992 Bytes

On a few occasions, I've even interrupted one of these tests at
300-400 seconds (real time, reported by the time form above), which
makes me fairly certain this isn't your normal garbage-collection
pause. An strace of the clisp process during one of these long runs
shows lots of select() calls, all of which timeout, with periodic
mmap()s. The long run behavior can be tricky to reproduce, and
combined with the extremely-short no-loop calls suggests this is some
sort of timing-related issue. I've traced the bytecode from
"(disassemble #'poll-test)" by hand and it looks solid, if that's of
any diagnostic use.

Is this a bug? Is my system (or code) broken? Is this just my
scheduler going crazy?

-Matt Stickney

[ clisp-Bugs-3545905 ] Hang with exemption

[SourceForge.net <no...@so...>]

Bugs item #3545905, was opened at 2012-07-19 08:29
Message generated for change (Settings changed) made by vtz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: multithreading
Group: lisp error
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Hang with exemption

Initial Comment:
The following RUN function eventually hangs for both the latest build (15589) and clisp-2.49.

(defstruct sema
  (count 0)
  (lock (mt:make-mutex))
  (cvar (mt:make-exemption)))

(defun inc-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (incf (sema-count sema))
    (mt:exemption-signal (sema-cvar sema))))

(defun dec-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (loop (cond ((plusp (sema-count sema))
                 (decf (sema-count sema))
                 (return))
                (t
                 (mt:exemption-wait
                  (sema-cvar sema) (sema-lock sema)))))))

(defun test (thread-count)
  (let ((from-threads (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda () (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (dec-sema from-threads))))

(defun run ()
  (loop
     (test 16)
     (format t ".")
     (finish-output)))

Sometimes the outcome with the latest build is:

Internal error: statement in file "zthread.d", line 771 has been reached!!

The number of iterations until hanging tends to decrease as thread-count increases.

The following replacement for TEST should also be checked (it has exposed bugs in other CL implementations where the previous TEST did not).

(defun test (thread-count)
  (let ((from-threads (make-sema))
        (to-threads   (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda ()
            (dec-sema to-threads)
            (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (inc-sema to-threads))
    (loop repeat thread-count do (dec-sema from-threads))))

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

GNU CLISP 2.49+ (2010-07-17) (built 3551638844) (memory 3551639097)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL
 INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE
 BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

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

Comment By: lmj ()
Date: 2012-09-15 07:27

Message:
I can still reproduce with latest in hg (15594) with specs given above;
symptoms haven't changed.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:26

Message:
In the past months I've tried to reproduce this on linux and osx (both i386
and x86_64) without success. Also tried different gcc version (up to
4.7.1).

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:26

Message:
This bug report is now marked as "pending"/"works for me".
This means that we think that we cannot reproduce the problem
and cannot do anything about it.
Unless you - the reporter - act within 2 weeks
(e.g., by submitting a self-contained test case
or answering our other recent requests),
the bug will be permanently closed.
Sorry about the inconvenience - 
we hope your silence means that 
you are no longer observing the problem either.


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

Comment By: lmj ()
Date: 2012-07-20 03:35

Message:
I have just discovered that the problem goes away when clisp is
configured --with-debug.

My only configure options are --prefix and --with-threads=POSIX_THREADS.

For me it fails within seconds for either TEST. This is a Core i7
3.4GHz running 32-bit Linux.

I have been compiling all functions. It takes longer for the issue to
appear with interpreted functions, though it still fails within a few
minutes at most.

I recently got a new error while running interpreted functions:

*** thread is going into lisp land without calling end_blocking_call()

On SBCL I once had a condition variable problem which was either
wholly present or wholly absent depending upon some dice roll at
launch time. (The SBCL bundled with Ubuntu sometimes (but not always)
decided to produce spurious wakeups, which I had not handled properly.
This caused some confusion because a vanilla SBCL compiled locally did
not generate these wakeups.) Perhaps not seeing the issue after a
couple minutes means a restart is needed.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 00:27

Message:
I can't reproduce it (tested both on Linux and OSX).
I used up to 128 threads and waited about 5 minutes on each run. Also
tested the second 'test' function without experiencing problems. 

Reaching zthread.d:771 means inconsistency in internal mutex record.
Will continue to test - any additional info (though not sure what to ask
for - debugging is an option but it's not easy one) will be helpful.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

[ clisp-Bugs-3545905 ] Hang with exemption

[SourceForge.net <no...@so...>]

Bugs item #3545905, was opened at 2012-07-19 08:29
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: multithreading
Group: lisp error
Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Hang with exemption

Initial Comment:
The following RUN function eventually hangs for both the latest build (15589) and clisp-2.49.

(defstruct sema
  (count 0)
  (lock (mt:make-mutex))
  (cvar (mt:make-exemption)))

(defun inc-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (incf (sema-count sema))
    (mt:exemption-signal (sema-cvar sema))))

(defun dec-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (loop (cond ((plusp (sema-count sema))
                 (decf (sema-count sema))
                 (return))
                (t
                 (mt:exemption-wait
                  (sema-cvar sema) (sema-lock sema)))))))

(defun test (thread-count)
  (let ((from-threads (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda () (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (dec-sema from-threads))))

(defun run ()
  (loop
     (test 16)
     (format t ".")
     (finish-output)))

Sometimes the outcome with the latest build is:

Internal error: statement in file "zthread.d", line 771 has been reached!!

The number of iterations until hanging tends to decrease as thread-count increases.

The following replacement for TEST should also be checked (it has exposed bugs in other CL implementations where the previous TEST did not).

(defun test (thread-count)
  (let ((from-threads (make-sema))
        (to-threads   (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda ()
            (dec-sema to-threads)
            (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (inc-sema to-threads))
    (loop repeat thread-count do (dec-sema from-threads))))

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

GNU CLISP 2.49+ (2010-07-17) (built 3551638844) (memory 3551639097)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL
 INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE
 BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

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

Comment By: lmj ()
Date: 2012-09-15 07:27

Message:
I can still reproduce with latest in hg (15594) with specs given above;
symptoms haven't changed.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:26

Message:
In the past months I've tried to reproduce this on linux and osx (both i386
and x86_64) without success. Also tried different gcc version (up to
4.7.1).

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:26

Message:
This bug report is now marked as "pending"/"works for me".
This means that we think that we cannot reproduce the problem
and cannot do anything about it.
Unless you - the reporter - act within 2 weeks
(e.g., by submitting a self-contained test case
or answering our other recent requests),
the bug will be permanently closed.
Sorry about the inconvenience - 
we hope your silence means that 
you are no longer observing the problem either.


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

Comment By: lmj ()
Date: 2012-07-20 03:35

Message:
I have just discovered that the problem goes away when clisp is
configured --with-debug.

My only configure options are --prefix and --with-threads=POSIX_THREADS.

For me it fails within seconds for either TEST. This is a Core i7
3.4GHz running 32-bit Linux.

I have been compiling all functions. It takes longer for the issue to
appear with interpreted functions, though it still fails within a few
minutes at most.

I recently got a new error while running interpreted functions:

*** thread is going into lisp land without calling end_blocking_call()

On SBCL I once had a condition variable problem which was either
wholly present or wholly absent depending upon some dice roll at
launch time. (The SBCL bundled with Ubuntu sometimes (but not always)
decided to produce spurious wakeups, which I had not handled properly.
This caused some confusion because a vanilla SBCL compiled locally did
not generate these wakeups.) Perhaps not seeing the issue after a
couple minutes means a restart is needed.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 00:27

Message:
I can't reproduce it (tested both on Linux and OSX).
I used up to 128 threads and waited about 5 minutes on each run. Also
tested the second 'test' function without experiencing problems. 

Reaching zthread.d:771 means inconsistency in internal mutex record.
Will continue to test - any additional info (though not sure what to ask
for - debugging is an option but it's not easy one) will be helpful.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

[SourceForge.net <no...@so...>]

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

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

Comment By: lmj ()
Date: 2012-09-14 20:30

Message:
Oh, thread_interrupt pops the stack when called with the current thread.
Nevermind.

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

Comment By: lmj ()
Date: 2012-09-14 15:45

Message:
... I mean using RESTART-CASE or equivalent to unwind; THREAD-INTERRUPT
seems to be overkill. (It wouldn't be sufficent to set :INVOKE-FUNCTION to
an empty lambda.)

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

Comment By: lmj ()
Date: 2012-09-14 15:26

Message:
Why does the :INVOKE-FUNCTION call THREAD-INTERRUPT? Isn't it sufficient to
do nothing? Execution will then reach the end of the thread function, and
the thread is done.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:20

Message:
Thanks for the suggestion - it has been just implemented and
checked into the CVS repository, and will be available in the next
release.
If you cannot wait for the next release, you can get the latest
development sources from the CVS and compile them yourself.
Please be aware that the development sources are not stable and
might not even compile on your machine.
You should report any problems you encounter with the CVS sources
to the <clisp-devel> mailing list, not to the <clisp-list>.
If you use the CVS sources, you should read <clisp-devel>
since the CVS log goes there.

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

Comment By: lmj ()
Date: 2012-07-20 05:03

Message:
I'm not sure I understand your point. The standard draws a distinction
between a REPL process and other processes.

"Typically, in an interactive listener, the invocation of abort returns to
the Lisp reader phase of the Lisp read-eval-print loop, though in some
batch or multi-processing situations there may be situations in which
having it kill the running process is more appropriate."
http://clhs.lisp.se/Body/r_abort.htm

So the main REPL thread is already doing what the standard suggests.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 03:28

Message:
Currently we throw special tag in the context of the thread in order to
cause it to exit - I can replace this with abort restart.
However what to do with the "main" thread - should we do the same? It is
not good to treat it specially.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

[SourceForge.net <no...@so...>]

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

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

Comment By: lmj ()
Date: 2012-09-14 15:45

Message:
... I mean using RESTART-CASE or equivalent to unwind; THREAD-INTERRUPT
seems to be overkill. (It wouldn't be sufficent to set :INVOKE-FUNCTION to
an empty lambda.)

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

Comment By: lmj ()
Date: 2012-09-14 15:26

Message:
Why does the :INVOKE-FUNCTION call THREAD-INTERRUPT? Isn't it sufficient to
do nothing? Execution will then reach the end of the thread function, and
the thread is done.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:20

Message:
Thanks for the suggestion - it has been just implemented and
checked into the CVS repository, and will be available in the next
release.
If you cannot wait for the next release, you can get the latest
development sources from the CVS and compile them yourself.
Please be aware that the development sources are not stable and
might not even compile on your machine.
You should report any problems you encounter with the CVS sources
to the <clisp-devel> mailing list, not to the <clisp-list>.
If you use the CVS sources, you should read <clisp-devel>
since the CVS log goes there.

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

Comment By: lmj ()
Date: 2012-07-20 05:03

Message:
I'm not sure I understand your point. The standard draws a distinction
between a REPL process and other processes.

"Typically, in an interactive listener, the invocation of abort returns to
the Lisp reader phase of the Lisp read-eval-print loop, though in some
batch or multi-processing situations there may be situations in which
having it kill the running process is more appropriate."
http://clhs.lisp.se/Body/r_abort.htm

So the main REPL thread is already doing what the standard suggests.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 03:28

Message:
Currently we throw special tag in the context of the thread in order to
cause it to exit - I can replace this with abort restart.
However what to do with the "main" thread - should we do the same? It is
not good to treat it specially.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

[SourceForge.net <no...@so...>]

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

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

Comment By: lmj ()
Date: 2012-09-14 15:26

Message:
Why does the :INVOKE-FUNCTION call THREAD-INTERRUPT? Isn't it sufficient to
do nothing? Execution will then reach the end of the thread function, and
the thread is done.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:20

Message:
Thanks for the suggestion - it has been just implemented and
checked into the CVS repository, and will be available in the next
release.
If you cannot wait for the next release, you can get the latest
development sources from the CVS and compile them yourself.
Please be aware that the development sources are not stable and
might not even compile on your machine.
You should report any problems you encounter with the CVS sources
to the <clisp-devel> mailing list, not to the <clisp-list>.
If you use the CVS sources, you should read <clisp-devel>
since the CVS log goes there.

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

Comment By: lmj ()
Date: 2012-07-20 05:03

Message:
I'm not sure I understand your point. The standard draws a distinction
between a REPL process and other processes.

"Typically, in an interactive listener, the invocation of abort returns to
the Lisp reader phase of the Lisp read-eval-print loop, though in some
batch or multi-processing situations there may be situations in which
having it kill the running process is more appropriate."
http://clhs.lisp.se/Body/r_abort.htm

So the main REPL thread is already doing what the standard suggests.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 03:28

Message:
Currently we throw special tag in the context of the thread in order to
cause it to exit - I can replace this with abort restart.
However what to do with the "main" thread - should we do the same? It is
not good to treat it specially.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

[ clisp-Bugs-3545905 ] Hang with exemption

[SourceForge.net <no...@so...>]

Bugs item #3545905, was opened at 2012-07-19 08:29
Message generated for change (Comment added) made by vtz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: multithreading
Group: lisp error
Status: Open
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Hang with exemption

Initial Comment:
The following RUN function eventually hangs for both the latest build (15589) and clisp-2.49.

(defstruct sema
  (count 0)
  (lock (mt:make-mutex))
  (cvar (mt:make-exemption)))

(defun inc-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (incf (sema-count sema))
    (mt:exemption-signal (sema-cvar sema))))

(defun dec-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (loop (cond ((plusp (sema-count sema))
                 (decf (sema-count sema))
                 (return))
                (t
                 (mt:exemption-wait
                  (sema-cvar sema) (sema-lock sema)))))))

(defun test (thread-count)
  (let ((from-threads (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda () (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (dec-sema from-threads))))

(defun run ()
  (loop
     (test 16)
     (format t ".")
     (finish-output)))

Sometimes the outcome with the latest build is:

Internal error: statement in file "zthread.d", line 771 has been reached!!

The number of iterations until hanging tends to decrease as thread-count increases.

The following replacement for TEST should also be checked (it has exposed bugs in other CL implementations where the previous TEST did not).

(defun test (thread-count)
  (let ((from-threads (make-sema))
        (to-threads   (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda ()
            (dec-sema to-threads)
            (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (inc-sema to-threads))
    (loop repeat thread-count do (dec-sema from-threads))))

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

GNU CLISP 2.49+ (2010-07-17) (built 3551638844) (memory 3551639097)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL
 INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE
 BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

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

>Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:26

Message:
In the past months I've tried to reproduce this on linux and osx (both i386
and x86_64) without success. Also tried different gcc version (up to
4.7.1).

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:26

Message:
This bug report is now marked as "pending"/"works for me".
This means that we think that we cannot reproduce the problem
and cannot do anything about it.
Unless you - the reporter - act within 2 weeks
(e.g., by submitting a self-contained test case
or answering our other recent requests),
the bug will be permanently closed.
Sorry about the inconvenience - 
we hope your silence means that 
you are no longer observing the problem either.


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

Comment By: lmj ()
Date: 2012-07-20 03:35

Message:
I have just discovered that the problem goes away when clisp is
configured --with-debug.

My only configure options are --prefix and --with-threads=POSIX_THREADS.

For me it fails within seconds for either TEST. This is a Core i7
3.4GHz running 32-bit Linux.

I have been compiling all functions. It takes longer for the issue to
appear with interpreted functions, though it still fails within a few
minutes at most.

I recently got a new error while running interpreted functions:

*** thread is going into lisp land without calling end_blocking_call()

On SBCL I once had a condition variable problem which was either
wholly present or wholly absent depending upon some dice roll at
launch time. (The SBCL bundled with Ubuntu sometimes (but not always)
decided to produce spurious wakeups, which I had not handled properly.
This caused some confusion because a vanilla SBCL compiled locally did
not generate these wakeups.) Perhaps not seeing the issue after a
couple minutes means a restart is needed.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 00:27

Message:
I can't reproduce it (tested both on Linux and OSX).
I used up to 128 threads and waited about 5 minutes on each run. Also
tested the second 'test' function without experiencing problems. 

Reaching zthread.d:771 means inconsistency in internal mutex record.
Will continue to test - any additional info (though not sure what to ask
for - debugging is an option but it's not easy one) will be helpful.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

[SourceForge.net <no...@so...>]

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Comment added) made by vtz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-09-14 13:20

Message:
Thanks for the suggestion - it has been just implemented and
checked into the CVS repository, and will be available in the next
release.
If you cannot wait for the next release, you can get the latest
development sources from the CVS and compile them yourself.
Please be aware that the development sources are not stable and
might not even compile on your machine.
You should report any problems you encounter with the CVS sources
to the <clisp-devel> mailing list, not to the <clisp-list>.
If you use the CVS sources, you should read <clisp-devel>
since the CVS log goes there.

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

Comment By: lmj ()
Date: 2012-07-20 05:03

Message:
I'm not sure I understand your point. The standard draws a distinction
between a REPL process and other processes.

"Typically, in an interactive listener, the invocation of abort returns to
the Lisp reader phase of the Lisp read-eval-print loop, though in some
batch or multi-processing situations there may be situations in which
having it kill the running process is more appropriate."
http://clhs.lisp.se/Body/r_abort.htm

So the main REPL thread is already doing what the standard suggests.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 03:28

Message:
Currently we throw special tag in the context of the thread in order to
cause it to exit - I can replace this with abort restart.
However what to do with the "main" thread - should we do the same? It is
not good to treat it specially.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

[ clisp-Bugs-3560795 ] armv6l/armhf: ariarm.c does not get generated

[SourceForge.net <no...@so...>]

Bugs item #3560795, was opened at 2012-08-22 13:11
Message generated for change (Tracker Item Submitted) made by cptsalek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3560795&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Walther (cptsalek)
Assigned to: Bruno Haible (haible)
Summary: armv6l/armhf: ariarm.c does not get generated

Initial Comment:
System: Raspberry Pi

% uname -a
Linux tinkerbell 3.1.9+ #272 PREEMPT Tue Aug 7 22:51:44 BST 2012 armv6l GNU/Linux
% cat /proc/cpuinfo 
#Processor      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 0002
Serial          : 00000000b096e6b2

The second error I encountered is a missing ariarm.c:
gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard -I/home/cptsalek/local/clisp/src/gllib -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O2 -falign-functions=4 -DENABLE_UNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -c lisparit.c
In file included from lisparit.d:28:0:
arilev1.d:270:26: fatal error: ariarm.c: No such file or directory
compilation terminated.
make: *** [lisparit.o] Error 1

This one can be traced back to a set of definitions and their handling in makemake.

After running configure, makemake contains the following definition:
host='armv6l-unknown-linux-gnueabi'                       # something like 'sparc-sun-sunos4'
host_cpu='armv6l'               # something like 'sparc'
host_cpu_c_abi='armel'   # ditto

In the following block cpu is set to $host_cpu_c_abi, thus containing armel as well:
# Main cpu dependencies:
cpu=$host_cpu_c_abi
if test -z "$cpu"; then
  echo "$0: WARNING: host_cpu_c_abi is void; using host_cpu=${host_cpu}" >&2
  case "$host_cpu" in
    hppa*) cpu=hppa ;;
    arm*)  cpu=arm  ;;
    mips64*) cpu=mips64 ;;
    * ) cpu=${host_cpu}
  esac
fi

But later on, where ARI_ASMD and ARI_ASMS are defined, there is no matching case for "armel", the only case for ARM cpus is the following:
if [ "$cpu" = arm ] ; then
  ARI_ASMD=$ARI_ASMD' ariarm'
  ARI_ASMS=$ARI_ASMS' ariarm'
fi

This probably goes undetected, makemake finishes, but no ariarm.c has been created.

As a workaround I forced host_cpu_c_abi to be ignored for arm by encapsulating cpu=$host_cpu_c_abi in a case statement.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3560795&group_id=1355

[ clisp-Bugs-3560789 ] armv6l/armhf: internal compiler error in intparam.c

[SourceForge.net <no...@so...>]

Bugs item #3560789, was opened at 2012-08-22 13:02
Message generated for change (Tracker Item Submitted) made by cptsalek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3560789&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Walther (cptsalek)
Assigned to: Bruno Haible (haible)
Summary: armv6l/armhf: internal compiler error in intparam.c

Initial Comment:
System is a Raspberry Pi:

% uname -a
Linux tinkerbell 3.1.9+ #272 PREEMPT Tue Aug 7 22:51:44 BST 2012 armv6l GNU/Linux
% cat /proc/cpuinfo 
#Processor      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 0002
Serial          : 00000000b096e6b2


Output from build:
echo '#include "config.h"' > tmp.c
cat 'intparam.c' >> tmp.c
gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard tmp.c -o intparam
tmp.c: In function ‘main5’:
tmp.c:423:1: internal compiler error: in elimination_costs_in_insn, at reload1.c:3633
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccTpy3rO.out file, please attach this to your bugreport.
make: *** [intparam.h] Error 1

I tracked this down to the following two calls:
test_integer_casts(schar,longlong,"char","long long",char_bitsize,longlong_bitsize,2);
test_integer_casts(schar,ulonglong,"char","unsigned long long",char_bitsize,ulonglong_bitsize,2);

Commenting both lines out allowed the build to continue, but of course I'm not sure if there's still a bug around, either related to the platform, the compiler or clisp.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3560789&group_id=1355

[ clisp-Bugs-3555549 ] Segfault for errors signaled inside threads

[SourceForge.net <no...@so...>]

Bugs item #3555549, was opened at 2012-08-08 22:42
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3555549&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: multithreading
Group: segfault
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Segfault for errors signaled inside threads

Initial Comment:
    (loop
       :repeat 16
       :do (mt:make-thread (lambda () (error "foo!"))))
    (sleep 999)

changeset 15591:a54e2c41e396

./configure --with-debug --prefix=/home/jlawrence/usr/stow/clisp-dev-dbg --with-threads=POSIX_THREADS

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

STACK size: 98206 [0xb74c2f00 0xb7463088]
GNU CLISP 2.49+ (2010-07-17) (built 3553466823) (memory 3553466941)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -pthread -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=3 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER
 LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

Sample runs with the above code invoked as a script:

======================

STACK size: 98206 [0xb7527f00 0xb74c8088]
*** - 
*** - Segmentation fault (core dumped)

======================

STACK size: 98206 [0xb74f5f00 0xb7496088]
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - 
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - 
*** - 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>:
    #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>jump    #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>by:

     -8567        jump:  takes byjump  by38 -8567   outsidetakes-8567  [takes 3810


            38      ;outside  outside[37 []10
10;;3737]
]
#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>: jump by -8567 takes 38
*** - 
      outside [
[eval.d:6557] 10;37#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>]
: jump byfoo! 
-8567 takes#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> 38

======================

STACK size: 98206 [0xb74c1f00 0xb7462088]
*** - 
*** - 
[eval.d:6458] 
*** - 

[eval.d:6458] *** - 
[eval.d:6458] 
[eval.d:6458] 
[eval.d:6458] 
*** - 
*** - 
[eval.d:6458] 
*** - 
[eval.d:6458] 
[eval.d:6458] 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - Corrupted STACK inCorrupted
[eval.d:6458]  STACKCorrupted  inSTACK inCLOS::STD-ADD-METHOD
:      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> at byte 26
 #<STANDARD-METHOD PROGN (#<STANDARD-CLASS ERROR>)> already belongs to
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>, cannot also add it to
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>Corrupted STACK infoo!

======================

STACK size: 98206 [0xb7446f00 0xb73e7088]
*** - 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
*** - 
[eval.d:7287] 
*** - 
[eval.d:7287] 
[eval.d:7287] 
*** - 
*** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 
*** - 
*** - 
[eval.d:7287] 
*** - 
*** - 
*** - Corrupted STACK inCorrupted STACK in
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> atCorrupted  STACK inbyte

       #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>     at  byte25 25

foo!

======================

$ ~/usr/stow/clisp-dev-dbg/bin/clisp -norc
STACK size: 98206 [0xb7457f00 0xb73f8088]
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]>     (loop
       :repeat 16
       :do (mt:make-thread (lambda () (error "foo!"))))
NIL
[2]> 
*** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - foo!foo!
Break 1 [1]> foo!
Break 1 [1]> 
Break 1 [1]> foo!
Break 1 [1]> foo!
Break 1 [1]> foo!foo!
Break 1 [1]> foo!foo!
Break 1 [1]> foo!
Break 1 [1]> foo!foo!
foo!Break 1 [1]> 
Break 1 [1]> 
Break 1 [1]> Break 1 [1]> *** glibc detected *** /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run: double free or corruption (fasttop): 0xb4100468 ***

Break 1 [1]> ======= Backtrace: =========
foo!/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xb74cde42]
foo!/lib/i386-linux-gnu/libreadline.so.6(rl_set_prompt+0x32)[0xb764e1e2]
/lib/i386-linux-gnu/libreadline.so.6(readline+0x27)[0xb764f2b7]

Break 1 [1]> /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x8118a34]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(read_line+0xe8)[0x
Break 1 [1]> foo!/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_read_line+0x43)[0x814269b]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x30)[0x80b72ac]

Break 1 [1]> /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x81c3a2b]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_read_eval_print+0xf)[0x81c4c93]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0xba)[0x80b7336]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd071]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_same_env_as+0x45)[0x81c75d1]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0xba)[0x80b7336]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd071]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_driver+0xc4)[0x80d0244]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd212]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_invoke_debugger+0x316)[0x81cd892]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x30)[0x80b72ac]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x81cb1cf]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_defclcs+0x0)[0x81ccc94]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b1e50]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80af99f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(eval+0x1aa)[0x80af3c2]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80ae869]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b9492]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x8236a45]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb7606d4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb7544ace]
======= Memory map: ========
08048000-08312000 r-xp 00000000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08312000-08314000 r-xp 002c9000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08314000-08331000 rwxp 002cb000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08331000-08334000 rwxp 00000000 00:00 0 
09c4f000-09c70000 rwxp 00000000 00:00 0          [heap]
219db000-21ba9000 rwxp 00000000 00:00 0 
685ab000-68676000 rwxp 00000000 00:00 0 
b3d00000-b3d21000 rwxp 00000000 00:00 0 
b3d21000-b3e00000 ---p 00000000 00:00 0 
b3f00000-b3f21000 rwxp 00000000 00:00 0 
b3f21000-b4000000 ---p 00000000 00:00 0 
b4000000-b4021000 rwxp 00000000 00:00 0 
b4021000-b4100000 ---p 00000000 00:00 0 
b4100000-b4121000 rwxp 00000000 00:00 0 
b4121000-b4200000 ---p 00000000 00:00 0 
b4200000-b4221000 rwxp 00000000 00:00 0 
b4221000-b4300000 ---p 00000000 00:00 0 
b4300000-b4321000 rwxp 00000000 00:00 0 
b4321000-b4400000 ---p 00000000 00:00 0 
b4400000-b4421000 rwxp 00000000 00:00 0 
b4421000-b4500000 ---p 00000000 00:00 0 
b4500000-b4521000 rwxp 00000000 00:00 0 
b4521000-b4600000 ---p 00000000 00:00 0 
b4600000-b4621000 rwxp 00000000 00:00 0 
b4621000-b4700000 ---p 00000000 00:00 0 
b4700000-b4721000 rwxp 00000000 00:00 0 
b4721000-b4800000 ---p 00000000 00:00 0 
b4800000-b4821000 rwxp 00000000 00:00 0 
b4821000-b4900000 ---p 00000000 00:00 0 
b4900000-b4921000 rwxp 00000000 00:00 0 
b4921000-b4a00000 ---p 00000000 00:00 0 
b4a00000-b4a21000 rwxp 00000000 00:00 0 
b4a21000-b4b00000 ---p 00000000 00:00 0 
b4b00000-b4b21000 rwxp 00000000 00:00 0 
b4b21000-b4c00000 ---p 00000000 00:00 0 
b4cb0000-b4cb1000 ---p 00000000 00:00 0 
b4cb1000-b4e11000 rwxp 00000000 00:00 0 
b4e11000-b4e12000 ---p 00000000 00:00 0 
b4e12000-b4f72000 rwxp 00000000 00:00 0 
b4f72000-b4f73000 ---p 00000000 00:00 0 
b4f73000-b50d3000 rwxp 00000000 00:00 0 
b50d3000-b50d4000 ---p 00000000 00:00 0 
b50d4000-b5234000 rwxp 00000000 00:00 0 
b5234000-b5235000 ---p 00000000 00:00 0 
b5235000-b5395000 rwxp 00000000 00:00 0 
b5395000-b5396000 ---p 00000000 00:00 0 
b5396000-b54f6000 rwxp 00000000 00:00 0 
b54f6000-b54f7000 ---p 00000000 00:00 0 
b54f7000-b5657000 rwxp 00000000 00:00 0 
b5657000-b5658000 ---p 00000000 00:00 0 
b5658000-b57b8000 rwxp 00000000 00:00 0 
b57b8000-b57b9000 ---p 00000000 00:00 0 
b57b9000-b5919000 rwxp 00000000 00:00 0 
b5919000-b591a000 ---p 00000000 00:00 0 
b591a000-b5a7a000 rwxp 00000000 00:00 0 
b5a7a000-b5a7b000 ---p 00000000 00:00 0 
b5a7b000-b5bdb000 rwxp 00000000 00:00 0 
b5bdb000-b5bdc000 ---p 00000000 00:00 0 
b5bdc000-b5d3c000 rwxp 00000000 00:00 0 
b5d3c000-b5d3d000 ---p 00000000 00:00 0 
b5d3d000-b5e9d000 rwxp 00000000 00:00 0 
b5e9d000-b5e9e000 ---p 00000000 00:00 0 
b5e9e000-b5ffe000 rwxp 00000000 00:00 0 
b5ffe000-b5fff000 ---p 00000000 00:00 0 
b5fff000-b60ff000 rwxp 00000000 00:00 0 
b60ff000-b6100000 ---p 00000000 00:00 0 
b6100000-b6200000 rwxp 00000000 00:00 0 
b6200000-b6225000 rwxp 00000000 00:00 0 
b6225000-b6300000 ---p 00000000 00:00 0 
b6337000-b63f7000 rwxp 00000000 00:00 0 
b63f7000-b63f8000 ---p 00000000 00:00 0 
b63f8000-b745a000 rwxp 00000000 00:00 0 
b745a000-b75f9000 r-xp 00000000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75f9000-b75fb000 r-xp 0019f000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75fb000-b75fc000 rwxp 001a1000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75fc000-b7600000 rwxp 00000000 00:00 0 
b7600000-b7617000 r-xp 00000000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7617000-b7618000 r-xp 00016000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7618000-b7619000 rwxp 00017000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7619000-b761b000 rwxp 00000000 00:00 0 
b761b000-b761d000 r-xp 00000000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761d000-b761e000 r-xp 00001000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761e000-b761f000 rwxp 00002000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761f000-b7622000 r-xp 00000000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7622000-b7623000 r-xp 00002000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7623000-b7624000 rwxp 00003000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7624000-b7640000 r-xp 00000000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7640000-b7642000 r-xp 0001b000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7642000-b7643000 rwxp 0001d000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7643000-b7678000 r-xp 00000000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b7678000-b7679000 r-xp 00035000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b7679000-b767c000 rwxp 00036000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b767c000-b767e000 rwxp 00000000 00:00 0 
b767e000-b7686000 r-xp 00000000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7686000-b7687000 r-xp 00007000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7687000-b7688000 rwxp 00008000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7688000-b76af000 rwxp 00000000 00:00 0 
b76af000-b76d9000 r-xp 00000000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76d9000-b76da000 r-xp 00029000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76da000-b76db000 rwxp 0002a000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76db000-b76f7000 r-xp 00000000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f7000-b76f8000 r-xp 0001b000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f8000-b76f9000 rwxp 0001c000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f9000-b76fd000 rwxp 00000000 00:00 0 
b76fd000-b76fe000 r-xp 00000000 00:00 0          [vdso]
b76fe000-b771e000 r-xp 00000000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
b771e000-b771f000 r-xp 0001f000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
b771f000-b7720000 rwxp 00020000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
bf7e2000-bf803000 rwxp 00000000 00:00 0          [stack]
Abort (core dumped)


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

>Comment By: lmj ()
Date: 2012-08-09 09:52

Message:
With readline removed I no longer get readline-related stack dumps
like above, but otherwise there is no apparent change. Since I gave
only one REPL example, here's a couple more:

=============================

[1]> (loop
:repeat 16
:do (mt:make-thread (lambda () (error "foo!"))))
NIL
[2]> 
** - Continuable Error

*** - 
*** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
** - Continuable Error
INTERN(foo!"SIMPLE-CONDITION-FORMAT-CONTROL-PRELIMINARY-1"):
 #<PACKAGE COMMON-LISP>Break 1 [1]>  is locked
If you continue (by typing 'continue'): foo!
Break 1 [1]> foo!foo!
Break 1 [1]> Ignore the lock and proceed
foo!foo!
Break 1 [1]> foo!foo!foo!
Break 1 [1]> 

Break 1 [1]> Break 1 [1]> 
Break 1 [1]> Break 1 [1]> 
Break 1 [1]> foo!
Break 1 [1]> foo!
Break 1 [1]> foo!
Break 1 [1]> foo!
Break 1 [1]> foo!
Break 1 [1]> foo!
Break 1 [1]>

=============================

[1]> (loop
:repeat 16
:do (mt:make-thread (lambda () (error "foo!"))))
NIL
[2]> 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - foo!foo!foo!
Break 1 [1]> 
Break 1 [1]> 
Break 1 [1]> foo!foo!foo!
Break 1 [1]> 

Break 1 [1]> Break 1 [1]> foo!foo!

Break 1 [1]> Break 1 [1]> foo!foo!foo!
Break 1 [1]> foo!foo!
Break 1 [1]> 
Break 1 [1]> Break 1 [1]> 
Break 1 [1]> foo!foo!
Break 1 [1]> 
Break 1 [1]> INTERN("CLASS-FINALIZED-P-PRELIMINARY-1"): #<PACKAGE CLOS> is
locked
Break 1 [1]>


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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-08-09 06:14

Message:
I cannot reproduce this on x86_64 Linux, OSX and i386 Linux.
Can you try the test without readline support (though I've already done
this without experiencing the problem)?

You've reported also #3545905 which I was not able to reproduce as well. 
Can anybody else run the same tests and share the results? 


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3555549&group_id=1355

[ clisp-Bugs-3555549 ] Segfault for errors signaled inside threads

[SourceForge.net <no...@so...>]

Bugs item #3555549, was opened at 2012-08-08 22:42
Message generated for change (Comment added) made by vtz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3555549&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: multithreading
Group: segfault
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Segfault for errors signaled inside threads

Initial Comment:
    (loop
       :repeat 16
       :do (mt:make-thread (lambda () (error "foo!"))))
    (sleep 999)

changeset 15591:a54e2c41e396

./configure --with-debug --prefix=/home/jlawrence/usr/stow/clisp-dev-dbg --with-threads=POSIX_THREADS

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

STACK size: 98206 [0xb74c2f00 0xb7463088]
GNU CLISP 2.49+ (2010-07-17) (built 3553466823) (memory 3553466941)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -pthread -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=3 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER
 LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

Sample runs with the above code invoked as a script:

======================

STACK size: 98206 [0xb7527f00 0xb74c8088]
*** - 
*** - Segmentation fault (core dumped)

======================

STACK size: 98206 [0xb74f5f00 0xb7496088]
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - 
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - 
*** - 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>:
    #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>jump    #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>by:

     -8567        jump:  takes byjump  by38 -8567   outsidetakes-8567  [takes 3810


            38      ;outside  outside[37 []10
10;;3737]
]
#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>: jump by -8567 takes 38
*** - 
      outside [
[eval.d:6557] 10;37#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>]
: jump byfoo! 
-8567 takes#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> 38

======================

STACK size: 98206 [0xb74c1f00 0xb7462088]
*** - 
*** - 
[eval.d:6458] 
*** - 

[eval.d:6458] *** - 
[eval.d:6458] 
[eval.d:6458] 
[eval.d:6458] 
*** - 
*** - 
[eval.d:6458] 
*** - 
[eval.d:6458] 
[eval.d:6458] 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - Corrupted STACK inCorrupted
[eval.d:6458]  STACKCorrupted  inSTACK inCLOS::STD-ADD-METHOD
:      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> at byte 26
 #<STANDARD-METHOD PROGN (#<STANDARD-CLASS ERROR>)> already belongs to
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>, cannot also add it to
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>Corrupted STACK infoo!

======================

STACK size: 98206 [0xb7446f00 0xb73e7088]
*** - 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
*** - 
[eval.d:7287] 
*** - 
[eval.d:7287] 
[eval.d:7287] 
*** - 
*** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 
*** - 
*** - 
[eval.d:7287] 
*** - 
*** - 
*** - Corrupted STACK inCorrupted STACK in
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> atCorrupted  STACK inbyte

       #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>     at  byte25 25

foo!

======================

$ ~/usr/stow/clisp-dev-dbg/bin/clisp -norc
STACK size: 98206 [0xb7457f00 0xb73f8088]
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]>     (loop
       :repeat 16
       :do (mt:make-thread (lambda () (error "foo!"))))
NIL
[2]> 
*** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - foo!foo!
Break 1 [1]> foo!
Break 1 [1]> 
Break 1 [1]> foo!
Break 1 [1]> foo!
Break 1 [1]> foo!foo!
Break 1 [1]> foo!foo!
Break 1 [1]> foo!
Break 1 [1]> foo!foo!
foo!Break 1 [1]> 
Break 1 [1]> 
Break 1 [1]> Break 1 [1]> *** glibc detected *** /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run: double free or corruption (fasttop): 0xb4100468 ***

Break 1 [1]> ======= Backtrace: =========
foo!/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xb74cde42]
foo!/lib/i386-linux-gnu/libreadline.so.6(rl_set_prompt+0x32)[0xb764e1e2]
/lib/i386-linux-gnu/libreadline.so.6(readline+0x27)[0xb764f2b7]

Break 1 [1]> /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x8118a34]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(read_line+0xe8)[0x
Break 1 [1]> foo!/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_read_line+0x43)[0x814269b]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x30)[0x80b72ac]

Break 1 [1]> /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x81c3a2b]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_read_eval_print+0xf)[0x81c4c93]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0xba)[0x80b7336]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd071]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_same_env_as+0x45)[0x81c75d1]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0xba)[0x80b7336]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd071]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_driver+0xc4)[0x80d0244]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd212]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_invoke_debugger+0x316)[0x81cd892]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x30)[0x80b72ac]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x81cb1cf]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_defclcs+0x0)[0x81ccc94]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b1e50]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80af99f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(eval+0x1aa)[0x80af3c2]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80ae869]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b9492]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x8236a45]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb7606d4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb7544ace]
======= Memory map: ========
08048000-08312000 r-xp 00000000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08312000-08314000 r-xp 002c9000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08314000-08331000 rwxp 002cb000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08331000-08334000 rwxp 00000000 00:00 0 
09c4f000-09c70000 rwxp 00000000 00:00 0          [heap]
219db000-21ba9000 rwxp 00000000 00:00 0 
685ab000-68676000 rwxp 00000000 00:00 0 
b3d00000-b3d21000 rwxp 00000000 00:00 0 
b3d21000-b3e00000 ---p 00000000 00:00 0 
b3f00000-b3f21000 rwxp 00000000 00:00 0 
b3f21000-b4000000 ---p 00000000 00:00 0 
b4000000-b4021000 rwxp 00000000 00:00 0 
b4021000-b4100000 ---p 00000000 00:00 0 
b4100000-b4121000 rwxp 00000000 00:00 0 
b4121000-b4200000 ---p 00000000 00:00 0 
b4200000-b4221000 rwxp 00000000 00:00 0 
b4221000-b4300000 ---p 00000000 00:00 0 
b4300000-b4321000 rwxp 00000000 00:00 0 
b4321000-b4400000 ---p 00000000 00:00 0 
b4400000-b4421000 rwxp 00000000 00:00 0 
b4421000-b4500000 ---p 00000000 00:00 0 
b4500000-b4521000 rwxp 00000000 00:00 0 
b4521000-b4600000 ---p 00000000 00:00 0 
b4600000-b4621000 rwxp 00000000 00:00 0 
b4621000-b4700000 ---p 00000000 00:00 0 
b4700000-b4721000 rwxp 00000000 00:00 0 
b4721000-b4800000 ---p 00000000 00:00 0 
b4800000-b4821000 rwxp 00000000 00:00 0 
b4821000-b4900000 ---p 00000000 00:00 0 
b4900000-b4921000 rwxp 00000000 00:00 0 
b4921000-b4a00000 ---p 00000000 00:00 0 
b4a00000-b4a21000 rwxp 00000000 00:00 0 
b4a21000-b4b00000 ---p 00000000 00:00 0 
b4b00000-b4b21000 rwxp 00000000 00:00 0 
b4b21000-b4c00000 ---p 00000000 00:00 0 
b4cb0000-b4cb1000 ---p 00000000 00:00 0 
b4cb1000-b4e11000 rwxp 00000000 00:00 0 
b4e11000-b4e12000 ---p 00000000 00:00 0 
b4e12000-b4f72000 rwxp 00000000 00:00 0 
b4f72000-b4f73000 ---p 00000000 00:00 0 
b4f73000-b50d3000 rwxp 00000000 00:00 0 
b50d3000-b50d4000 ---p 00000000 00:00 0 
b50d4000-b5234000 rwxp 00000000 00:00 0 
b5234000-b5235000 ---p 00000000 00:00 0 
b5235000-b5395000 rwxp 00000000 00:00 0 
b5395000-b5396000 ---p 00000000 00:00 0 
b5396000-b54f6000 rwxp 00000000 00:00 0 
b54f6000-b54f7000 ---p 00000000 00:00 0 
b54f7000-b5657000 rwxp 00000000 00:00 0 
b5657000-b5658000 ---p 00000000 00:00 0 
b5658000-b57b8000 rwxp 00000000 00:00 0 
b57b8000-b57b9000 ---p 00000000 00:00 0 
b57b9000-b5919000 rwxp 00000000 00:00 0 
b5919000-b591a000 ---p 00000000 00:00 0 
b591a000-b5a7a000 rwxp 00000000 00:00 0 
b5a7a000-b5a7b000 ---p 00000000 00:00 0 
b5a7b000-b5bdb000 rwxp 00000000 00:00 0 
b5bdb000-b5bdc000 ---p 00000000 00:00 0 
b5bdc000-b5d3c000 rwxp 00000000 00:00 0 
b5d3c000-b5d3d000 ---p 00000000 00:00 0 
b5d3d000-b5e9d000 rwxp 00000000 00:00 0 
b5e9d000-b5e9e000 ---p 00000000 00:00 0 
b5e9e000-b5ffe000 rwxp 00000000 00:00 0 
b5ffe000-b5fff000 ---p 00000000 00:00 0 
b5fff000-b60ff000 rwxp 00000000 00:00 0 
b60ff000-b6100000 ---p 00000000 00:00 0 
b6100000-b6200000 rwxp 00000000 00:00 0 
b6200000-b6225000 rwxp 00000000 00:00 0 
b6225000-b6300000 ---p 00000000 00:00 0 
b6337000-b63f7000 rwxp 00000000 00:00 0 
b63f7000-b63f8000 ---p 00000000 00:00 0 
b63f8000-b745a000 rwxp 00000000 00:00 0 
b745a000-b75f9000 r-xp 00000000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75f9000-b75fb000 r-xp 0019f000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75fb000-b75fc000 rwxp 001a1000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75fc000-b7600000 rwxp 00000000 00:00 0 
b7600000-b7617000 r-xp 00000000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7617000-b7618000 r-xp 00016000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7618000-b7619000 rwxp 00017000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7619000-b761b000 rwxp 00000000 00:00 0 
b761b000-b761d000 r-xp 00000000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761d000-b761e000 r-xp 00001000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761e000-b761f000 rwxp 00002000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761f000-b7622000 r-xp 00000000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7622000-b7623000 r-xp 00002000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7623000-b7624000 rwxp 00003000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7624000-b7640000 r-xp 00000000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7640000-b7642000 r-xp 0001b000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7642000-b7643000 rwxp 0001d000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7643000-b7678000 r-xp 00000000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b7678000-b7679000 r-xp 00035000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b7679000-b767c000 rwxp 00036000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b767c000-b767e000 rwxp 00000000 00:00 0 
b767e000-b7686000 r-xp 00000000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7686000-b7687000 r-xp 00007000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7687000-b7688000 rwxp 00008000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7688000-b76af000 rwxp 00000000 00:00 0 
b76af000-b76d9000 r-xp 00000000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76d9000-b76da000 r-xp 00029000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76da000-b76db000 rwxp 0002a000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76db000-b76f7000 r-xp 00000000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f7000-b76f8000 r-xp 0001b000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f8000-b76f9000 rwxp 0001c000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f9000-b76fd000 rwxp 00000000 00:00 0 
b76fd000-b76fe000 r-xp 00000000 00:00 0          [vdso]
b76fe000-b771e000 r-xp 00000000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
b771e000-b771f000 r-xp 0001f000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
b771f000-b7720000 rwxp 00020000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
bf7e2000-bf803000 rwxp 00000000 00:00 0          [stack]
Abort (core dumped)


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

>Comment By: Vladimir Tzankov (vtz)
Date: 2012-08-09 06:14

Message:
I cannot reproduce this on x86_64 Linux, OSX and i386 Linux.
Can you try the test without readline support (though I've already done
this without experiencing the problem)?

You've reported also #3545905 which I was not able to reproduce as well. 
Can anybody else run the same tests and share the results? 


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3555549&group_id=1355

[ clisp-Bugs-3555549 ] Segfault for errors signaled inside threads

[SourceForge.net <no...@so...>]

Bugs item #3555549, was opened at 2012-08-08 22:42
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3555549&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: multithreading
Group: segfault
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Segfault for errors signaled inside threads

Initial Comment:
    (loop
       :repeat 16
       :do (mt:make-thread (lambda () (error "foo!"))))
    (sleep 999)

changeset 15591:a54e2c41e396

./configure --with-debug --prefix=/home/jlawrence/usr/stow/clisp-dev-dbg --with-threads=POSIX_THREADS

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

STACK size: 98206 [0xb74c2f00 0xb7463088]
GNU CLISP 2.49+ (2010-07-17) (built 3553466823) (memory 3553466941)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -falign-functions=4 -pthread -g -O0 -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=3 HEAPCODES LINUX_NOEXEC_HEAPCODES SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER
 LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

Sample runs with the above code invoked as a script:

======================

STACK size: 98206 [0xb7527f00 0xb74c8088]
*** - 
*** - Segmentation fault (core dumped)

======================

STACK size: 98206 [0xb74f5f00 0xb7496088]
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - 
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - 
*** - 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
*** - 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
[eval.d:6557] 
*** - 
*** - #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>:
    #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>jump    #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>by:

     -8567        jump:  takes byjump  by38 -8567   outsidetakes-8567  [takes 3810


            38      ;outside  outside[37 []10
10;;3737]
]
#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>: jump by -8567 takes 38
*** - 
      outside [
[eval.d:6557] 10;37#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>]
: jump byfoo! 
-8567 takes#<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> 38

======================

STACK size: 98206 [0xb74c1f00 0xb7462088]
*** - 
*** - 
[eval.d:6458] 
*** - 

[eval.d:6458] *** - 
[eval.d:6458] 
[eval.d:6458] 
[eval.d:6458] 
*** - 
*** - 
[eval.d:6458] 
*** - 
[eval.d:6458] 
[eval.d:6458] 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - Corrupted STACK inCorrupted
[eval.d:6458]  STACKCorrupted  inSTACK inCLOS::STD-ADD-METHOD
:      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> at byte 26
 #<STANDARD-METHOD PROGN (#<STANDARD-CLASS ERROR>)> already belongs to
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>, cannot also add it to
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>Corrupted STACK infoo!

======================

STACK size: 98206 [0xb7446f00 0xb73e7088]
*** - 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
[eval.d:7287] 
*** - 
[eval.d:7287] 
*** - 
[eval.d:7287] 
[eval.d:7287] 
*** - 
*** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 
*** - 
*** - 
[eval.d:7287] 
*** - 
*** - 
*** - Corrupted STACK inCorrupted STACK in
      #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER> atCorrupted  STACK inbyte

       #<STANDARD-GENERIC-FUNCTION SYSTEM::GLOBAL-HANDLER>     at  byte25 25

foo!

======================

$ ~/usr/stow/clisp-dev-dbg/bin/clisp -norc
STACK size: 98206 [0xb7457f00 0xb73f8088]
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
  I I I I I I I      8     8   8           8     8     o  8    8
  I  \ `+' /  I      8         8           8     8        8    8
   \  `-+-'  /       8         8           8      ooooo   8oooo
    `-__|__-'        8         8           8           8  8
        |            8     o   8           8     o     8  8
  ------+------       ooooo    8oooooo  ooo8ooo   ooooo   8

Welcome to GNU CLISP 2.49+ (2010-07-17) <http://clisp.org/>

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2010

Type :h and hit Enter for context help.

[1]>     (loop
       :repeat 16
       :do (mt:make-thread (lambda () (error "foo!"))))
NIL
[2]> 
*** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 

*** - *** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - 
*** - foo!foo!
Break 1 [1]> foo!
Break 1 [1]> 
Break 1 [1]> foo!
Break 1 [1]> foo!
Break 1 [1]> foo!foo!
Break 1 [1]> foo!foo!
Break 1 [1]> foo!
Break 1 [1]> foo!foo!
foo!Break 1 [1]> 
Break 1 [1]> 
Break 1 [1]> Break 1 [1]> *** glibc detected *** /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run: double free or corruption (fasttop): 0xb4100468 ***

Break 1 [1]> ======= Backtrace: =========
foo!/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xb74cde42]
foo!/lib/i386-linux-gnu/libreadline.so.6(rl_set_prompt+0x32)[0xb764e1e2]
/lib/i386-linux-gnu/libreadline.so.6(readline+0x27)[0xb764f2b7]

Break 1 [1]> /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x8118a34]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(read_line+0xe8)[0x
Break 1 [1]> foo!/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_read_line+0x43)[0x814269b]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x30)[0x80b72ac]

Break 1 [1]> /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x81c3a2b]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_read_eval_print+0xf)[0x81c4c93]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0xba)[0x80b7336]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd071]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_same_env_as+0x45)[0x81c75d1]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0xba)[0x80b7336]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd071]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_driver+0xc4)[0x80d0244]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80bd212]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b932c]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_invoke_debugger+0x316)[0x81cd892]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b810f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x30)[0x80b72ac]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x81cb1cf]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(C_defclcs+0x0)[0x81ccc94]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b1e50]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80af99f]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(eval+0x1aa)[0x80af3c2]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80ae869]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x80b9492]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run(funcall+0x5f)[0x80b72db]
/home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run[0x8236a45]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb7606d4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb7544ace]
======= Memory map: ========
08048000-08312000 r-xp 00000000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08312000-08314000 r-xp 002c9000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08314000-08331000 rwxp 002cb000 08:01 97916461   /home/jlawrence/usr/stow/clisp-dev-dbg/lib/clisp-2.49+/base/lisp.run
08331000-08334000 rwxp 00000000 00:00 0 
09c4f000-09c70000 rwxp 00000000 00:00 0          [heap]
219db000-21ba9000 rwxp 00000000 00:00 0 
685ab000-68676000 rwxp 00000000 00:00 0 
b3d00000-b3d21000 rwxp 00000000 00:00 0 
b3d21000-b3e00000 ---p 00000000 00:00 0 
b3f00000-b3f21000 rwxp 00000000 00:00 0 
b3f21000-b4000000 ---p 00000000 00:00 0 
b4000000-b4021000 rwxp 00000000 00:00 0 
b4021000-b4100000 ---p 00000000 00:00 0 
b4100000-b4121000 rwxp 00000000 00:00 0 
b4121000-b4200000 ---p 00000000 00:00 0 
b4200000-b4221000 rwxp 00000000 00:00 0 
b4221000-b4300000 ---p 00000000 00:00 0 
b4300000-b4321000 rwxp 00000000 00:00 0 
b4321000-b4400000 ---p 00000000 00:00 0 
b4400000-b4421000 rwxp 00000000 00:00 0 
b4421000-b4500000 ---p 00000000 00:00 0 
b4500000-b4521000 rwxp 00000000 00:00 0 
b4521000-b4600000 ---p 00000000 00:00 0 
b4600000-b4621000 rwxp 00000000 00:00 0 
b4621000-b4700000 ---p 00000000 00:00 0 
b4700000-b4721000 rwxp 00000000 00:00 0 
b4721000-b4800000 ---p 00000000 00:00 0 
b4800000-b4821000 rwxp 00000000 00:00 0 
b4821000-b4900000 ---p 00000000 00:00 0 
b4900000-b4921000 rwxp 00000000 00:00 0 
b4921000-b4a00000 ---p 00000000 00:00 0 
b4a00000-b4a21000 rwxp 00000000 00:00 0 
b4a21000-b4b00000 ---p 00000000 00:00 0 
b4b00000-b4b21000 rwxp 00000000 00:00 0 
b4b21000-b4c00000 ---p 00000000 00:00 0 
b4cb0000-b4cb1000 ---p 00000000 00:00 0 
b4cb1000-b4e11000 rwxp 00000000 00:00 0 
b4e11000-b4e12000 ---p 00000000 00:00 0 
b4e12000-b4f72000 rwxp 00000000 00:00 0 
b4f72000-b4f73000 ---p 00000000 00:00 0 
b4f73000-b50d3000 rwxp 00000000 00:00 0 
b50d3000-b50d4000 ---p 00000000 00:00 0 
b50d4000-b5234000 rwxp 00000000 00:00 0 
b5234000-b5235000 ---p 00000000 00:00 0 
b5235000-b5395000 rwxp 00000000 00:00 0 
b5395000-b5396000 ---p 00000000 00:00 0 
b5396000-b54f6000 rwxp 00000000 00:00 0 
b54f6000-b54f7000 ---p 00000000 00:00 0 
b54f7000-b5657000 rwxp 00000000 00:00 0 
b5657000-b5658000 ---p 00000000 00:00 0 
b5658000-b57b8000 rwxp 00000000 00:00 0 
b57b8000-b57b9000 ---p 00000000 00:00 0 
b57b9000-b5919000 rwxp 00000000 00:00 0 
b5919000-b591a000 ---p 00000000 00:00 0 
b591a000-b5a7a000 rwxp 00000000 00:00 0 
b5a7a000-b5a7b000 ---p 00000000 00:00 0 
b5a7b000-b5bdb000 rwxp 00000000 00:00 0 
b5bdb000-b5bdc000 ---p 00000000 00:00 0 
b5bdc000-b5d3c000 rwxp 00000000 00:00 0 
b5d3c000-b5d3d000 ---p 00000000 00:00 0 
b5d3d000-b5e9d000 rwxp 00000000 00:00 0 
b5e9d000-b5e9e000 ---p 00000000 00:00 0 
b5e9e000-b5ffe000 rwxp 00000000 00:00 0 
b5ffe000-b5fff000 ---p 00000000 00:00 0 
b5fff000-b60ff000 rwxp 00000000 00:00 0 
b60ff000-b6100000 ---p 00000000 00:00 0 
b6100000-b6200000 rwxp 00000000 00:00 0 
b6200000-b6225000 rwxp 00000000 00:00 0 
b6225000-b6300000 ---p 00000000 00:00 0 
b6337000-b63f7000 rwxp 00000000 00:00 0 
b63f7000-b63f8000 ---p 00000000 00:00 0 
b63f8000-b745a000 rwxp 00000000 00:00 0 
b745a000-b75f9000 r-xp 00000000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75f9000-b75fb000 r-xp 0019f000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75fb000-b75fc000 rwxp 001a1000 08:01 62915487   /lib/i386-linux-gnu/libc-2.15.so
b75fc000-b7600000 rwxp 00000000 00:00 0 
b7600000-b7617000 r-xp 00000000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7617000-b7618000 r-xp 00016000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7618000-b7619000 rwxp 00017000 08:01 62915567   /lib/i386-linux-gnu/libpthread-2.15.so
b7619000-b761b000 rwxp 00000000 00:00 0 
b761b000-b761d000 r-xp 00000000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761d000-b761e000 r-xp 00001000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761e000-b761f000 rwxp 00002000 08:01 52700192   /usr/lib/libsigsegv.so.2.0.2
b761f000-b7622000 r-xp 00000000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7622000-b7623000 r-xp 00002000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7623000-b7624000 rwxp 00003000 08:01 62915500   /lib/i386-linux-gnu/libdl-2.15.so
b7624000-b7640000 r-xp 00000000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7640000-b7642000 r-xp 0001b000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7642000-b7643000 rwxp 0001d000 08:01 62915584   /lib/i386-linux-gnu/libtinfo.so.5.9
b7643000-b7678000 r-xp 00000000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b7678000-b7679000 r-xp 00035000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b7679000-b767c000 rwxp 00036000 08:01 62915570   /lib/i386-linux-gnu/libreadline.so.6.2
b767c000-b767e000 rwxp 00000000 00:00 0 
b767e000-b7686000 r-xp 00000000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7686000-b7687000 r-xp 00007000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7687000-b7688000 rwxp 00008000 08:01 62915495   /lib/i386-linux-gnu/libcrypt-2.15.so
b7688000-b76af000 rwxp 00000000 00:00 0 
b76af000-b76d9000 r-xp 00000000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76d9000-b76da000 r-xp 00029000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76da000-b76db000 rwxp 0002a000 08:01 62915519   /lib/i386-linux-gnu/libm-2.15.so
b76db000-b76f7000 r-xp 00000000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f7000-b76f8000 r-xp 0001b000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f8000-b76f9000 rwxp 0001c000 08:01 62915508   /lib/i386-linux-gnu/libgcc_s.so.1
b76f9000-b76fd000 rwxp 00000000 00:00 0 
b76fd000-b76fe000 r-xp 00000000 00:00 0          [vdso]
b76fe000-b771e000 r-xp 00000000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
b771e000-b771f000 r-xp 0001f000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
b771f000-b7720000 rwxp 00020000 08:01 62915467   /lib/i386-linux-gnu/ld-2.15.so
bf7e2000-bf803000 rwxp 00000000 00:00 0          [stack]
Abort (core dumped)


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3555549&group_id=1355

[ clisp-Bugs-3554023 ] special operators without a corresponding macro definition.

[SourceForge.net <no...@so...>]

Bugs item #3554023, was opened at 2012-08-03 06:43
Message generated for change (Tracker Item Submitted) made by informatimago
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3554023&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pascal J. Bourguignon (informatimago)
Assigned to: Bruno Haible (haible)
Summary: special operators without a corresponding macro definition.

Initial Comment:


The following special operators don't have a corresponding macro definition.

EXT:COMPILER-LET
 SYSTEM::FUNCTION-MACRO-LET

While the standard doesn't specify anything for special operators not in the CL package, it would still be nice if they followed the same rule as for CL macros implemented as special operators:

3.1.2.1.2.2 Macro Forms
An implementation is free to implement any macro operator as a special operator, 
but only if an equivalent definition of the macro is also provided. 

since this would ensure that portable code walkers can be written.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3554023&group_id=1355

[ clisp-Bugs-3552396 ] clisp's Cursor Hides in Win32?

[SourceForge.net <no...@so...>]

Bugs item #3552396, was opened at 2012-07-30 21:58
Message generated for change (Tracker Item Submitted) made by zunhuakq
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3552396&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kang Qiao (zunhuakq)
Assigned to: Bruno Haible (haible)
Summary: clisp's Cursor Hides in Win32?

Initial Comment:
In win32,when I type lisp expressions in clisp command line,the cursor always hides.
When i move the cursor by arrow keys , it hides too.
It's also a problem that keys like Home,End,Delete can't be used.

My clisp version is 2.49.And it runs without any Linux emulator such as Cygwin.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3552396&group_id=1355

Re: terminating clisp: clisp.exe vs lisp.exe

[Anton V. <avo...@ya...>]

29.06.2012, 06:32, "Sam Steingold" <sd...@gn...>:
>
> it's a joke, not a penalty.

I know. I wanted to try villages. 

My promise keeps valid - from now on you have right
to have my answer onto a single technical question. 
You can transfer this right to anyone else in exchange
to anything he agrees to do for you (house cleaning, hard
work on CLISP documentation, whatever).

Best regards,
- Anton

[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

[SourceForge.net <no...@so...>]

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

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

Comment By: lmj ()
Date: 2012-07-20 05:03

Message:
I'm not sure I understand your point. The standard draws a distinction
between a REPL process and other processes.

"Typically, in an interactive listener, the invocation of abort returns to
the Lisp reader phase of the Lisp read-eval-print loop, though in some
batch or multi-processing situations there may be situations in which
having it kill the running process is more appropriate."
http://clhs.lisp.se/Body/r_abort.htm

So the main REPL thread is already doing what the standard suggests.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 03:28

Message:
Currently we throw special tag in the context of the thread in order to
cause it to exit - I can replace this with abort restart.
However what to do with the "main" thread - should we do the same? It is
not good to treat it specially.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

[ clisp-Bugs-3545905 ] Hang with exemption

[SourceForge.net <no...@so...>]

Bugs item #3545905, was opened at 2012-07-19 08:29
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: multithreading
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Hang with exemption

Initial Comment:
The following RUN function eventually hangs for both the latest build (15589) and clisp-2.49.

(defstruct sema
  (count 0)
  (lock (mt:make-mutex))
  (cvar (mt:make-exemption)))

(defun inc-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (incf (sema-count sema))
    (mt:exemption-signal (sema-cvar sema))))

(defun dec-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (loop (cond ((plusp (sema-count sema))
                 (decf (sema-count sema))
                 (return))
                (t
                 (mt:exemption-wait
                  (sema-cvar sema) (sema-lock sema)))))))

(defun test (thread-count)
  (let ((from-threads (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda () (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (dec-sema from-threads))))

(defun run ()
  (loop
     (test 16)
     (format t ".")
     (finish-output)))

Sometimes the outcome with the latest build is:

Internal error: statement in file "zthread.d", line 771 has been reached!!

The number of iterations until hanging tends to decrease as thread-count increases.

The following replacement for TEST should also be checked (it has exposed bugs in other CL implementations where the previous TEST did not).

(defun test (thread-count)
  (let ((from-threads (make-sema))
        (to-threads   (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda ()
            (dec-sema to-threads)
            (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (inc-sema to-threads))
    (loop repeat thread-count do (dec-sema from-threads))))

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

GNU CLISP 2.49+ (2010-07-17) (built 3551638844) (memory 3551639097)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL
 INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE
 BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

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

>Comment By: lmj ()
Date: 2012-07-20 03:35

Message:
I have just discovered that the problem goes away when clisp is
configured --with-debug.

My only configure options are --prefix and --with-threads=POSIX_THREADS.

For me it fails within seconds for either TEST. This is a Core i7
3.4GHz running 32-bit Linux.

I have been compiling all functions. It takes longer for the issue to
appear with interpreted functions, though it still fails within a few
minutes at most.

I recently got a new error while running interpreted functions:

*** thread is going into lisp land without calling end_blocking_call()

On SBCL I once had a condition variable problem which was either
wholly present or wholly absent depending upon some dice roll at
launch time. (The SBCL bundled with Ubuntu sometimes (but not always)
decided to produce spurious wakeups, which I had not handled properly.
This caused some confusion because a vanilla SBCL compiled locally did
not generate these wakeups.) Perhaps not seeing the issue after a
couple minutes means a restart is needed.

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

Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 00:27

Message:
I can't reproduce it (tested both on Linux and OSX).
I used up to 128 threads and waited about 5 minutes on each run. Also
tested the second 'test' function without experiencing problems. 

Reaching zthread.d:771 means inconsistency in internal mutex record.
Will continue to test - any additional info (though not sure what to ask
for - debugging is an option but it's not easy one) will be helpful.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

[SourceForge.net <no...@so...>]

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Comment added) made by vtz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

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

>Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 03:28

Message:
Currently we throw special tag in the context of the thread in order to
cause it to exit - I can replace this with abort restart.
However what to do with the "main" thread - should we do the same? It is
not good to treat it specially.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

[ clisp-Bugs-3545905 ] Hang with exemption

[SourceForge.net <no...@so...>]

Bugs item #3545905, was opened at 2012-07-19 08:29
Message generated for change (Comment added) made by vtz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: multithreading
Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Vladimir Tzankov (vtz)
Summary: Hang with exemption

Initial Comment:
The following RUN function eventually hangs for both the latest build (15589) and clisp-2.49.

(defstruct sema
  (count 0)
  (lock (mt:make-mutex))
  (cvar (mt:make-exemption)))

(defun inc-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (incf (sema-count sema))
    (mt:exemption-signal (sema-cvar sema))))

(defun dec-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (loop (cond ((plusp (sema-count sema))
                 (decf (sema-count sema))
                 (return))
                (t
                 (mt:exemption-wait
                  (sema-cvar sema) (sema-lock sema)))))))

(defun test (thread-count)
  (let ((from-threads (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda () (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (dec-sema from-threads))))

(defun run ()
  (loop
     (test 16)
     (format t ".")
     (finish-output)))

Sometimes the outcome with the latest build is:

Internal error: statement in file "zthread.d", line 771 has been reached!!

The number of iterations until hanging tends to decrease as thread-count increases.

The following replacement for TEST should also be checked (it has exposed bugs in other CL implementations where the previous TEST did not).

(defun test (thread-count)
  (let ((from-threads (make-sema))
        (to-threads   (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda ()
            (dec-sema to-threads)
            (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (inc-sema to-threads))
    (loop repeat thread-count do (dec-sema from-threads))))

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

GNU CLISP 2.49+ (2010-07-17) (built 3551638844) (memory 3551639097)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL
 INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE
 BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

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

>Comment By: Vladimir Tzankov (vtz)
Date: 2012-07-20 00:27

Message:
I can't reproduce it (tested both on Linux and OSX).
I used up to 128 threads and waited about 5 minutes on each run. Also
tested the second 'test' function without experiencing problems. 

Reaching zthread.d:771 means inconsistency in internal mutex record.
Will continue to test - any additional info (though not sure what to ask
for - debugging is an option but it's not easy one) will be helpful.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

[SourceForge.net <no...@so...>]

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: UI
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
>Assigned to: Vladimir Tzankov (vtz)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

[ clisp-Feature Requests-3545986 ] Add ABORT restart to threads

[SourceForge.net <no...@so...>]

Feature Requests item #3545986, was opened at 2012-07-19 11:03
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Add ABORT restart to threads

Initial Comment:
* "Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time ... in some batch or multi-processing situations there may be situations in which having it kill the running process is more appropriate." http://clhs.lisp.se/Body/r_abort.htm

* There's nothing to do inside the debugger with no restarts; the 'a' key in SLIME doesn't work.

* Since bordeaux-threads does not permit a thread to kill itself, there is no implementation-neutral way of self-terminating a thread outside of invoking ABORT (or establishing some other restart beforehand).

* User code which has already added an ABORT restart is OK, since the user's ABORT will hide the new topmost ABORT.

* Peer pressure: these implementations define ABORT inside threads: ABCL, Allegro, Clozure, ECL, LispWorks, SBCL.

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=3545986&group_id=1355

[ clisp-Bugs-3545905 ] Hang with exemption

[SourceForge.net <no...@so...>]

Bugs item #3545905, was opened at 2012-07-19 08:29
Message generated for change (Settings changed) made by sds
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: multithreading
>Group: lisp error
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lmj ()
>Assigned to: Vladimir Tzankov (vtz)
Summary: Hang with exemption

Initial Comment:
The following RUN function eventually hangs for both the latest build (15589) and clisp-2.49.

(defstruct sema
  (count 0)
  (lock (mt:make-mutex))
  (cvar (mt:make-exemption)))

(defun inc-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (incf (sema-count sema))
    (mt:exemption-signal (sema-cvar sema))))

(defun dec-sema (sema)
  (mt:with-mutex-lock ((sema-lock sema))
    (loop (cond ((plusp (sema-count sema))
                 (decf (sema-count sema))
                 (return))
                (t
                 (mt:exemption-wait
                  (sema-cvar sema) (sema-lock sema)))))))

(defun test (thread-count)
  (let ((from-threads (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda () (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (dec-sema from-threads))))

(defun run ()
  (loop
     (test 16)
     (format t ".")
     (finish-output)))

Sometimes the outcome with the latest build is:

Internal error: statement in file "zthread.d", line 771 has been reached!!

The number of iterations until hanging tends to decrease as thread-count increases.

The following replacement for TEST should also be checked (it has exposed bugs in other CL implementations where the previous TEST did not).

(defun test (thread-count)
  (let ((from-threads (make-sema))
        (to-threads   (make-sema)))
    (loop repeat thread-count do
         (mt:make-thread
          (lambda ()
            (dec-sema to-threads)
            (inc-sema from-threads))
          :name "test"))
    (loop repeat thread-count do (inc-sema to-threads))
    (loop repeat thread-count do (dec-sema from-threads))))

Linux xi 3.2.0-24-generic-pae #39-Ubuntu SMP Mon May 21 18:54:21 UTC 2012 i686 i686 i386 GNU/Linux

gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 

GNU CLISP 2.49+ (2010-07-17) (built 3551638844) (memory 3551639097)
Software: GNU C 4.6.3 
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith -Wreturn-type -Wmissing-declarations -Wimplicit -Wno-sign-compare -Wno-format-nonliteral -O2 -fexpensive-optimizations -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS -DDYNAMIC_MODULES  libgnu.a  -lreadline -lncurses -ldl   -lsigsegv  
SAFETY=0 HEAPCODES LINUX_NOEXEC_HEAPCODES GENERATIONAL_GC SPVW_BLOCKS SPVW_MIXED TRIVIALMAP_MEMORY
libsigsegv 2.9
libreadline 6.2
Features: 
(REGEXP WILDCARD SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL
 INTERPRETER LOGICAL-PATHNAMES MT SOCKETS GENERIC-STREAMS SCREEN GETTEXT UNICODE
 BASE-CHAR=CHARACTER PC386 UNIX)
C Modules: (clisp i18n syscalls regexp)
Installation directory: /home/jlawrence/usr/stow/clisp-dev/lib/clisp-2.49+/
User language: ENGLISH
Machine: I686 (I686) xi [127.0.1.1]

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3545905&group_id=1355