Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


sbcl Log

Commit Date  
[fdb3f2] (sbcl_1_0_26) by Christophe Rhodes Christophe Rhodes

1.0.26: release, will be tagged as sbcl_1_0_26

2009-03-01 21:49:12 Tree
[dd6563] by Christophe Rhodes Christophe Rhodes HPPA fixes from Larry Valkama

2009-03-01 20:34:50 Tree
[1b32a5] by Gabor Melis Gabor Melis fix compilation on win32

2009-03-01 15:57:08 Tree
[f6fb4d] by Gabor Melis Gabor Melis SUB-GC: don't observe deadlines

- because the condition that's signalled can cause arbitrary code to
run catching us with pants down

- and we should not skip gc if it was triggerred

2009-02-24 10:32:11 Tree
[cd12bb] by Alastair Bridgewater Alastair Bridgewater x86 disassembler fixes.

Made operand-size-prefix bytes disassemble correctly, using the same
approach used in the x86-64 backend (extra instruction formats for
reading the prefix byte).

Fixed movzx and movsx instructions to indicate the size of the source
data when moving from memory.

Added printers for cbw, cwde and cwd instructions.

2009-02-17 23:41:22 Tree
[012b15] by Gabor Melis Gabor Melis centralize scattered arch_os_get_context() calls

... to the six signal handlers trampolines. These are now the only
places where void_context appears, the rest of the runtime uses

Also, the &void_context+37 hack was removed. On Sparc/Linux the third
parameter of SA_SIGINFO signal handlers is a pointer to sigcontext,
which happens to be the same as &void_context+37 most of the time,

I have tested two on Sparc/Linux boxes, one running 2.6.26 that
randomly segfaulted compiling itself with, and another
runnin 2.6.24 that worked fine before at that version.

Thanks to Bruce O'Neel for the shell access.

2009-02-16 22:30:25 Tree
[4a205a] by Gabor Melis Gabor Melis fix gencgc_handle_wp_violation on multicpu systems

Acquire free_pages_lock around page_table accesses to be sure that the
changes actually propagate to other CPUs and we don't end up losing in
the else branch and also to prevent problems caused by the compiler or
the processor reordering stuff.

2009-02-16 22:29:06 Tree
[64eccd] by Gabor Melis Gabor Melis go through lisp_memory_fault_error on all platforms

... so that the corruption mechanism can kick in.

2009-02-16 22:27:07 Tree
[78c7db] by Gabor Melis Gabor Melis use WITH-RECURSIVE-SYSTEM-SPINLOCK

... instead of WITH-RECURSIVE-SPINLOCK because it's possible to
deadlock due to lock ordering with sufficiently unlucky interrupts as
demonstrated by test (:timer :parallel-unschedule) with low

This affects hash tables and some pcl locks.

Also, use WITH-RECURSIVE-MUTEX for packages.

Not a spinlock becuase it can be held for a long time and not a system
lock (i.e. with WITHOUT-INTERRUPTS) because conflicts are signalled
while holding the lock which I think this warrants a FIXME.

2009-02-16 22:26:25 Tree
[e5d969] by Gabor Melis Gabor Melis detect binding and alien stack exhaustion

Alien stack exhaustion machinery only works on x86oids.

2009-02-16 22:23:08 Tree
[724474] by Gabor Melis Gabor Melis x86/x86-64 unithread: use the allocated alien stack

... in struct thread and not the original control stack that we switch
away from in call_into_lisp_first_time.

2009-02-16 22:22:23 Tree
[eadeb7] by Gabor Melis Gabor Melis signals internals doc

2009-02-16 22:20:39 Tree
[842d3c] by Gabor Melis Gabor Melis OOAO restoring fp control word

Do it in all signal handlers, no matter what, on platforms that
require it.

2009-02-16 22:20:16 Tree
[3dd90b] by Gabor Melis Gabor Melis restore errno in signal handlers

2009-02-16 22:19:27 Tree
[2b0c46] by Gabor Melis Gabor Melis fix futex_wait deadlines when interrupted

When the syscall returned with EINTR futex_wait called again with the
same timeout. Now it lets Lisp recalculate the relative timeout from
the deadline.

2009-02-16 22:17:56 Tree
[ae09f8] by Gabor Melis Gabor Melis INTERRUPT-THREAD and timer improvements

The main thing accomplished by this commit is that it's finally
possible to use INTERRUPT-THREAD and TIMERS sanely:

- there is a per thread interruption queue, interruption are executed
in order of arrival

- the interruption has to explicitly enable interrupts with
WITH-INTERRUPTS if needed. In the absence of WITH-INTERRUPTS the
interruption itself is not interrupted and running out of stack is
not a problem.

- timers have an improved repeat mechanism

