[Sbcl-devel] x86 FreeBSD and Threading
Anthony Juckel
I've tried building SBCL with threading support to see whether or not
it was supported. I'm running into a problem with the build though,
and haven't seen much documentation on the threading state on
non-linux machines. Any pointers on where to find better
documentation, or how to go about debugging this particular issue
would be welcome. Bear in mind that I'm a longish-time SBCL user, but
haven't done any SBCL internals hacking at this time.
I'm not sure exactly how much context from the build would be desired,
but here is the last bit of output I have readily available:
; SYS:SRC;PCL;COMPILER-SUPPORT.FASL.NEWEST written
; compilation finished in 0:00:00
; compiling file "/home/awj/src/lisp/sbcl-0.9.17/src/pcl/low.lisp"
(written 14 SEP 2006 08:33:06 AM):
; compiling (IN-PACKAGE "SB-PCL")
; compiling (DEFVAR *OPTIMIZE-SPEED* ...)
; compiling (DEFMACRO DOTIMES-FIXNUM ...)
; compiling (DEFSTRUCT (WRAPPER # ...) ...)
At this point the build hangs and CPU usage is pegged at 100%. The
output of truss -d when attached to the currently running sbcl process
is:
0.000208409 sigprocmask(SIG_BLOCK,0x0,SIGHUP|SIGINT|SIGQUIT|SIGPIPE|SIGALRM|SIGURG|SIGTSTP|SIGCHLD|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
) = 0 (0x0)
0.000367928 sigprocmask(SIG_BLOCK,0x0,SIGHUP|SIGINT|SIGQUIT|SIGPIPE|SIGALRM|SIGURG|SIGTSTP|SIGCHLD|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
) = 0 (0x0)
0.000442798 sigprocmask(SIG_BLOCK,0x0,SIGHUP|SIGINT|SIGQUIT|SIGPIPE|SIGALRM|SIGURG|SIGTSTP|SIGCHLD|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
) = 0 (0x0)
0.000508450 sigprocmask(SIG_BLOCK,0x0,SIGHUP|SIGINT|SIGQUIT|SIGPIPE|SIGALRM|SIGURG|SIGTSTP|SIGCHLD|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
) = 0 (0x0)
0.000582203 sigprocmask(SIG_BLOCK,0x0,SIGHUP|SIGINT|SIGQUIT|SIGPIPE|SIGALRM|SIGURG|SIGTSTP|SIGCHLD|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
) = 0 (0x0)
0.000648134 sigprocmask(SIG_BLOCK,0x0,SIGHUP|SIGINT|SIGQUIT|SIGPIPE|SIGALRM|SIGURG|SIGTSTP|SIGCHLD|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2
) = 0 (0x0)
......
For the sake of completeness, here's the struct that SBCL appears to
be compiling:
(defstruct (wrapper
(:include layout
;; KLUDGE: In CMU CL, the initialization default
;; for LAYOUT-INVALID was NIL. In SBCL, that has
;; changed to :UNINITIALIZED, but PCL code might
;; still expect NIL for the initialization
;; default of WRAPPER-INVALID. Instead of trying
;; to find out, I just overrode the LAYOUT
;; default here. -- WHN 19991204
(invalid nil))
(:conc-name %wrapper-)
(:constructor make-wrapper-internal)
(:copier nil))
(instance-slots-layout nil :type list)
(class-slots nil :type list))
#-sb-fluid (declaim (sb-ext:freeze-type wrapper))
Now, I'm not certain if this is a known problem. I'm fairly certain
that there is no official support for threads on non-linux machines,
but I'm uncertain where any development attempts may be.
Anthony W. Juckel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
Anthony Juckel
Hardware: Pentium4
OS: FreeBSD 6.2-PRERELEASE
SBCL: 0.9.17 release tarball.
I tried loading the cold-sbcl.core in gdb, but quickly ran into the
SIGBUS problem that I've heard discussed, so I'm unsure how to
progress. For now, I'll attempt to condense the problem to a minimal
test case which triggers the error.
Nikodemus Siivola
> As I now have a FreeBSD development machine available to me again,
> I've tried building SBCL with threading support to see whether or not
> it was supported. I'm running into a problem with the build though,
Threads on FreeBSD are not supported.
Threading support does exist for Darwin/x86 (quite experimental still)
and Solaris/x86 in addition to Linux, so porting to FreeBSD is
significantly less daunting these days.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
Martin Cracauer
> "Anthony Juckel" <aju...@gmail.com> writes:
>
> > As I now have a FreeBSD development machine available to me again,
> > I've tried building SBCL with threading support to see whether or not
> > it was supported. I'm running into a problem with the build though,
>
> Threads on FreeBSD are not supported.
>
> Threading support does exist for Darwin/x86 (quite experimental still)
> and Solaris/x86 in addition to Linux, so porting to FreeBSD is
> significantly less daunting these days.
The Linux compat layer in FreeBSD also has futex functionality.
You might be able to do use the futex SBCL code if you can move the
futex code into the native FreeBSD API. That might be a good idea
anyway as other Linux code (namely programming languages VMs) also use
futexes and it would make porting from Linux to FreeBSD easier.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@cons.org> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/
NIIMI Satoshi
2006/10/25, Nikodemus Siivola <niko...@random-state.net>:
> Threading support does exist for Darwin/x86 (quite experimental still)
> and Solaris/x86 in addition to Linux, so porting to FreeBSD is
> significantly less daunting these days.
Attached is a patch to experimentally support threading on FreeBSD.
I think more work should be done, but it executes simple threading program
and multi-threaded slime.
Failed tests on uni-processor 6.2-PRERELEASE are:
> Invalid exit status: threads.impure.lisp
> Invalid exit status: core.test.sh
Thanks,
--
NIIMI Satoshi
NIIMI Satoshi
Attached is an updated patch to support threding on FreeBSD.
Now, all tests are passed(*1).
On FreeBSD, most deadlocks are at pthread_join and are fixed by
joining the thread by dedicated worker thread.
The same method (defining CREATE_CLEANUP_THREAD in thread.c)
may solve Darwin's occasional hang ups.
*1 Although "sh run-tests.sh signals.impure.lisp" succeeds,
signals.impure.lisp fails when multiple tests are invoked.
Thanks,
--
NIIMI Satoshi
Andreas Fuchs
list)
NIIMI Satoshi wrote:
> Hi,
>
> Attached is an updated patch to support threding on FreeBSD.
> Now, all tests are passed(*1).
I tested this patch, applied to sbcl HEAD on FreeBSD 6.1-RELEASE running
in the Parallels Desktop for Mac virtual machine.
Of the 3 times I ran the tests, I got 2 complete (apparent) success.
For the successes, signals.impure.lisp worked when run from "sh
run-tests.sh" as well as "sh run-tests.sh signals.impure.lisp". Maybe
the slower CPU or strange interrupt behaviour of the virtual machine is
responsible for that.
The third run was a failure, though: It hangs in threads.impure.lisp,
directly after this output:
[many dashes]-----------------------------------------infodb test done
The sbcl process uses 100% of the CPU, and when I attach to it with
truss -p, I get lots of:
sigwait() ERR#429 'Unknown error: 429'
sigwait() ERR#429 'Unknown error: 429'
sigwait() ERR#429 'Unknown error: 429'
sigwait() ERR#429 'Unknown error: 429'
Hitting ^C gave me a backtrace of the SBCL invoking the impure test
only. The spinning child process had to be killed separately.
> On FreeBSD, most deadlocks are at pthread_join and are fixed by
> joining the thread by dedicated worker thread.
> The same method (defining CREATE_CLEANUP_THREAD in thread.c)
> may solve Darwin's occasional hang ups.
If it does, that would be fantastic.
Cheers,
--
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
NIIMI Satoshi
On 2006/11/18 07:47, Andreas Fuchs wrote:
> I tested this patch, applied to sbcl HEAD on FreeBSD 6.1-RELEASE running
> in the Parallels Desktop for Mac virtual machine.
Thank you for testing my patch.
> Of the 3 times I ran the tests, I got 2 complete (apparent) success.
>
> For the successes, signals.impure.lisp worked when run from "sh
> run-tests.sh" as well as "sh run-tests.sh signals.impure.lisp". Maybe
> the slower CPU or strange interrupt behaviour of the virtual machine is
> responsible for that.
I've found why "signals.impure.lisp" failed occasionally, and am
planning to fix it.
> The third run was a failure, though: It hangs in threads.impure.lisp,
> directly after this output:
>
> [many dashes]-----------------------------------------infodb test done
>
> The sbcl process uses 100% of the CPU, and when I attach to it with
> truss -p, I get lots of:
>
> sigwait() ERR#429 'Unknown error: 429'
> sigwait() ERR#429 'Unknown error: 429'
> sigwait() ERR#429 'Unknown error: 429'
> sigwait() ERR#429 'Unknown error: 429'
Hmmm... It seems that deadlock at "backtrace test" is still there.
I'll recheck it.
Thanks,
--
NIIMI Satoshi
NIIMI Satoshi
Attached is an additional patch to support threading on FreeBSD.
Apply this patch after my previous patch "sbcl-freebsd-thread-2.diff".
Currently threading on FreeBSD with these patches works only on 6.x.
Fixed problems are:
* Lock on the mutex locked by the same thread
Failure might occur like:
(with-mute (mutex)
...
*signal* ... (with-mutex (mutex) ...) ... *signal return*
...)
To work around this, use PTHREAD_MUTEX_ERRORCHECK and check some
error codes in lisp side.
This fixes occasional failure on signals.impures.lisp.
* Race condition on gc_stop_the_world() and create_os_thread()
On FreeBSD, signaling might cause deadlock in pthread_create().
To work around this, serialize them with a mutex. (kludge)
This fixes occasional hang on threads.impures.lisp reported by
Andreas Fuchs.
In addition, I also attached a patch for clean.sh not to clobber
repository data of Mercurial.
Thanks,
--
NIIMI Satoshi
Andreas Fuchs
> Hi,
>
> Attached is an additional patch to support threading on FreeBSD.
> Apply this patch after my previous patch "sbcl-freebsd-thread-2.diff".
>
> Currently threading on FreeBSD with these patches works only on 6.x.
Tested with this patch applied to CVS HEAD patched with -2. Results:
4 runs, 4 successes, 0 failures.
Also, I notice that Cyrus Harmon just committed your patch.
Congratulations! (:
Cheers,
--
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Nikodemus Siivola
> Attached is an additional patch to support threading on FreeBSD.
Great work! Congratulations!
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Harald Hanche-Olsen
| NIIMI Satoshi <sa...@sa2c.net> writes:
|
| > Attached is an additional patch to support threading on FreeBSD.
|
| Great work! Congratulations!
Indeed. Next question - will this make it easier, somehow, to also
get threading on Darwin/PPC? I seem to recall from earlier
discussions that some of the issues were similar. But of course, if
the current patch only works on FreeBSD 6.x, then given that Darwin is
based on a much older FreeBSD, I suppose there are still hurdles to
overcome. (I'd be glad to help, but I am afraid this sort of hackery
is way beyond my ken.)
- Harald