You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(8) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
(8) |
2003 |
Jan
(5) |
Feb
(4) |
Mar
(14) |
Apr
|
May
(27) |
Jun
(10) |
Jul
(3) |
Aug
(28) |
Sep
(27) |
Oct
(3) |
Nov
(14) |
Dec
(19) |
2004 |
Jan
(32) |
Feb
(15) |
Mar
(21) |
Apr
(69) |
May
(18) |
Jun
(15) |
Jul
(23) |
Aug
(14) |
Sep
(38) |
Oct
(20) |
Nov
(76) |
Dec
(27) |
2005 |
Jan
(24) |
Feb
(32) |
Mar
(39) |
Apr
(65) |
May
(69) |
Jun
(37) |
Jul
(32) |
Aug
(28) |
Sep
(28) |
Oct
(17) |
Nov
(30) |
Dec
(24) |
2006 |
Jan
(45) |
Feb
(38) |
Mar
(19) |
Apr
(26) |
May
(19) |
Jun
(29) |
Jul
(13) |
Aug
(26) |
Sep
(53) |
Oct
(46) |
Nov
(40) |
Dec
(85) |
2007 |
Jan
(45) |
Feb
(51) |
Mar
(69) |
Apr
(48) |
May
(75) |
Jun
(35) |
Jul
(35) |
Aug
(25) |
Sep
(11) |
Oct
(16) |
Nov
(9) |
Dec
(59) |
2008 |
Jan
(36) |
Feb
(17) |
Mar
(28) |
Apr
(13) |
May
(1) |
Jun
(25) |
Jul
(24) |
Aug
(52) |
Sep
(19) |
Oct
(52) |
Nov
(43) |
Dec
(80) |
2009 |
Jan
(33) |
Feb
(30) |
Mar
(18) |
Apr
(15) |
May
(29) |
Jun
(58) |
Jul
(48) |
Aug
(35) |
Sep
(52) |
Oct
(59) |
Nov
(46) |
Dec
(31) |
2010 |
Jan
(26) |
Feb
(45) |
Mar
(55) |
Apr
(59) |
May
(8) |
Jun
(24) |
Jul
(43) |
Aug
(31) |
Sep
(43) |
Oct
(33) |
Nov
(41) |
Dec
(19) |
2011 |
Jan
(17) |
Feb
(31) |
Mar
(5) |
Apr
(31) |
May
(17) |
Jun
(28) |
Jul
(15) |
Aug
(38) |
Sep
(21) |
Oct
(25) |
Nov
(21) |
Dec
(21) |
2012 |
Jan
(9) |
Feb
(22) |
Mar
(17) |
Apr
(16) |
May
(58) |
Jun
(13) |
Jul
(40) |
Aug
(12) |
Sep
(10) |
Oct
(10) |
Nov
(14) |
Dec
(4) |
2013 |
Jan
(9) |
Feb
(8) |
Mar
(17) |
Apr
(10) |
May
|
Jun
(9) |
Jul
(1) |
Aug
(7) |
Sep
(8) |
Oct
(22) |
Nov
(9) |
Dec
(6) |
2014 |
Jan
(30) |
Feb
(55) |
Mar
(38) |
Apr
(15) |
May
(7) |
Jun
(17) |
Jul
(15) |
Aug
(13) |
Sep
(21) |
Oct
(29) |
Nov
(7) |
Dec
(10) |
2015 |
Jan
(11) |
Feb
(19) |
Mar
(32) |
Apr
(17) |
May
(5) |
Jun
(3) |
Jul
(9) |
Aug
(7) |
Sep
(19) |
Oct
(3) |
Nov
(31) |
Dec
(23) |
2016 |
Jan
(11) |
Feb
(5) |
Mar
(8) |
Apr
(10) |
May
(15) |
Jun
(1) |
Jul
(11) |
Aug
(9) |
Sep
(11) |
Oct
(1) |
Nov
(26) |
Dec
(7) |
2017 |
Jan
(18) |
Feb
(19) |
Mar
(40) |
Apr
(6) |
May
(12) |
Jun
(1) |
Jul
(14) |
Aug
(21) |
Sep
(27) |
Oct
(22) |
Nov
(42) |
Dec
(3) |
2018 |
Jan
(9) |
Feb
(7) |
Mar
(31) |
Apr
(5) |
May
(7) |
Jun
|
Jul
(6) |
Aug
(34) |
Sep
(2) |
Oct
(8) |
Nov
(29) |
Dec
(7) |
2019 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(62) |
May
(18) |
Jun
(12) |
Jul
(30) |
Aug
(8) |
Sep
(4) |
Oct
(8) |
Nov
(6) |
Dec
(12) |
2020 |
Jan
(24) |
Feb
(4) |
Mar
(11) |
Apr
(16) |
May
(6) |
Jun
(59) |
Jul
(51) |
Aug
(18) |
Sep
(32) |
Oct
(19) |
Nov
(12) |
Dec
(29) |
2021 |
Jan
(11) |
Feb
(27) |
Mar
(30) |
Apr
(10) |
May
(29) |
Jun
(14) |
Jul
(10) |
Aug
(3) |
Sep
(12) |
Oct
(10) |
Nov
(18) |
Dec
(19) |
2022 |
Jan
(11) |
Feb
(8) |
Mar
(21) |
Apr
(30) |
May
(3) |
Jun
(2) |
Jul
(16) |
Aug
(9) |
Sep
(4) |
Oct
(2) |
Nov
(17) |
Dec
(10) |
2023 |
Jan
(16) |
Feb
(21) |
Mar
(42) |
Apr
(8) |
May
(7) |
Jun
(32) |
Jul
(3) |
Aug
(22) |
Sep
(11) |
Oct
(3) |
Nov
(16) |
Dec
(12) |
2024 |
Jan
(8) |
Feb
(15) |
Mar
(22) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jérôme R. <jer...@gm...> - 2024-03-18 12:53:08
|
Thanks Martin. It works when using (BREAK) after declaring local variables. But does that mean that stepping through code using the debugger can't show new local variables declared after (BREAK) ? How can I have my local variables automatically detected/shown when stepping through code using the debugger, like in other languages debuggers? Regards, Jérôme. Le lun. 18 mars 2024 à 11:25, eMko <mm0...@gm...> a écrit : > Hi, > > if you put `(break)` into the `let` form, you will be able to see the > variable (tested with SBCL 2.4.1 on Windows, the Roswell build). > > (defun foo (var1) > (let ((var2 (subseq var1 0 10))) > (break) > (dotimes (i 10 (fresh-line)) > (format t "~C" (char var2 i))))) > > SLY: > > break > [Condition of type SIMPLE-CONDITION] > > Restarts: > 0: [CONTINUE] Return from BREAK. > 1: [RETRY] Retry SLY mREPL evaluation request. > 2: [*ABORT] Return to SLY's top level. > 3: [ABORT] abort thread (#<THREAD "sly-channel-1-mrepl-remote-1" RUNNING > {1001160003}>) > > Backtrace: > 0: (FOO "hello world") > Locals: > VAR1 = "hello world" > VAR2 = "hello worl" > > Hope that helps. > > Martin > > On Mon, Mar 18, 2024 at 10:25 AM Jérôme Radix <jer...@gm...> > wrote: > >> Hello, >> >> When using the debugger, I can't figure out how to see the value of I and >> VAR2 in my little test code, even with (debug 3) optimization setting: >> (defun foo (var1) >> (break) >> (let ((var2 (subseq var1 0 10))) >> (dotimes (i 10 (fresh-line)) >> (format t "~C" (char var2 i))))) >> >> (foo "Hello World") >> >> Here is the transcript of my session, on linux >> 5.15.146.1-microsoft-standard-WSL2: >> >> $ sbcl --no-sysinit --no-userinit >> This is SBCL 2.3.4, an implementation of ANSI Common Lisp. >> More information about SBCL is available at <http://www.sbcl.org/>. >> >> SBCL is free software, provided as is, with absolutely no warranty. >> It is mostly in the public domain; some portions are provided under >> BSD-style licenses. See the CREDITS and COPYING files in the >> distribution for more information. >> * (declaim (optimize (debug 3))) >> NIL >> * (sb-ext:describe-compiler-policy) >> Basic qualities: >> COMPILATION-SPEED = 1 >> DEBUG = 3 >> SAFETY = 1 >> SPACE = 1 >> SPEED = 1 >> INHIBIT-WARNINGS = 1 >> Dependent qualities: >> SB-C::CHECK-CONSTANT-MODIFICATION = 1 -> 1 (maybe) >> SB-C::TYPE-CHECK = 1 -> 3 (full) >> SB-C::LET-CONVERSION = 1 -> 0 (off) >> SB-C:ALIEN-FUNCALL-SAVES-FP-AND-PC = 1 -> 3 (yes) >> SB-C:VERIFY-ARG-COUNT = 1 -> 3 (yes) >> SB-C::INSERT-DEBUG-CATCH = 1 -> 3 (yes) >> SB-C::RECOGNIZE-SELF-CALLS = 1 -> 0 (no) >> SB-C::FLOAT-ACCURACY = 1 -> 3 (full) >> SB-C:INSERT-STEP-CONDITIONS = 1 -> 3 (full) >> SB-C::COMPUTE-DEBUG-FUN = 1 -> 3 (yes) >> SB-C:STORE-SOURCE-FORM = 1 -> 3 (yes) >> SB-C::PRESERVE-SINGLE-USE-DEBUG-VARIABLES = 1 -> 3 (yes) >> SB-C::PRESERVE-CONSTANTS = 1 -> 0 (no) >> SB-C:INSERT-ARRAY-BOUNDS-CHECKS = 1 -> 3 (yes) >> SB-C::AREF-TRAPPING = 1 -> 0 (no) >> SB-C::STORE-XREF-DATA = 1 -> 3 (yes) >> SB-C:STORE-COVERAGE-DATA = 1 -> 0 (no) >> SB-C:INSTRUMENT-CONSING = 1 -> 1 (no) >> SB-C::STORE-CLOSURE-DEBUG-POINTER = 1 -> 0 (no) >> * (defun foo (var1) >> (break) >> (let ((var2 (subseq var1 0 10))) >> (dotimes (i 10 (fresh-line)) >> (format t "~C" (char var2 i))))) >> FOO >> * (foo "Hello World") >> >> debugger invoked on a SIMPLE-CONDITION in thread >> #<THREAD tid=1590 "main thread" RUNNING {1001090003}>: >> break >> >> Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. >> >> restarts (invokable by number or by possibly-abbreviated name): >> 0: [CONTINUE] Return from BREAK. >> 1: [ABORT ] Exit debugger, returning to top level. >> >> (FOO "Hello World") >> source: (BREAK) >> 0] start >> ; Evaluating call: >> ; (SUBSEQ VAR1 0 10) >> ; With arguments: >> ; "Hello World" >> ; 0 >> ; 10 >> >> 1] step >> ; (SUBSEQ VAR1 0 10) => "Hello Worl" >> ; Evaluating call: >> ; (+ I 1) >> ; With unknown arguments >> H >> 0] step >> ; Evaluating call: >> ; (+ I 1) >> ; With unknown arguments >> e >> 0] L >> VAR1 = "Hello World" >> >> ==> I want to see the value of I and VAR2. What am I doing wrong ? >> I've tried several combinations of (declaim (optimize (debug 3) (space 0) >> (safety 3) (speed 0))) with no difference in behavior. >> >> Thanks for your help. >> >> Regards, >> Jérôme. >> _______________________________________________ >> Sbcl-help mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-help >> > |
From: eMko <mm0...@gm...> - 2024-03-18 10:25:59
|
Hi, if you put `(break)` into the `let` form, you will be able to see the variable (tested with SBCL 2.4.1 on Windows, the Roswell build). (defun foo (var1) (let ((var2 (subseq var1 0 10))) (break) (dotimes (i 10 (fresh-line)) (format t "~C" (char var2 i))))) SLY: break [Condition of type SIMPLE-CONDITION] Restarts: 0: [CONTINUE] Return from BREAK. 1: [RETRY] Retry SLY mREPL evaluation request. 2: [*ABORT] Return to SLY's top level. 3: [ABORT] abort thread (#<THREAD "sly-channel-1-mrepl-remote-1" RUNNING {1001160003}>) Backtrace: 0: (FOO "hello world") Locals: VAR1 = "hello world" VAR2 = "hello worl" Hope that helps. Martin On Mon, Mar 18, 2024 at 10:25 AM Jérôme Radix <jer...@gm...> wrote: > Hello, > > When using the debugger, I can't figure out how to see the value of I and > VAR2 in my little test code, even with (debug 3) optimization setting: > (defun foo (var1) > (break) > (let ((var2 (subseq var1 0 10))) > (dotimes (i 10 (fresh-line)) > (format t "~C" (char var2 i))))) > > (foo "Hello World") > > Here is the transcript of my session, on linux > 5.15.146.1-microsoft-standard-WSL2: > > $ sbcl --no-sysinit --no-userinit > This is SBCL 2.3.4, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > * (declaim (optimize (debug 3))) > NIL > * (sb-ext:describe-compiler-policy) > Basic qualities: > COMPILATION-SPEED = 1 > DEBUG = 3 > SAFETY = 1 > SPACE = 1 > SPEED = 1 > INHIBIT-WARNINGS = 1 > Dependent qualities: > SB-C::CHECK-CONSTANT-MODIFICATION = 1 -> 1 (maybe) > SB-C::TYPE-CHECK = 1 -> 3 (full) > SB-C::LET-CONVERSION = 1 -> 0 (off) > SB-C:ALIEN-FUNCALL-SAVES-FP-AND-PC = 1 -> 3 (yes) > SB-C:VERIFY-ARG-COUNT = 1 -> 3 (yes) > SB-C::INSERT-DEBUG-CATCH = 1 -> 3 (yes) > SB-C::RECOGNIZE-SELF-CALLS = 1 -> 0 (no) > SB-C::FLOAT-ACCURACY = 1 -> 3 (full) > SB-C:INSERT-STEP-CONDITIONS = 1 -> 3 (full) > SB-C::COMPUTE-DEBUG-FUN = 1 -> 3 (yes) > SB-C:STORE-SOURCE-FORM = 1 -> 3 (yes) > SB-C::PRESERVE-SINGLE-USE-DEBUG-VARIABLES = 1 -> 3 (yes) > SB-C::PRESERVE-CONSTANTS = 1 -> 0 (no) > SB-C:INSERT-ARRAY-BOUNDS-CHECKS = 1 -> 3 (yes) > SB-C::AREF-TRAPPING = 1 -> 0 (no) > SB-C::STORE-XREF-DATA = 1 -> 3 (yes) > SB-C:STORE-COVERAGE-DATA = 1 -> 0 (no) > SB-C:INSTRUMENT-CONSING = 1 -> 1 (no) > SB-C::STORE-CLOSURE-DEBUG-POINTER = 1 -> 0 (no) > * (defun foo (var1) > (break) > (let ((var2 (subseq var1 0 10))) > (dotimes (i 10 (fresh-line)) > (format t "~C" (char var2 i))))) > FOO > * (foo "Hello World") > > debugger invoked on a SIMPLE-CONDITION in thread > #<THREAD tid=1590 "main thread" RUNNING {1001090003}>: > break > > Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [CONTINUE] Return from BREAK. > 1: [ABORT ] Exit debugger, returning to top level. > > (FOO "Hello World") > source: (BREAK) > 0] start > ; Evaluating call: > ; (SUBSEQ VAR1 0 10) > ; With arguments: > ; "Hello World" > ; 0 > ; 10 > > 1] step > ; (SUBSEQ VAR1 0 10) => "Hello Worl" > ; Evaluating call: > ; (+ I 1) > ; With unknown arguments > H > 0] step > ; Evaluating call: > ; (+ I 1) > ; With unknown arguments > e > 0] L > VAR1 = "Hello World" > > ==> I want to see the value of I and VAR2. What am I doing wrong ? > I've tried several combinations of (declaim (optimize (debug 3) (space 0) > (safety 3) (speed 0))) with no difference in behavior. > > Thanks for your help. > > Regards, > Jérôme. > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Jérôme R. <jer...@gm...> - 2024-03-18 09:21:44
|
Hello, When using the debugger, I can't figure out how to see the value of I and VAR2 in my little test code, even with (debug 3) optimization setting: (defun foo (var1) (break) (let ((var2 (subseq var1 0 10))) (dotimes (i 10 (fresh-line)) (format t "~C" (char var2 i))))) (foo "Hello World") Here is the transcript of my session, on linux 5.15.146.1-microsoft-standard-WSL2: $ sbcl --no-sysinit --no-userinit This is SBCL 2.3.4, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (declaim (optimize (debug 3))) NIL * (sb-ext:describe-compiler-policy) Basic qualities: COMPILATION-SPEED = 1 DEBUG = 3 SAFETY = 1 SPACE = 1 SPEED = 1 INHIBIT-WARNINGS = 1 Dependent qualities: SB-C::CHECK-CONSTANT-MODIFICATION = 1 -> 1 (maybe) SB-C::TYPE-CHECK = 1 -> 3 (full) SB-C::LET-CONVERSION = 1 -> 0 (off) SB-C:ALIEN-FUNCALL-SAVES-FP-AND-PC = 1 -> 3 (yes) SB-C:VERIFY-ARG-COUNT = 1 -> 3 (yes) SB-C::INSERT-DEBUG-CATCH = 1 -> 3 (yes) SB-C::RECOGNIZE-SELF-CALLS = 1 -> 0 (no) SB-C::FLOAT-ACCURACY = 1 -> 3 (full) SB-C:INSERT-STEP-CONDITIONS = 1 -> 3 (full) SB-C::COMPUTE-DEBUG-FUN = 1 -> 3 (yes) SB-C:STORE-SOURCE-FORM = 1 -> 3 (yes) SB-C::PRESERVE-SINGLE-USE-DEBUG-VARIABLES = 1 -> 3 (yes) SB-C::PRESERVE-CONSTANTS = 1 -> 0 (no) SB-C:INSERT-ARRAY-BOUNDS-CHECKS = 1 -> 3 (yes) SB-C::AREF-TRAPPING = 1 -> 0 (no) SB-C::STORE-XREF-DATA = 1 -> 3 (yes) SB-C:STORE-COVERAGE-DATA = 1 -> 0 (no) SB-C:INSTRUMENT-CONSING = 1 -> 1 (no) SB-C::STORE-CLOSURE-DEBUG-POINTER = 1 -> 0 (no) * (defun foo (var1) (break) (let ((var2 (subseq var1 0 10))) (dotimes (i 10 (fresh-line)) (format t "~C" (char var2 i))))) FOO * (foo "Hello World") debugger invoked on a SIMPLE-CONDITION in thread #<THREAD tid=1590 "main thread" RUNNING {1001090003}>: break Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Return from BREAK. 1: [ABORT ] Exit debugger, returning to top level. (FOO "Hello World") source: (BREAK) 0] start ; Evaluating call: ; (SUBSEQ VAR1 0 10) ; With arguments: ; "Hello World" ; 0 ; 10 1] step ; (SUBSEQ VAR1 0 10) => "Hello Worl" ; Evaluating call: ; (+ I 1) ; With unknown arguments H 0] step ; Evaluating call: ; (+ I 1) ; With unknown arguments e 0] L VAR1 = "Hello World" ==> I want to see the value of I and VAR2. What am I doing wrong ? I've tried several combinations of (declaim (optimize (debug 3) (space 0) (safety 3) (speed 0))) with no difference in behavior. Thanks for your help. Regards, Jérôme. |
From: Stas B. <sta...@gm...> - 2024-03-15 16:48:30
|
If it finds a thread that waits for a mutex owned by the current thread then from this point nothing can change, so then it goes back and rechecks that the previous mutex is still owned by this thread and so on. Since the write to thread-waits-for happens after the write to mutex-owner if we can observe thread-waits-for then we can be sure mutex-owner is correct. On Fri, Mar 15, 2024 at 7:41 PM Gábor Melis <me...@re...> wrote: > On Fri, 15 Mar 2024 at 14:53, Stas Boukarev <sta...@gm...> wrote: > > You don't need to stop the world because if there is a deadlock the > threads are aleady stopped. > > I haven't thought much about whether real deadlocks would get detected. > But deadlocks may be detected where there aren't any. > > > Which part is racy? > > I suspect it's racy because I couldn't convince myself otherwise in > half an hour. Here is my thinking. > > While CHECK-DEADLOCK is running, other threads are acquiring and > releasing locks, leading to situations like in this report. The chain > can be completely bogus in that it does not correspond to a consistent > snapshot (that one could get with the world stopped). Even a single > step in the chain -- looking up the owner of a lock and then looking > up what the owner thread is waiting for -- can give us a lock-to-lock > edge in the graph that never existed, if between the two lookups the > owner thread releases the lock and proceeds to block on another. > > If the read barriers somehow guarantee that this cannot happen, I > can't see it. > > The recheck needs to do what the comment [1] says: > > ;; Recheck that the mutex is still owned by the same thread. > > ... while the code that follows seems happy if the mutex is owned > _again_ by the same thread, or if the change of ownership is not yet > visible to this thread. > > > > [1]: > https://github.com/sbcl/sbcl/blob/1aaeffe0bc7319f07413077a9a0c17877f995a4a/src/code/target-thread.lisp#L588C45-L588C102 > |
From: Gábor M. <me...@re...> - 2024-03-15 16:42:12
|
On Fri, 15 Mar 2024 at 14:53, Stas Boukarev <sta...@gm...> wrote: > You don't need to stop the world because if there is a deadlock the threads are aleady stopped. I haven't thought much about whether real deadlocks would get detected. But deadlocks may be detected where there aren't any. > Which part is racy? I suspect it's racy because I couldn't convince myself otherwise in half an hour. Here is my thinking. While CHECK-DEADLOCK is running, other threads are acquiring and releasing locks, leading to situations like in this report. The chain can be completely bogus in that it does not correspond to a consistent snapshot (that one could get with the world stopped). Even a single step in the chain -- looking up the owner of a lock and then looking up what the owner thread is waiting for -- can give us a lock-to-lock edge in the graph that never existed, if between the two lookups the owner thread releases the lock and proceeds to block on another. If the read barriers somehow guarantee that this cannot happen, I can't see it. The recheck needs to do what the comment [1] says: ;; Recheck that the mutex is still owned by the same thread. ... while the code that follows seems happy if the mutex is owned _again_ by the same thread, or if the change of ownership is not yet visible to this thread. [1]: https://github.com/sbcl/sbcl/blob/1aaeffe0bc7319f07413077a9a0c17877f995a4a/src/code/target-thread.lisp#L588C45-L588C102 |
From: Stas B. <sta...@gm...> - 2024-03-15 14:53:52
|
Which part is racy? You don't need to stop the world because if there is a deadlock the threads are aleady stopped. On Fri, Mar 15, 2024 at 12:48 PM Gábor Melis <me...@re...> wrote: > I suspect this fix is also racy but can't see how to fix the > inconsistent wait-for graph bug without extreme overhead, for example, > stopping the world, which suggests doing it during GC. > > Gábor > > PS: If a timeout is in effect around the acquisition of a lock, > CHECK-DEADLOCK cuts the dependency chain, which is reasonable [1]. > However, only SBCL's own timeouts are recognized; async unwinding for > another reason is not. This creates the possibility for false > positives if the code employs such a mechanism as par for the course > (arguably quite ugly). > > [1]: Another, weird option is to signal the inevitable timeout ahead > of time. > > On Tue, 12 Mar 2024 at 21:55, Stas Boukarev <sta...@gm...> wrote: > > > > I pushed a fix. But, as always with multithreaded code, it's hard to be > certain. So, please, test. > > On Mon, Feb 26, 2024 at 6:58 PM Michał Herda | Keepit via Sbcl-help < > sbc...@li...> wrote: > >> > >> Hello, > >> > >> we at Keepit might have run into a situation where the > deadlock-checking in SBCL seems overzealous in some situations because of a > race condition in target-thread.lisp. > >> > >> Here's the hypothetical scenario for threads T1 T2 and mutexes M1 M2: > >> > >> 1. T2 grabs M2. > >> 2. T1 grabs M1. > >> 3. T1 starts waiting for M2 (which is locked by T2) > >> 4. T1 starts checking for deadlocks. > >> 5. T1 sees that M2 belongs to T2. > >> 6. T2 releases M2. > >> 7. T2 starts waiting for M1 (which is locked by T1). > >> 8. T1 continues to check deadlocks and sees that T2 is waiting for M1. > >> 9. T1 sees that M1 belongs to itself. > >> 10. T1 signals a deadlock, even though M2 is now free and the code can > proceed. > >> > >> Our idea of patching this behavior is to add a handler around the call > to DETECT-DEADLOCK that, in case of signaling, reattempts to verify the > deadlock. This resolves this particular situation in the following way: > >> > >> 11. The deadlock is handled, T1 attempts to check for deadlocks again. > >> 12. T1 sees no deadlock, because M2 is now free. > >> 13. T1 grabs M2. > >> 14. T1 has both mutexes, does work, releases mutexes. > >> > >> The below patch seems to have resolved the deadlocks we've been seeing > in our deployed application on 2.3.7. Is the above solution valid? Can we > come up with anything better? Is it possible to avoid the situation where a > thread T3 can grab M2 in meantime, which would lead to another false > positive? > >> > >> BR, > >> Michał "phoe" Herda > >> > >> -------------- > >> > >> diff --git a/src/code/target-thread.lisp b/src/code/target-thread.lisp > >> index > 795802c769f6169b664bbedc118994e81d8ef919..d25a3c6ede5ab5ba7ad26b54fce901b5a3badc55 > 100644 > >> --- a/src/code/target-thread.lisp > >> +++ b/src/code/target-thread.lisp > >> @@ -578,7 +578,13 @@ See also: RETURN-FROM-THREAD and SB-EXT:EXIT." > >> (return-from check-deadlock nil))))))) > >> ;; Timeout means there is no deadlock > >> (when (mutex-p origin) > >> - (detect-deadlock origin) > >> + (handler-case (detect-deadlock origin) > >> + (thread-deadlock () > >> + ;; Double-check. If it's a true deadlock, it should stay > >> + (detect-deadlock origin) > >> + ;; Restore the waiting-for mark now that we know it was > >> + ;; a false positive > >> + (setf (thread-waiting-for self) origin))) > >> t)))) > >> > >> ;;;; WAIT-FOR -- waiting on arbitrary conditions > >> > >> > >> > >> This e-mail is sent to you from Keepit A/S. Dedicated SaaS Data > Protection. > >> VAT: DK30806883, Per Henrik Lings Allé 4, 7., DK-2100 Copenhagen Ø, > Denmark. > >> > >> This e-mail is sent to you directly and is meant for nobody else. If > the e-mail contains personal data that Keepit is responsible for and the > e-mail was not meant for you, please do not forward, distribute, or copy, > i.e. but return the e-mail to sender. Also, do not send the e-mail to a > third party without making sure that you have our prior consent. > Distribution of this e-mail to unauthorized receivers may have legal > consequences. > >> If you have received an e-mail from us and you don’t know why, then > please refer to our Privacy Policy. > >> If you do not want to receive more e-mails from us, please contact > bus...@ke.... > >> _______________________________________________ > >> Sbcl-help mailing list > >> Sbc...@li... > >> https://lists.sourceforge.net/lists/listinfo/sbcl-help > > > > _______________________________________________ > > Sbcl-help mailing list > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Gábor M. <me...@re...> - 2024-03-15 09:48:26
|
I suspect this fix is also racy but can't see how to fix the inconsistent wait-for graph bug without extreme overhead, for example, stopping the world, which suggests doing it during GC. Gábor PS: If a timeout is in effect around the acquisition of a lock, CHECK-DEADLOCK cuts the dependency chain, which is reasonable [1]. However, only SBCL's own timeouts are recognized; async unwinding for another reason is not. This creates the possibility for false positives if the code employs such a mechanism as par for the course (arguably quite ugly). [1]: Another, weird option is to signal the inevitable timeout ahead of time. On Tue, 12 Mar 2024 at 21:55, Stas Boukarev <sta...@gm...> wrote: > > I pushed a fix. But, as always with multithreaded code, it's hard to be certain. So, please, test. > On Mon, Feb 26, 2024 at 6:58 PM Michał Herda | Keepit via Sbcl-help <sbc...@li...> wrote: >> >> Hello, >> >> we at Keepit might have run into a situation where the deadlock-checking in SBCL seems overzealous in some situations because of a race condition in target-thread.lisp. >> >> Here's the hypothetical scenario for threads T1 T2 and mutexes M1 M2: >> >> 1. T2 grabs M2. >> 2. T1 grabs M1. >> 3. T1 starts waiting for M2 (which is locked by T2) >> 4. T1 starts checking for deadlocks. >> 5. T1 sees that M2 belongs to T2. >> 6. T2 releases M2. >> 7. T2 starts waiting for M1 (which is locked by T1). >> 8. T1 continues to check deadlocks and sees that T2 is waiting for M1. >> 9. T1 sees that M1 belongs to itself. >> 10. T1 signals a deadlock, even though M2 is now free and the code can proceed. >> >> Our idea of patching this behavior is to add a handler around the call to DETECT-DEADLOCK that, in case of signaling, reattempts to verify the deadlock. This resolves this particular situation in the following way: >> >> 11. The deadlock is handled, T1 attempts to check for deadlocks again. >> 12. T1 sees no deadlock, because M2 is now free. >> 13. T1 grabs M2. >> 14. T1 has both mutexes, does work, releases mutexes. >> >> The below patch seems to have resolved the deadlocks we've been seeing in our deployed application on 2.3.7. Is the above solution valid? Can we come up with anything better? Is it possible to avoid the situation where a thread T3 can grab M2 in meantime, which would lead to another false positive? >> >> BR, >> Michał "phoe" Herda >> >> -------------- >> >> diff --git a/src/code/target-thread.lisp b/src/code/target-thread.lisp >> index 795802c769f6169b664bbedc118994e81d8ef919..d25a3c6ede5ab5ba7ad26b54fce901b5a3badc55 100644 >> --- a/src/code/target-thread.lisp >> +++ b/src/code/target-thread.lisp >> @@ -578,7 +578,13 @@ See also: RETURN-FROM-THREAD and SB-EXT:EXIT." >> (return-from check-deadlock nil))))))) >> ;; Timeout means there is no deadlock >> (when (mutex-p origin) >> - (detect-deadlock origin) >> + (handler-case (detect-deadlock origin) >> + (thread-deadlock () >> + ;; Double-check. If it's a true deadlock, it should stay >> + (detect-deadlock origin) >> + ;; Restore the waiting-for mark now that we know it was >> + ;; a false positive >> + (setf (thread-waiting-for self) origin))) >> t)))) >> >> ;;;; WAIT-FOR -- waiting on arbitrary conditions >> >> >> >> This e-mail is sent to you from Keepit A/S. Dedicated SaaS Data Protection. >> VAT: DK30806883, Per Henrik Lings Allé 4, 7., DK-2100 Copenhagen Ø, Denmark. >> >> This e-mail is sent to you directly and is meant for nobody else. If the e-mail contains personal data that Keepit is responsible for and the e-mail was not meant for you, please do not forward, distribute, or copy, i.e. but return the e-mail to sender. Also, do not send the e-mail to a third party without making sure that you have our prior consent. Distribution of this e-mail to unauthorized receivers may have legal consequences. >> If you have received an e-mail from us and you don’t know why, then please refer to our Privacy Policy. >> If you do not want to receive more e-mails from us, please contact bus...@ke.... >> _______________________________________________ >> Sbcl-help mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-help > > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help |
From: Stas B. <sta...@gm...> - 2024-03-12 21:53:54
|
I pushed a fix. But, as always with multithreaded code, it's hard to be certain. So, please, test. On Mon, Feb 26, 2024 at 6:58 PM Michał Herda | Keepit via Sbcl-help < sbc...@li...> wrote: > Hello, > > we at Keepit might have run into a situation where the deadlock-checking > in SBCL seems overzealous in some situations because of a race condition in > target-thread.lisp. > > Here's the hypothetical scenario for threads T1 T2 and mutexes M1 M2: > > 1. T2 grabs M2. > 2. T1 grabs M1. > 3. T1 starts waiting for M2 (which is locked by T2) > 4. T1 starts checking for deadlocks. > 5. T1 sees that M2 belongs to T2. > 6. T2 releases M2. > 7. T2 starts waiting for M1 (which is locked by T1). > 8. T1 continues to check deadlocks and sees that T2 is waiting for M1. > 9. T1 sees that M1 belongs to itself. > 10. T1 signals a deadlock, even though M2 is now free and the code can > proceed. > > Our idea of patching this behavior is to add a handler around the call to > DETECT-DEADLOCK that, in case of signaling, reattempts to verify the > deadlock. This resolves this particular situation in the following way: > > 11. The deadlock is handled, T1 attempts to check for deadlocks again. > 12. T1 sees no deadlock, because M2 is now free. > 13. T1 grabs M2. > 14. T1 has both mutexes, does work, releases mutexes. > > The below patch seems to have resolved the deadlocks we've been seeing in > our deployed application on 2.3.7. Is the above solution valid? Can we come > up with anything better? Is it possible to avoid the situation where a > thread T3 can grab M2 in meantime, which would lead to another false > positive? > > BR, > Michał "phoe" Herda > > -------------- > > diff --git a/src/code/target-thread.lisp b/src/code/target-thread.lisp > index > 795802c769f6169b664bbedc118994e81d8ef919..d25a3c6ede5ab5ba7ad26b54fce901b5a3badc55 > 100644 > --- a/src/code/target-thread.lisp > +++ b/src/code/target-thread.lisp > @@ -578,7 +578,13 @@ See also: RETURN-FROM-THREAD and SB-EXT:EXIT." > (return-from check-deadlock nil))))))) > ;; Timeout means there is no deadlock > (when (mutex-p origin) > - (detect-deadlock origin) > + (handler-case (detect-deadlock origin) > + (thread-deadlock () > + ;; Double-check. If it's a true deadlock, it should stay > + (detect-deadlock origin) > + ;; Restore the waiting-for mark now that we know it was > + ;; a false positive > + (setf (thread-waiting-for self) origin))) > t)))) > > ;;;; WAIT-FOR -- waiting on arbitrary conditions > > > > This e-mail is sent to you from Keepit A/S. Dedicated SaaS Data Protection. > VAT: DK30806883, Per Henrik Lings Allé 4, 7., DK-2100 Copenhagen Ø, > Denmark. > > This e-mail is sent to you directly and is meant for nobody else. If the > e-mail contains personal data that Keepit is responsible for and the e-mail > was not meant for you, please do not forward, distribute, or copy, i.e. but > return the e-mail to sender. Also, do not send the e-mail to a third party > without making sure that you have our prior consent. Distribution of this > e-mail to unauthorized receivers may have legal consequences. > If you have received an e-mail from us and you don’t know why, then please > refer to our Privacy Policy <https://www.keepit.com/privacy-policy/>. > If you do not want to receive more e-mails from us, please contact > bus...@ke.... > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Stas B. <sta...@gm...> - 2024-03-12 15:30:14
|
Looking at the 6.2 version superficially, the contents do differ. Maybe having a broken link is better. Outside of actually having our own documentation. (Who even uses simple-streams?) On Mon, Mar 11, 2024 at 5:37 PM Nalin Ranjan <ran...@gm...> wrote: > Hi, > Would you like to fix the broken link to " > http://www.franz.com/support/documentation/6.2/doc/streams.html" > in the documentation under " > https://www.sbcl.org/manual/index.html#Simple-Streams" > > While browsing, I got " > https://franz.com/support/documentation/11.0/streams.html". > > I understand that the url could be different for different versions. > > Just raising it as a flag, in case you want to. > > Thanks and Regards > Nalin Ranjan > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Nalin R. <ran...@gm...> - 2024-03-11 14:33:14
|
Hi, Would you like to fix the broken link to " http://www.franz.com/support/documentation/6.2/doc/streams.html" in the documentation under " https://www.sbcl.org/manual/index.html#Simple-Streams" While browsing, I got " https://franz.com/support/documentation/11.0/streams.html". I understand that the url could be different for different versions. Just raising it as a flag, in case you want to. Thanks and Regards Nalin Ranjan |
From: Douglas K. <do...@go...> - 2024-03-05 17:36:36
|
nice work getting that far! You could try gdb to find the function it's in. However, as shown below, you're going to get a SIGTAP right away, because SBCL uses the ppc 'trapw' instruction for a lot of things which unfortunately conflict with gdb. There is (supposedly) a way to build without using 'trapw' but I just tried it and it didn't work; maybe it bit-rotted. So let's not use that option. Now if you encounter sigfpe sooner than the first sigtrap, you'll find out where that occurred. If you get it after the sigtrap, things are going to be more difficult. gdb --args src/runtime/sbcl --core output/cold-sbcl.core (gdb) *run* COLD-INIT... Program received signal SIGTRAP, Trace/breakpoint trap. I tried telling gdb to passthru the sigtraps, and that failed. gdb is acting as if the user program never installed a sigtrap handler, which I think it must have. Not sure what's going on there. (gdb) *handle SIGTRAP pass nostop print* SIGTRAP is used by the debugger. Are you sure you want to change it? (y or n)*y* (gdb) *run* Starting program: /home/snuglas/devel/sbcl/src/runtime/sbcl --core output/cold-sbcl.core [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program terminated with signal SIGTRAP, Trace/breakpoint trap. The program no longer exists. Based on your output, you got a kernel coredump. You could start that up. In this case 'core' is the name of the OS-format core file, so it doesn't take a "--core" arg which is an SBCL arg. gdb src/runtime/sbcl core (gdb) where If the function is C (which seems unlikely), gdb will have the name of it. If the function is Lisp, you have to open up 'output/cold-sbcl.map' in an editor and search for the text II.B. defined functions (numerically): that demarcates the function map. Scan that list visually and look for two addresses that span the program count where gdb says the process died. There are some other techniques we can get into as well. One other thing to try: wherever the code is doing ll_install_handler to install our so-called "low-level handlers", add ll_install_handler(SIGFPE, ldb_monitor); This will _maybe_ get it to go into SBCL's monitor at the first sigfpe. Normally we don't install it as a low-level handler, we install it as Lisp handler, because Lisp wants to know about the various FPEs, and we should never see an FPE in cold-init. But if you make a low-level handler, you should get a chance to get into the monitor before dying Do you have some diffs I can see? |
From: Curtis H. <clh...@gm...> - 2024-03-05 16:35:44
|
Hello All! I’m trying to port to FreeBSD/PPC64le and looking for a little help. Since it supposedly works on Linux/ppc64le, I’ve made what I think are the necessary changes for FreeBSD. However, the build fails on “COLD-INIT” with a floating point exception (see below). Can someone point me to what I need to do to this fixed? Thanks in advance for your help ; SB-Loader: (170+4430) methods/other SB-XC:*FEATURES* = (:PPC64 :GENCGC :64-BIT :ALIEN-CALLBACKS :ANSI-CL :ANSI-COMPLIANT-LOAD-TRUENAME :BSD :COMMON-LISP :COMPACT-SYMBOL :COMPARE-AND-SWAP-VOPS :ELF :FREEBSD :GCC-TLS :GENERATIONAL :IEEE-FLOATING-POINT :LITTLE-ENDIAN :OS-PROVIDES-BLKSIZE-T :OS-PROVIDES-CLOSE-RANGE-WRAPPER :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-GETPROTOBY-R :OS-PROVIDES-POLL :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :SB-DOC :SB-EVAL :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS :SB-SOURCE-LOCATIONS :SB-THREAD :SB-UNICODE :SBCL :SOFT-CARD-MARKS :UNIX :UNTAGGED-FDEFNS) [building initial core file in "output/cold-sbcl.core": writing 65536 bytes [1 page] from #<SB-FASL::GSPACE @#x4100000 :STATIC> writing 38141952 bytes [582 pages] from #<SB-FASL::GSPACE @#x1000000000 :DYNAMIC> writing 0 bytes [0 pages] from #<SB-FASL::GSPACE @#x4000000 :READ-ONLY> movable dynamic space: 45 + 263 + 274 cons/code/mixed pages /INITIAL-FUN=#X10022C5AC6 done] Bye. //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good 3841.54 real 3839.40 user 2.15 sys //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 2.4.2.50-4a7f4df1c-WIP, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Initial page table: Immobile Object Counts Gen layout fdefn symbol code Boxed Cons Raw Code SmMix Mixed LgRaw LgCode LgMix Waste% Alloc Trig Dirty GCs Mem-age 6 0 0 0 0 0 45 0 263 0 274 0 0 0 0.2 38047040 2000000 0 0 0.0000 Tot 0 0 0 0 0 45 0 263 0 274 0 0 0 0.2 38047040 [3.5% of 1073741824 max] COLD-INIT... Floating point exception (core dumped) 0.80 real 0.00 user 0.64 sys |
From: Stas B. <sta...@gm...> - 2024-03-04 09:02:42
|
Is your LLM malfunctioning? On Mon, Mar 4, 2024 at 6:46 AM steve gonedes <sgo...@gm...> wrote: > > On 3/2/24 10:32, Matt Kaufmann wrote: > > Hi, > > In SBCL 2.4.2, standard-char-p no longer returns t on a standard > character input. Apparently it now returns that input, as defined in > file src/code/target-char.lisp of the SBCL 2.4.2 source distribution. > This behavior is of course Common Lisp compliant, since every value is > a so-called generalized Boolean. That said, our ACL2 development has > assumed for more than 30 years that predicates return Booleans except > when specified otherwise, like member (not looking here for an > argument about whether that assumption was proper) -- and we've never > seen that assumption violated by any Common Lisp implementation that > can host ACL2 (currently 6 of them, including SBCL). So, I'll ask: > > Might that change be reversed in the next SBCL release? > > Since the change wasn't mentioned in the "changes in sbcl-2.4.2 > relative to sbcl-2.4.1" emailed to the list, at least not mentioned > explicitly, I'm hoping that the change was inadvertent. Of course, if > there are other such examples I'd be very interested to learn of them. > > Thanks, > Matt > > > a long time ago ; before emacs had character.h most people decided that > characters where assumed EQL. I don't know if this helps or not. this > unicode is a terrible concept. it keeps changing. linux used to use a > representation that was similiar to BSD compression. i don't have the code > here though... > > > I do remember a consideration for modifier bits or character "attributes". > I wonder if we could just use 4 octets in place of these character > attributes. I don't know unicode but 4-bytes per char can be simple. > > however I still feel as though base-char or character should be one of 95 > ASCII glyphs. > > > this is such a big deal my linux kernel has unicode translation and the > fonts I use also have these enormous amounts of useless data; but what > about 128? > > > i have some code dedicated to character-p being 128 printing characters. > > > your request is a good one in a murkey area - IMHO. > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: steve g. <sgo...@gm...> - 2024-03-04 03:44:48
|
On 3/2/24 10:32, Matt Kaufmann wrote: > Hi, > > In SBCL 2.4.2, standard-char-p no longer returns t on a standard > character input. Apparently it now returns that input, as defined in > file src/code/target-char.lisp of the SBCL 2.4.2 source distribution. > This behavior is of course Common Lisp compliant, since every value is > a so-called generalized Boolean. That said, our ACL2 development has > assumed for more than 30 years that predicates return Booleans except > when specified otherwise, like member (not looking here for an > argument about whether that assumption was proper) -- and we've never > seen that assumption violated by any Common Lisp implementation that > can host ACL2 (currently 6 of them, including SBCL). So, I'll ask: > > Might that change be reversed in the next SBCL release? > > Since the change wasn't mentioned in the "changes in sbcl-2.4.2 > relative to sbcl-2.4.1" emailed to the list, at least not mentioned > explicitly, I'm hoping that the change was inadvertent. Of course, if > there are other such examples I'd be very interested to learn of them. > > Thanks, > Matt a long time ago ; before emacs had character.h most people decided that characters where assumed EQL. I don't know if this helps or not. this unicode is a terrible concept. it keeps changing. linux used to use a representation that was similiar to BSD compression. i don't have the code here though... I do remember a consideration for modifier bits or character "attributes". I wonder if we could just use 4 octets in place of these character attributes. I don't know unicode but 4-bytes per char can be simple. however I still feel as though base-char or character should be one of 95 ASCII glyphs. this is such a big deal my linux kernel has unicode translation and the fonts I use also have these enormous amounts of useless data; but what about 128? i have some code dedicated to character-p being 128 printing characters. your request is a good one in a murkey area - IMHO. |
From: Matt K. <mat...@gm...> - 2024-03-03 21:40:01
|
I appreciate the replies and the update. Regards, Matt On Sat, Mar 2, 2024 at 12:05 PM Stas Boukarev <sta...@gm...> wrote: > And the change to standard-char-p actually made type derivation > worse, (truly-the base-char char) didn't derive the char to base-char (it > was removed as unused). > The new constraints make either version derive to STANDARD-CHAR. So I'll > change it back to returning BOOLEAN. > > On Sat, Mar 2, 2024 at 8:27 PM Stas Boukarev <sta...@gm...> wrote: > >> Ok, I rectified that part. >> >> On Sat, Mar 2, 2024 at 7:58 PM Stas Boukarev <sta...@gm...> wrote: >> >>> It seems to solve the problem of >>> (when (< (char-code x) 100) >>> x) ; => base-char. >>> but not in a general way. >>> >>> On Sat, Mar 2, 2024 at 7:56 PM Douglas Katzman <do...@go...> wrote: >>> >>>> >>>> >>>> On Sat, Mar 2, 2024 at 11:50 AM Stas Boukarev <sta...@gm...> >>>> wrote: >>>> >>>>> Is the better code only for the out-of-line function or does it have >>>>> any difference when inlined? >>>>> >>>>> If affects both. So while we could say that the full-called version >>>> returns a strict boolean (because the wrapper stub forces T/NIL), that >>>> would be really weird obscure policy-sensitive behavior >>>> >>> |
From: Stas B. <sta...@gm...> - 2024-03-02 18:06:05
|
And the change to standard-char-p actually made type derivation worse, (truly-the base-char char) didn't derive the char to base-char (it was removed as unused). The new constraints make either version derive to STANDARD-CHAR. So I'll change it back to returning BOOLEAN. On Sat, Mar 2, 2024 at 8:27 PM Stas Boukarev <sta...@gm...> wrote: > Ok, I rectified that part. > > On Sat, Mar 2, 2024 at 7:58 PM Stas Boukarev <sta...@gm...> wrote: > >> It seems to solve the problem of >> (when (< (char-code x) 100) >> x) ; => base-char. >> but not in a general way. >> >> On Sat, Mar 2, 2024 at 7:56 PM Douglas Katzman <do...@go...> wrote: >> >>> >>> >>> On Sat, Mar 2, 2024 at 11:50 AM Stas Boukarev <sta...@gm...> >>> wrote: >>> >>>> Is the better code only for the out-of-line function or does it have >>>> any difference when inlined? >>>> >>>> If affects both. So while we could say that the full-called version >>> returns a strict boolean (because the wrapper stub forces T/NIL), that >>> would be really weird obscure policy-sensitive behavior >>> >> |
From: Stas B. <sta...@gm...> - 2024-03-02 17:28:21
|
Ok, I rectified that part. On Sat, Mar 2, 2024 at 7:58 PM Stas Boukarev <sta...@gm...> wrote: > It seems to solve the problem of > (when (< (char-code x) 100) > x) ; => base-char. > but not in a general way. > > On Sat, Mar 2, 2024 at 7:56 PM Douglas Katzman <do...@go...> wrote: > >> >> >> On Sat, Mar 2, 2024 at 11:50 AM Stas Boukarev <sta...@gm...> wrote: >> >>> Is the better code only for the out-of-line function or does it have any >>> difference when inlined? >>> >>> If affects both. So while we could say that the full-called version >> returns a strict boolean (because the wrapper stub forces T/NIL), that >> would be really weird obscure policy-sensitive behavior >> > |
From: Stas B. <sta...@gm...> - 2024-03-02 16:59:00
|
It seems to solve the problem of (when (< (char-code x) 100) x) ; => base-char. but not in a general way. On Sat, Mar 2, 2024 at 7:56 PM Douglas Katzman <do...@go...> wrote: > > > On Sat, Mar 2, 2024 at 11:50 AM Stas Boukarev <sta...@gm...> wrote: > >> Is the better code only for the out-of-line function or does it have any >> difference when inlined? >> >> If affects both. So while we could say that the full-called version > returns a strict boolean (because the wrapper stub forces T/NIL), that > would be really weird obscure policy-sensitive behavior > |
From: Douglas K. <do...@go...> - 2024-03-02 16:56:25
|
On Sat, Mar 2, 2024 at 11:50 AM Stas Boukarev <sta...@gm...> wrote: > Is the better code only for the out-of-line function or does it have any > difference when inlined? > > If affects both. So while we could say that the full-called version returns a strict boolean (because the wrapper stub forces T/NIL), that would be really weird obscure policy-sensitive behavior |
From: Stas B. <sta...@gm...> - 2024-03-02 16:50:38
|
Is the better code only for the out-of-line function or does it have any difference when inlined? On Sat, Mar 2, 2024 at 7:44 PM Douglas Katzman via Sbcl-help < sbc...@li...> wrote: > > > On Sat, Mar 2, 2024 at 10:33 AM Matt Kaufmann < > mat...@gm...> wrote: > >> I'm hoping that the change was inadvertent. >> > No, the change description says "Generate better code" > I concur the NEWS file could have said "minor incompatible change" but did > not. > > >> Might that change be reversed in the next SBCL release? >> >> I personally don't find the argument that "If the compiler *could* > generate worse code, then it *should* generate worse code" very > compelling. > It's an interesting assumption that ACL2 is making, considering that this > is literally the purpose of having defined "generalized boolean" in the > CLHS glossary. > > >> >> if there are other such examples I'd be very interested to learn of them. >> > Subsequently I would assume that any predicate returns a *generalized > boolean*, e.g. PATHNAMEP and NUMBERP could return the input. > Maybe the SBCL release maintainer will prefer strict boolean everywhere, > and/or revert the one offending change, I don't know. But either way you'd > be safe. > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |
From: Douglas K. <do...@go...> - 2024-03-02 16:43:00
|
On Sat, Mar 2, 2024 at 10:33 AM Matt Kaufmann <mat...@gm...> wrote: > I'm hoping that the change was inadvertent. > No, the change description says "Generate better code" I concur the NEWS file could have said "minor incompatible change" but did not. > Might that change be reversed in the next SBCL release? > > I personally don't find the argument that "If the compiler *could* generate worse code, then it *should* generate worse code" very compelling. It's an interesting assumption that ACL2 is making, considering that this is literally the purpose of having defined "generalized boolean" in the CLHS glossary. > > if there are other such examples I'd be very interested to learn of them. > Subsequently I would assume that any predicate returns a *generalized boolean*, e.g. PATHNAMEP and NUMBERP could return the input. Maybe the SBCL release maintainer will prefer strict boolean everywhere, and/or revert the one offending change, I don't know. But either way you'd be safe. |
From: Matt K. <mat...@gm...> - 2024-03-02 15:32:56
|
Hi, In SBCL 2.4.2, standard-char-p no longer returns t on a standard character input. Apparently it now returns that input, as defined in file src/code/target-char.lisp of the SBCL 2.4.2 source distribution. This behavior is of course Common Lisp compliant, since every value is a so-called generalized Boolean. That said, our ACL2 development has assumed for more than 30 years that predicates return Booleans except when specified otherwise, like member (not looking here for an argument about whether that assumption was proper) -- and we've never seen that assumption violated by any Common Lisp implementation that can host ACL2 (currently 6 of them, including SBCL). So, I'll ask: Might that change be reversed in the next SBCL release? Since the change wasn't mentioned in the "changes in sbcl-2.4.2 relative to sbcl-2.4.1" emailed to the list, at least not mentioned explicitly, I'm hoping that the change was inadvertent. Of course, if there are other such examples I'd be very interested to learn of them. Thanks, Matt |
From: Grégory V. <g.v...@gm...> - 2024-02-29 10:43:31
|
Hello, Just for information, even if better can be done, I finally ended with managing unreferenced memory with a sb-concurrency:queue that I populate through sb-ext:finalize and handle in the main process to delete necessary stuff in Julia. That works like a charm. All the best, - Greg Le ven. 23 févr. 2024 à 11:11, Grégory Vanuxem <g.v...@gm...> a écrit : > > First, thanks to Phoe and you, for taking the time to respond. > > But to respond to you, it's not possible as far as I know, the > dictionaries are on the Julia side. Working with "interpreter based" > applications from another application is never easy I find. For a > quick glance, here is the Julia interface: > https://docs.julialang.org/en/v1/manual/embedding/#Embedding-Julia > > Basically, you have two options, you "import", at startup for example, > the functions you need and use it via jl_call[1-*](thefunction, *args) > or you use a generic string evaluation that will be parsed and > interpreted. The two will return a generic value that you'll unbox to > fit C need. > > Yesterday I tried to use the 'delete!' function but I need to call it > via jl_call1(del, "123456789") (1 argument). I also tried via string > parsing. > > For now, I continue what I was doing with another CL implementation, > but I continue to think about that, I really want to use SBCL. In this > regard I have a question, on SBCL, threads are somewhat similar to > generic threads, right? What I mean here is, different threads, here > the finalizers and the main process, share the same address space? > What I have in mind right now, for example, that should be doable, is > to use a global/shared pool, FIFO why not, and let the finalizer > having write access to add references to no longer referenced > variables and the main process using it via a scheduler or whatever to > manage it and delete the unnecessary entries to let Julia retrieve > allocated memory. It may be silly, I have no fixed idea for now. > > Regards, > > - Greg > > > Le ven. 23 févr. 2024 à 09:44, Stas Boukarev <sta...@gm...> a écrit : > > > > Don't call jl functions, erase the reference to your object and let the julia gc delete it? > > > > On Fri, Feb 23, 2024 at 4:38 AM Grégory Vanuxem <g.v...@gm...> wrote: > >> > >> The problem is apparently more complex than I thought. The finalizer > >> runs in another thread, right? > >> > >> And from the Julia documentation: > >> =============================================== > >> Thread-safety > >> > >> In general, the Julia C API is not fully thread-safe. When embedding > >> Julia in a multi-threaded application care needs to be taken not to > >> violate the following restrictions: > >> > >> jl_init() may only be called once in the application life-time. The > >> same applies to jl_atexit_hook(), and it may only be called after > >> jl_init(). > >> jl_...() API functions may only be called from the thread in which > >> jl_init() was called, or from threads started by the Julia runtime. > >> Calling Julia API functions from user-started threads is not > >> supported, and may lead to undefined behaviour and crashes. > >> > >> The second condition above implies that you can not safely call > >> jl_...() functions from threads that were not started by Julia (the > >> thread calling jl_init() being the exception). For example, the > >> following is not supported and will most likely segfault: > >> ================================================ > >> > >> So other work needs to be done. > >> > >> - Greg > >> > >> Le jeu. 22 févr. 2024 à 15:05, Grégory Vanuxem <g.v...@gm...> a écrit : > >> > > >> > Hello, > >> > > >> > I have a problem with the SBCL finalizer. I do not master it at all. > >> > > >> > I explain, I have a very simple class to keep a "trace" of variables > >> > allocated in another application, here Julia. Its definition: > >> > > >> > (defclass jlref () > >> > ((id :accessor jlrefId :initarg :id) > >> > (val :accessor jlrefVal :initarg :val) > >> > (type :reader jlrefType :initarg :type)) > >> > (:default-initargs :id nil :type nil :val nil)) > >> > > >> > When _my_ variable (on SBCL) is no longer referenced, what I need is > >> > to let Julia, on its side, garbage collect its memory allocation when > >> > necessary. So I want to use the SBCL GC finalizer mechanism. But bad > >> > things happen. I have spent some time trying to figure out why I > >> > always encounter issues, SBCL's messages are somehow cryptic to me > >> > sometimes. I tried different ways to let Julia reclaims its memory > >> > allocation without success. So, no shame, I ask here. > >> > > >> > To create an instance I use the following code (I am a bad CL coder I think): > >> > > >> > ============================================== > >> > (defun |make_jlref| (str type) > >> > (let* ((hash (write-to-string (random most-positive-fixnum))) ; base 16? > >> > (id (|jl_setindex_wrap_eval_string| 0 hash str)) > >> > (val (|jl_getindex_wrapped_hash| 0 hash)) > >> > (ret (make-instance 'jlref :type type :id id :val val))) > >> > #+:lispworks (flag-special-free-action hash) > >> > #+:cmu (ext:finalize ret (lambda () (free_jlref hash))) > >> > #+:sbcl (sb-ext:finalize ret (lambda () > >> > (sb-alien:alien-funcall > >> > (sb-alien::extern-alien "jl_delete_wrapped_hash" > >> > (sb-alien::function sb-alien::void > >> > (sb-alien::integer) > >> > (sb-alien::c-string))) 0 hash))) > >> > #+:allegro (excl:schedule-finalization ret (lambda () > >> > (free_jlref hash))) > >> > ret)) > >> > > >> > (defun free_jlref (hash) > >> > (progn > >> > (format t "freeing... ~x~%" hash) > >> > ; #+:sbcl (sb-ext:finalize ret (lambda () > >> > ; (sb-alien:alien-funcall > >> > ; (sb-alien::extern-alien "jl_delete_wrapped_hash" > >> > ; (sb-alien::function sb-alien::void > >> > ; (sb-alien::integer) > >> > ; (sb-alien::c-string))) 0 hash))) > >> > ; Dirty hack but for an unknown reason the following does not work. > >> > (|jl_delete_wrapped_hash| 0 hash))) > >> > ;jl_eval_string((concatenate 'string "delete!(refs,\"" hash "\")")))) > >> > ================================================= > >> > > >> > Basically, I create an object on the Julia side and store it in a > >> > dictionary to prevent the Julia garbage collector from acting on it. > >> > > >> > So now here come my problems: > >> > If I use the "actual" code, here is what I obtain: > >> > =============================================== > >> > #<SB-SYS:MEMORY-FAULT-ERROR {1001D888F3}> > >> > CORRUPTION WARNING in SBCL pid 27916 tid 27917: > >> > Memory fault at 0x10 (pc=0x7f8c85e2d5ed, fp=0x7f8c86c0e760, > >> > sp=0x7f8c86c0e740) tid 27917 > >> > The integrity of this image is possibly compromised. > >> > Continuing with fingers crossed. > >> > WARNING: > >> > Error calling finalizer #<FUNCTION (LAMBDA () > >> > :IN > >> > |make_jlref|) {10021B333B}>: > >> > > >> > WARNING: > >> > Error calling finalizer #<FUNCTION (LAMBDA () :IN |make_jlref|) {54F7DC8B}>: > >> > #<SB-INT:COMPILED-PROGRAM-ERROR {1001D97EF3}> > >> > ========================================== > >> > etc. > >> > > >> > In the previous code, below you can see I have two other solutions, > >> > but I guess I am coding wrong so the error is, for example: > >> > > >> > WARNING: > >> > Error calling finalizer #<FUNCTION (LAMBDA () :IN |make_jlref|) {54F7DC6B}>: > >> > #<SB-INT:COMPILED-PROGRAM-ERROR {1001DA1473}> > >> > > >> > > >> > And If I load the code (instead of compiling it), the memory is > >> > retrieved on the SBCL side but the finalizer whatever it is (the three > >> > solutions) is never called apparently. > >> > > >> > Don't know if I am clear. > >> > > >> > Regards, > >> > > >> > - Greg > >> > > >> > PS: of course I force the GC to do a full GC for testing purposes. > >> > >> > >> _______________________________________________ > >> Sbcl-help mailing list > >> Sbc...@li... > >> https://lists.sourceforge.net/lists/listinfo/sbcl-help |
From: Michał p. H. <ph...@di...> - 2024-02-26 17:50:56
|
No, SBCL doesn't have to detect deadlocks, but in this case we get a false positive without a chance to opt out of it. https://github.com/sbcl/sbcl/blob/e5168a6f3ac86260deb22df8f6e29722e7b0eee7/src/code/target-thread.lisp#L543 offers no chance to try to continue from that point, even via CERROR. W dniu 2024-02-26 17:38, Stas Boukarev napisał(a): > Do other systems provide deadlock detection? Do we have to detect > deadlocks? > > On Mon, Feb 26, 2024 at 6:58 PM Michał Herda | Keepit via Sbcl-help > <sbc...@li...> wrote: > >> Hello, >> >> we at Keepit might have run into a situation where the >> deadlock-checking in SBCL seems overzealous in some situations because >> of a race condition in target-thread.lisp. >> >> Here's the hypothetical scenario for threads T1 T2 and mutexes M1 M2: >> >> 1. T2 grabs M2. >> 2. T1 grabs M1. >> 3. T1 starts waiting for M2 (which is locked by T2) >> 4. T1 starts checking for deadlocks. >> 5. T1 sees that M2 belongs to T2. >> 6. T2 releases M2. >> 7. T2 starts waiting for M1 (which is locked by T1). >> 8. T1 continues to check deadlocks and sees that T2 is waiting for M1. >> 9. T1 sees that M1 belongs to itself. >> 10. T1 signals a deadlock, even though M2 is now free and the code can >> proceed. >> >> Our idea of patching this behavior is to add a handler around the call >> to DETECT-DEADLOCK that, in case of signaling, reattempts to verify >> the deadlock. This resolves this particular situation in the following >> way: >> >> 11. The deadlock is handled, T1 attempts to check for deadlocks again. >> 12. T1 sees no deadlock, because M2 is now free. >> 13. T1 grabs M2. >> 14. T1 has both mutexes, does work, releases mutexes. >> >> The below patch seems to have resolved the deadlocks we've been seeing >> in our deployed application on 2.3.7. Is the above solution valid? Can >> we come up with anything better? Is it possible to avoid the situation >> where a thread T3 can grab M2 in meantime, which would lead to another >> false positive? >> >> BR, >> Michał "phoe" Herda >> >> -------------- >> >> diff --git a/src/code/target-thread.lisp b/src/code/target-thread.lisp >> index >> 795802c769f6169b664bbedc118994e81d8ef919..d25a3c6ede5ab5ba7ad26b54fce901b5a3badc55 >> 100644 >> --- a/src/code/target-thread.lisp >> +++ b/src/code/target-thread.lisp >> @@ -578,7 +578,13 @@ See also: RETURN-FROM-THREAD and SB-EXT:EXIT." >> (return-from check-deadlock nil))))))) >> ;; Timeout means there is no deadlock >> (when (mutex-p origin) >> - (detect-deadlock origin) >> + (handler-case (detect-deadlock origin) >> + (thread-deadlock () >> + ;; Double-check. If it's a true deadlock, it should stay >> + (detect-deadlock origin) >> + ;; Restore the waiting-for mark now that we know it was >> + ;; a false positive >> + (setf (thread-waiting-for self) origin))) >> t)))) >> >> ;;;; WAIT-FOR -- waiting on arbitrary conditions >> >> This e-mail is sent to you from Keepit A/S. Dedicated SaaS Data >> Protection. >> VAT: DK30806883, Per Henrik Lings Allé 4, 7., DK-2100 Copenhagen Ø, >> Denmark. >> >> This e-mail is sent to you directly and is meant for nobody else. If >> the e-mail contains personal data that Keepit is responsible for and >> the e-mail was not meant for you, please do not forward, distribute, >> or copy, i.e. but return the e-mail to sender. Also, do not send the >> e-mail to a third party without making sure that you have our prior >> consent. Distribution of this e-mail to unauthorized receivers may >> have legal consequences. >> If you have received an e-mail from us and you don't know why, then >> please refer to our Privacy Policy [1]. >> If you do not want to receive more e-mails from us, please contact >> bus...@ke.... >> _______________________________________________ >> Sbcl-help mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-help > > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help Links: ------ [1] https://www.keepit.com/privacy-policy/ |
From: Stas B. <sta...@gm...> - 2024-02-26 16:38:57
|
Do other systems provide deadlock detection? Do we have to detect deadlocks? On Mon, Feb 26, 2024 at 6:58 PM Michał Herda | Keepit via Sbcl-help < sbc...@li...> wrote: > Hello, > > we at Keepit might have run into a situation where the deadlock-checking > in SBCL seems overzealous in some situations because of a race condition in > target-thread.lisp. > > Here's the hypothetical scenario for threads T1 T2 and mutexes M1 M2: > > 1. T2 grabs M2. > 2. T1 grabs M1. > 3. T1 starts waiting for M2 (which is locked by T2) > 4. T1 starts checking for deadlocks. > 5. T1 sees that M2 belongs to T2. > 6. T2 releases M2. > 7. T2 starts waiting for M1 (which is locked by T1). > 8. T1 continues to check deadlocks and sees that T2 is waiting for M1. > 9. T1 sees that M1 belongs to itself. > 10. T1 signals a deadlock, even though M2 is now free and the code can > proceed. > > Our idea of patching this behavior is to add a handler around the call to > DETECT-DEADLOCK that, in case of signaling, reattempts to verify the > deadlock. This resolves this particular situation in the following way: > > 11. The deadlock is handled, T1 attempts to check for deadlocks again. > 12. T1 sees no deadlock, because M2 is now free. > 13. T1 grabs M2. > 14. T1 has both mutexes, does work, releases mutexes. > > The below patch seems to have resolved the deadlocks we've been seeing in > our deployed application on 2.3.7. Is the above solution valid? Can we come > up with anything better? Is it possible to avoid the situation where a > thread T3 can grab M2 in meantime, which would lead to another false > positive? > > BR, > Michał "phoe" Herda > > -------------- > > diff --git a/src/code/target-thread.lisp b/src/code/target-thread.lisp > index > 795802c769f6169b664bbedc118994e81d8ef919..d25a3c6ede5ab5ba7ad26b54fce901b5a3badc55 > 100644 > --- a/src/code/target-thread.lisp > +++ b/src/code/target-thread.lisp > @@ -578,7 +578,13 @@ See also: RETURN-FROM-THREAD and SB-EXT:EXIT." > (return-from check-deadlock nil))))))) > ;; Timeout means there is no deadlock > (when (mutex-p origin) > - (detect-deadlock origin) > + (handler-case (detect-deadlock origin) > + (thread-deadlock () > + ;; Double-check. If it's a true deadlock, it should stay > + (detect-deadlock origin) > + ;; Restore the waiting-for mark now that we know it was > + ;; a false positive > + (setf (thread-waiting-for self) origin))) > t)))) > > ;;;; WAIT-FOR -- waiting on arbitrary conditions > > > > This e-mail is sent to you from Keepit A/S. Dedicated SaaS Data Protection. > VAT: DK30806883, Per Henrik Lings Allé 4, 7., DK-2100 Copenhagen Ø, > Denmark. > > This e-mail is sent to you directly and is meant for nobody else. If the > e-mail contains personal data that Keepit is responsible for and the e-mail > was not meant for you, please do not forward, distribute, or copy, i.e. but > return the e-mail to sender. Also, do not send the e-mail to a third party > without making sure that you have our prior consent. Distribution of this > e-mail to unauthorized receivers may have legal consequences. > If you have received an e-mail from us and you don’t know why, then please > refer to our Privacy Policy <https://www.keepit.com/privacy-policy/>. > If you do not want to receive more e-mails from us, please contact > bus...@ke.... > _______________________________________________ > Sbcl-help mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-help > |