Implementation notes:

- INTERRUPT-THREAD is implemented on all platforms and builds (that
is, even without :SB-THREAD) by sending a signal to the current
thread (or process without thread). This allows us to hook into the
normal, interrupt deferral mechanism without having to commit OAOO
violations on the Lisp side. And it makes threaded, non-threaded
builds closer, hopefully easing testing.

- SIG_INTERRUPT_THREAD is SIGPIPE on all platforms. SIGPIPE is not
used in SBCL for its original purpose, instead it's for signalling a
thread that it should look at its interruption queue. The handler
(RUN_INTERRUPTION) just returns if there is nothing to do so it's
safe to receive spurious SIGPIPEs coming from the kernel.

- IN-INTERRUPTION does not unblock deferrables anymore, but arranges
for them to be unblocked when interrupts are enabled (see

- Thread interruption run wrapped in a (WITHOUT-INTERRUPTS

- Repeating timers reschedule themselves when they finished to the
current expiry time + repeat interval even if that's in the past.
Hence, a timer's schedule does not get shifted if it takes a long
time to run. If it takes more time than the repeat interval then it
may catch up on later invokations.

...)) even in run in a new thread.

- Enable previously failing tests.

- Add more tests.

- Automatically unschedule repeating timers if they take up all the

2009-02-16 22:16:20 Tree
[816c50] by Gabor Melis Gabor Melis alpha interrupt context fixes

- interrupt contexts pointers are 64 bit

- add padding to DEFINE-PRIMITIVE-OBJECT THREAD, because the C
compiler aligns interrupt_contexts on a double word boundary

2009-02-16 22:12:36 Tree
[0d4c7a] by Gabor Melis Gabor Melis make os_thread 0 on unithread builds

... because storing the pid there (two places really, thread.os_thread
and THREAD-OS-THREAD) complicates SB-POSIX:FORK, and makes a simple
fork() lose.

2009-02-16 22:08:38 Tree
[dca9c0] by Gabor Melis Gabor Melis only call pthread_kill with valid thread ids

... else it segfaults (at least on Linux). Fixes sporadic "Unhandled
memory fault" running timer, INTERRUPT-THREAD heavy code. And block
signals while calling pthread_kill because it is not async signal

2009-02-16 22:07:55 Tree
[bbbe40] by Gabor Melis Gabor Melis fix JOIN-THREAD

If the thread has not returned normally signal the error when not
holding the mutex anymore. Disable interrupt for the duration of
holding the mutex. Fix test.

2009-02-16 22:05:45 Tree
[77090f] by Gabor Melis Gabor Melis thread start/stop fixes

- disable interrupts during create_thread

... to protect against signals (async unwinds, reentrancy, ...)
during malloc, pthread code and to make the pinning of
INITIAL-FUNCTION effective. Also add checks to

- make-thread: assert gc enabled (to prevent deadlocks)

- block blockables while holding LOCK_CREATE_THREAD lock

- make dying threads safe from interrupts

2009-02-16 22:04:26 Tree
[d9d75f] by Gabor Melis Gabor Melis fix maybe_gc

2009-02-16 22:01:45 Tree
[aa0ed5] by Gabor Melis Gabor Melis block deferrables when gc pending in PA

Consider this:

alloc and set pseudo_atomic_interrupted and GC_PENDING
if (get_pseudo_atomic_interrupted())

If an async interrupt happens and unwinds between
clear_pseudo_atomic_atomic and gc() we have lost a gc trigger until
the next alloc. Same with SIG_STOP_FOR_GC instead of alloc.

This patch addresses the above problem by blocking deferrables when a
gc is requested in a pseudo atomic section. On exit from the protected
section there is no race because no async unwinding interrupts can

2009-02-16 22:01:15 Tree
[8d2697] by Gabor Melis Gabor Melis unblock signals on low level errors

Low level errors (control stack exhausted, memory fault) may trigger
at inconvenient times such as in signal handlers still running with
deferrables blocked. Due to the condition handling mechanism this
leads to executing user code at unsafe places and the image may very
well become corrupted. To allow continuing anyway with fingers crossed
to diagnose the problem, deferrable and/or gc signals are unblocked
before arranging for returning to the Lisp function that signals the
appropriate condition. Before that is done, however, a warning is
fprintf'ed to stderr to that this important piece of information is
not lost in some generic condition handler (or in a interrupt handler
async unwinding before anyone gets a chance to handle the condition)
which makes diagnosis of subsequent problems very hard.

This was brought to light by the checks added in the previous commit.

2009-02-16 21:56:20 Tree
[89aafe] by Gabor Melis Gabor Melis check that gc signals are unblocked

... when alloc() is called and when calling into Lisp.

2009-02-16 21:54:06 Tree
Older >