From: Gábor M. <me...@re...> - 2009-01-28 18:08:58
|
Hullo I've cleaned up a bit what's mostly my Christmas hacking branch to make commits more self contained and the progression more logical. Fetch it from the interrupts branch of my git tree [1]. For the whole list of changes see the commit log [2]. To summarize here, to interrupt handling has been cleaned up with numerous bugs fixed, lot of assertions added. No real time signals are used any more. It's possible to use timers and interrupt-thread without risking running out of stack. WITHOUT-GCING is faster. Stopping the world is faster. Added binding and alien stack exhaustion mechanism. Made SHOW in the runtime useful for debugging threading and signal related issues. Added --disable-ldb, --lose-on-corruption runtime options. On x86 linux, all tests pass, even the notorious disabled timer tests. There is no doubt that there are bugs left and even less that I have broken all other platforms and most applications in the process. For this reason I'd appreciate testers giving it a whirl and report back. Please build with ldb. When reporting problems please: - write a small test case if you can - include the backtrace from ldb ("ba 1000") - include the backtrace from gdb gdb -p <process-id> (gdb) thread apply all ba (gdb) thread apply all call backtrace_from_fp($ebp,1000) (substitute $ebp with $rbp or whatever depending on the platform) - if the problem is not obvious, please enable QSHOW, QSHOW_SAFE and QSHOW_SIGNALS, try to reproduce the problem and include the whole output - describe the platform and OS Testers with cheneygc platforms are especially welcome. Cheers, Gábor PS: the branch is subject to rebasing PS/2: x86-64 calls pthread_getspecial in arch_os_get_current_thread(), but it's not async signal safe. That could deadlock in theory. [1] http://quotenil.com/git/sbcl.git [2] http://quotenil.com/git/?p=sbcl.git;a=shortlog;h=interrupts |
From: Stas B. <sta...@gm...> - 2009-01-28 19:52:03
|
Gábor Melis <me...@re...> writes: > Hullo > > I've cleaned up a bit what's mostly my Christmas hacking branch to make > commits more self contained and the progression more logical. Fetch it > from the interrupts branch of my git tree [1]. For the whole list of > changes see the commit log [2]. > When compiling without sb-thread I get: thread.c: In function 'kill_safely': thread.c:727: error: 'thread' undeclared (first use in this function) -- With Best Regards, Stas. |
From: Gábor M. <me...@re...> - 2009-01-28 22:14:33
|
On Miércoles 28 Enero 2009, Stas Boukarev wrote: > Gábor Melis <me...@re...> writes: > > Hullo > > > > I've cleaned up a bit what's mostly my Christmas hacking branch to > > make commits more self contained and the progression more logical. > > Fetch it from the interrupts branch of my git tree [1]. For the > > whole list of changes see the commit log [2]. > > When compiling without sb-thread I get: > > thread.c: In function 'kill_safely': > thread.c:727: error: 'thread' undeclared (first use in this function) Thank you. Fixed. |
From: Cyrus H. <ch...@bo...> - 2009-01-29 02:29:47
|
Gabor, This sounds very encouraging! The following patch allows me to compile under x86/darwin: diff --git a/src/runtime/interrupt.c b/src/runtime/interrupt.c index 030cb50..05fa017 100644 --- a/src/runtime/interrupt.c +++ b/src/runtime/interrupt.c @@ -76,7 +76,8 @@ os_context_t *context = arch_os_get_context(&void_context); \ os_restore_fp_control(context); #else -#define RESTORE_FP_CONTROL_WORD(context,void_context) +#define RESTORE_FP_CONTROL_WORD(context,void_context) \ + os_context_t *context = arch_os_get_context(&void_context); #endif /* These are to be used in signal handlers. Currently all handlers are But you'll notice that I'm not restoring the fp_control_word. Not sure if we need to or not. I'll run the tests and see how it goes. thanks! Cyrus On Jan 28, 2009, at 11:04 AM, Gábor Melis wrote: > Hullo > > I've cleaned up a bit what's mostly my Christmas hacking branch to > make > commits more self contained and the progression more logical. Fetch it > from the interrupts branch of my git tree [1]. For the whole list of > changes see the commit log [2]. > > To summarize here, to interrupt handling has been cleaned up with > numerous bugs fixed, lot of assertions added. No real time signals are > used any more. It's possible to use timers and interrupt-thread > without > risking running out of stack. WITHOUT-GCING is faster. Stopping the > world is faster. Added binding and alien stack exhaustion mechanism. > Made SHOW in the runtime useful for debugging threading and signal > related issues. Added --disable-ldb, --lose-on-corruption runtime > options. > > On x86 linux, all tests pass, even the notorious disabled timer tests. > There is no doubt that there are bugs left and even less that I have > broken all other platforms and most applications in the process. > > For this reason I'd appreciate testers giving it a whirl and report > back. Please build with ldb. When reporting problems please: > - write a small test case if you can > - include the backtrace from ldb ("ba 1000") > - include the backtrace from gdb > gdb -p <process-id> > (gdb) thread apply all ba > (gdb) thread apply all call backtrace_from_fp($ebp,1000) > (substitute $ebp with $rbp or whatever depending on the platform) > - if the problem is not obvious, please enable QSHOW, QSHOW_SAFE and > QSHOW_SIGNALS, try to reproduce the problem and include the whole > output > - describe the platform and OS > > Testers with cheneygc platforms are especially welcome. > > Cheers, Gábor > > PS: the branch is subject to rebasing > PS/2: x86-64 calls pthread_getspecial in arch_os_get_current_thread(), > but it's not async signal safe. That could deadlock in theory. > > [1] http://quotenil.com/git/sbcl.git > [2] http://quotenil.com/git/?p=sbcl.git;a=shortlog;h=interrupts > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Cyrus H. <ch...@bo...> - 2009-01-29 02:46:25
|
Running all of the tests on x86/darwin gives the following results: Status: Expected failure: float.pure.lisp / (SCALE-FLOAT-OVERFLOW BUG-372) Expected failure: float.pure.lisp / (ADDITION-OVERFLOW BUG-372) Expected failure: threads.pure.lisp / WITHOUT-INTERRUPTS +CONDITION-WAIT Failure: threads.pure.lisp / SEMAPHORE-MULTIPLE-WAITERS Invalid exit status: clos-add-remove-method.impure.lisp Invalid exit status: clos-cache.impure.lisp Invalid exit status: clos-interrupts.impure.lisp Invalid exit status: compare-and-swap.impure.lisp Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353) Expected failure: debug.impure.lisp / (THROW NO-SUCH-TAG) Unhandled error dynamic-extent.impure.lisp Expected failure: external-format.impure.lisp / (CHARACTER-DECODE- LARGE FORCE-END-OF-FILE) Invalid exit status: gc.impure.lisp Invalid exit status: hash.impure.lisp Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Invalid exit status: signals.impure.lisp Invalid exit status: threads.impure.lisp Invalid exit status: timer.impure.lisp test failed, expected 104 return code, got 1 Not sure how that compares with the trunk... Cyrus On Jan 28, 2009, at 11:04 AM, Gábor Melis wrote: > Hullo > > I've cleaned up a bit what's mostly my Christmas hacking branch to > make > commits more self contained and the progression more logical. Fetch it > from the interrupts branch of my git tree [1]. For the whole list of > changes see the commit log [2]. > > To summarize here, to interrupt handling has been cleaned up with > numerous bugs fixed, lot of assertions added. No real time signals are > used any more. It's possible to use timers and interrupt-thread > without > risking running out of stack. WITHOUT-GCING is faster. Stopping the > world is faster. Added binding and alien stack exhaustion mechanism. > Made SHOW in the runtime useful for debugging threading and signal > related issues. Added --disable-ldb, --lose-on-corruption runtime > options. > > On x86 linux, all tests pass, even the notorious disabled timer tests. > There is no doubt that there are bugs left and even less that I have > broken all other platforms and most applications in the process. > > For this reason I'd appreciate testers giving it a whirl and report > back. Please build with ldb. When reporting problems please: > - write a small test case if you can > - include the backtrace from ldb ("ba 1000") > - include the backtrace from gdb > gdb -p <process-id> > (gdb) thread apply all ba > (gdb) thread apply all call backtrace_from_fp($ebp,1000) > (substitute $ebp with $rbp or whatever depending on the platform) > - if the problem is not obvious, please enable QSHOW, QSHOW_SAFE and > QSHOW_SIGNALS, try to reproduce the problem and include the whole > output > - describe the platform and OS > > Testers with cheneygc platforms are especially welcome. > > Cheers, Gábor > > PS: the branch is subject to rebasing > PS/2: x86-64 calls pthread_getspecial in arch_os_get_current_thread(), > but it's not async signal safe. That could deadlock in theory. > > [1] http://quotenil.com/git/sbcl.git > [2] http://quotenil.com/git/?p=sbcl.git;a=shortlog;h=interrupts > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Gábor M. <me...@re...> - 2009-01-29 08:46:31
|
On Jueves 29 Enero 2009, Cyrus Harmon wrote: > Running all of the tests on x86/darwin gives the following results: > > Status: > Expected failure: float.pure.lisp / (SCALE-FLOAT-OVERFLOW > BUG-372) Expected failure: float.pure.lisp / (ADDITION-OVERFLOW > BUG-372) Expected failure: threads.pure.lisp / WITHOUT-INTERRUPTS > +CONDITION-WAIT > Failure: threads.pure.lisp / SEMAPHORE-MULTIPLE-WAITERS > Invalid exit status: clos-add-remove-method.impure.lisp > Invalid exit status: clos-cache.impure.lisp > Invalid exit status: clos-interrupts.impure.lisp > Invalid exit status: compare-and-swap.impure.lisp > Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION > BUG-353) Expected failure: debug.impure.lisp / (THROW NO-SUCH-TAG) > Unhandled error dynamic-extent.impure.lisp > Expected failure: external-format.impure.lisp / > (CHARACTER-DECODE- LARGE > > FORCE-END-OF-FILE) Invalid exit status: gc.impure.lisp > Invalid exit status: hash.impure.lisp > Expected failure: packages.impure.lisp / > USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / > IMPORT-SINGLE-CONFLICT Invalid exit status: signals.impure.lisp > Invalid exit status: threads.impure.lisp > Invalid exit status: timer.impure.lisp > test failed, expected 104 return code, got 1 > > Not sure how that compares with the trunk... Courtesy of milanj: http://paste.lisp.org/display/73245. Not quite the trunk but 1.0.24. It's very similar. The only relevant difference seems to me the failure of SEMAPHORE-MULTIPLE-WAITERS in threads.pure.lisp. |
From: Gábor M. <me...@re...> - 2009-01-29 08:13:39
|
On Jueves 29 Enero 2009, Cyrus Harmon wrote: > Running all of the tests on x86/darwin gives the following results: > > Status: > Expected failure: float.pure.lisp / (SCALE-FLOAT-OVERFLOW > BUG-372) Expected failure: float.pure.lisp / (ADDITION-OVERFLOW > BUG-372) Expected failure: threads.pure.lisp / WITHOUT-INTERRUPTS > +CONDITION-WAIT > Failure: threads.pure.lisp / SEMAPHORE-MULTIPLE-WAITERS > Invalid exit status: clos-add-remove-method.impure.lisp > Invalid exit status: clos-cache.impure.lisp > Invalid exit status: clos-interrupts.impure.lisp > Invalid exit status: compare-and-swap.impure.lisp > Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION > BUG-353) Expected failure: debug.impure.lisp / (THROW NO-SUCH-TAG) > Unhandled error dynamic-extent.impure.lisp > Expected failure: external-format.impure.lisp / > (CHARACTER-DECODE- LARGE > > FORCE-END-OF-FILE) Invalid exit status: gc.impure.lisp > Invalid exit status: hash.impure.lisp > Expected failure: packages.impure.lisp / > USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / > IMPORT-SINGLE-CONFLICT Invalid exit status: signals.impure.lisp > Invalid exit status: threads.impure.lisp > Invalid exit status: timer.impure.lisp > test failed, expected 104 return code, got 1 > > Not sure how that compares with the trunk... > > Cyrus Thanks for the patch. I imagine the trunk is not so bad, or not so explicit about it at least. There are a lot of assertions about interrupt handling that can easily trip up Darwin that, I hear, does not follow the letter of posix too closely. Anyway, this is pretty long. What is the easiest way to get hold of a darwin shell, VMWare? |
From: Larry V. <re...@us...> - 2009-01-29 19:41:12
|
> Testers with cheneygc platforms are especially welcome. Not sure I got your branch properly, did: $ git-clone http://quotenil.com/git/sbcl.git $ git-checkout interrupts $ sh make.sh on hppa: Guess it needs patching at: cheneygc.c line 657 - maybe_save_gc_mask_and_block_deferrables(os_context_addr(context)); + maybe_save_gc_mask_and_block_deferrables(os_context_sigmask_addr(context)); in funcall.c move function safe_call_into_lisp above #ifdef LISP_FEATURE_C_STACK_IS_CONTROL_STACK ( or should #else LISP_FEATURE_C_STACK_IS_CONTROL_STACK clause use call_into_lisp ) And also patch load-symbol in src/compiler/hppa/macros.lisp, but that was a hppa only bug and is reported in an other mail. The errors I get below would be interesting to compare to an mips build. finally running make.sh: obj/from-xc/src/code/late-setf.lisp-obj obj/from-xc/src/code/late-format.lisp-obj obj/from-xc/src/code/sxhash.lisp-obj obj/from-xc/src/code/signal.lisp-obj obj/from-xc/src/code/late-defbangmethod.lisp-obj obj/from-xc/src/pcl/walk.lisp-obj [building initial core file in "output/cold-sbcl.core": writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY> writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC> writing 29159424 bytes [7119 pages] from #<SB!FASL::GSPACE :DYNAMIC> /(DESCRIPTOR-BITS INITIAL-FUN)=#X51AC48DD done] * //testing for consistency of first and second GENESIS passes //header files match between first and second GENESIS -- good real 12:36.2 user 10:29.5 sys 1:28.8 //entering make-target-2.sh //doing warm init - compilation phase This is SBCL 1.0.24.48.interrupts, 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. fatal error encountered in SBCL pid 1080: internal error too early in init, can't recover internal error #31 SC: 8, Offset: 20 0x00000040: even fixnum: 16 SC: 8, Offset: 14 $1= 0x5000ba4f: other pointer Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> Backtrace: <Frame 0x7abea0a0 [interrupted], CODE: 0x514CD8BF, MAKE-HASH-TABLE, <no LRA>, PC: 0xd53> <Frame 0x7abea080, CODE: 0x50965077, !TYPECHECKFUNS-COLD-INIT, LRA: 0x5096521f, PC: 0x58> <Frame 0x7abea000, CODE: 0x51AC4787, !COLD-INIT, LRA: 0x51ac4a4f, PC: 0x170> ldb> regards, /larry |
From: Gábor M. <me...@re...> - 2009-01-30 17:14:21
|
On Jueves 29 Enero 2009, Larry Valkama wrote: > > Testers with cheneygc platforms are especially welcome. > > Not sure I got your branch properly, did: > $ git-clone http://quotenil.com/git/sbcl.git > $ git-checkout interrupts > $ sh make.sh > > on hppa: > > Guess it needs patching at: > > cheneygc.c line 657 > - > maybe_save_gc_mask_and_block_deferrables(os_context_addr(context)); > + > maybe_save_gc_mask_and_block_deferrables(os_context_sigmask_addr(cont >ext)); I blame dabbrev-expand. > in funcall.c > move function safe_call_into_lisp above #ifdef > LISP_FEATURE_C_STACK_IS_CONTROL_STACK > > ( or should #else LISP_FEATURE_C_STACK_IS_CONTROL_STACK clause use > call_into_lisp ) Moved it up. > And also patch load-symbol in src/compiler/hppa/macros.lisp, but that > was a hppa only bug and is reported in an other mail. > > The errors I get below would be interesting to compare to an mips > build. > > finally running make.sh: > > obj/from-xc/src/code/late-setf.lisp-obj > obj/from-xc/src/code/late-format.lisp-obj > obj/from-xc/src/code/sxhash.lisp-obj > obj/from-xc/src/code/signal.lisp-obj > obj/from-xc/src/code/late-defbangmethod.lisp-obj > obj/from-xc/src/pcl/walk.lisp-obj > [building initial core file in "output/cold-sbcl.core": > writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY> > writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC> > writing 29159424 bytes [7119 pages] from #<SB!FASL::GSPACE :DYNAMIC> > /(DESCRIPTOR-BITS INITIAL-FUN)=#X51AC48DD > done] > * //testing for consistency of first and second GENESIS passes > //header files match between first and second GENESIS -- good > > real 12:36.2 > user 10:29.5 > sys 1:28.8 > //entering make-target-2.sh > //doing warm init - compilation phase > This is SBCL 1.0.24.48.interrupts, 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. > fatal error encountered in SBCL pid 1080: > internal error too early in init, can't recover > > internal error #31 > SC: 8, Offset: 20 0x00000040: even fixnum: 16 > SC: 8, Offset: 14 $1= 0x5000ba4f: other pointer > Welcome to LDB, a low-level debugger for the Lisp runtime > environment. ldb> Backtrace: > <Frame 0x7abea0a0 [interrupted], CODE: 0x514CD8BF, MAKE-HASH-TABLE, > <no LRA>, PC: 0xd53> > <Frame 0x7abea080, CODE: 0x50965077, !TYPECHECKFUNS-COLD-INIT, LRA: > 0x5096521f, PC: 0x58> > <Frame 0x7abea000, CODE: 0x51AC4787, !COLD-INIT, LRA: 0x51ac4a4f, PC: > 0x170> ldb> > > regards, > /larry I have no hppa box and didn't get around to try the mips, yet. But managed to get the PPC/GENCGC port functioning again. Internal error #31 is a type error. Printing 0x5000ba4f may offer clues. Thanks, Gabor |
From: Gábor M. <me...@re...> - 2009-02-05 10:46:16
|
On Jueves 29 Enero 2009, Larry Valkama wrote: > > Testers with cheneygc platforms are especially welcome. > > Not sure I got your branch properly, did: > $ git-clone http://quotenil.com/git/sbcl.git > $ git-checkout interrupts > $ sh make.sh > > on hppa: > > Guess it needs patching at: > > cheneygc.c line 657 > - > maybe_save_gc_mask_and_block_deferrables(os_context_addr(context)); > + > maybe_save_gc_mask_and_block_deferrables(os_context_sigmask_addr(cont >ext)); > > > in funcall.c > move function safe_call_into_lisp above #ifdef > LISP_FEATURE_C_STACK_IS_CONTROL_STACK > > ( or should #else LISP_FEATURE_C_STACK_IS_CONTROL_STACK clause use > call_into_lisp ) > > > And also patch load-symbol in src/compiler/hppa/macros.lisp, but that > was a hppa only bug and is reported in an other mail. > > The errors I get below would be interesting to compare to an mips > build. > > finally running make.sh: > > obj/from-xc/src/code/late-setf.lisp-obj > obj/from-xc/src/code/late-format.lisp-obj > obj/from-xc/src/code/sxhash.lisp-obj > obj/from-xc/src/code/signal.lisp-obj > obj/from-xc/src/code/late-defbangmethod.lisp-obj > obj/from-xc/src/pcl/walk.lisp-obj > [building initial core file in "output/cold-sbcl.core": > writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY> > writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC> > writing 29159424 bytes [7119 pages] from #<SB!FASL::GSPACE :DYNAMIC> > /(DESCRIPTOR-BITS INITIAL-FUN)=#X51AC48DD > done] > * //testing for consistency of first and second GENESIS passes > //header files match between first and second GENESIS -- good > > real 12:36.2 > user 10:29.5 > sys 1:28.8 > //entering make-target-2.sh > //doing warm init - compilation phase > This is SBCL 1.0.24.48.interrupts, 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. > fatal error encountered in SBCL pid 1080: > internal error too early in init, can't recover > > internal error #31 > SC: 8, Offset: 20 0x00000040: even fixnum: 16 > SC: 8, Offset: 14 $1= 0x5000ba4f: other pointer > Welcome to LDB, a low-level debugger for the Lisp runtime > environment. ldb> Backtrace: > <Frame 0x7abea0a0 [interrupted], CODE: 0x514CD8BF, MAKE-HASH-TABLE, > <no LRA>, PC: 0xd53> > <Frame 0x7abea080, CODE: 0x50965077, !TYPECHECKFUNS-COLD-INIT, LRA: > 0x5096521f, PC: 0x58> > <Frame 0x7abea000, CODE: 0x51AC4787, !COLD-INIT, LRA: 0x51ac4a4f, PC: > 0x170> ldb> > > regards, > /larry These platforms/builds now work: x86 threads x86 unithread x86-64 threads ppc gencgc ppc chenyeygc alpha All on Linux. Alpha was a major pain due to long standing bugs. I don't have the opportunity to test with other operating systems, and with HPPA, but who knows, even that may do better now. Mipsel/linux next. |
From: Gábor M. <me...@re...> - 2009-02-05 16:59:15
|
On Jueves 05 Febrero 2009, Gábor Melis wrote: > On Jueves 29 Enero 2009, Larry Valkama wrote: > > > Testers with cheneygc platforms are especially welcome. > > > > Not sure I got your branch properly, did: > > $ git-clone http://quotenil.com/git/sbcl.git > > $ git-checkout interrupts > > $ sh make.sh > > > > on hppa: > > > > Guess it needs patching at: > > > > cheneygc.c line 657 > > - > > maybe_save_gc_mask_and_block_deferrables(os_context_addr(context)); > > + > > maybe_save_gc_mask_and_block_deferrables(os_context_sigmask_addr(co > >nt ext)); > > > > > > in funcall.c > > move function safe_call_into_lisp above #ifdef > > LISP_FEATURE_C_STACK_IS_CONTROL_STACK > > > > ( or should #else LISP_FEATURE_C_STACK_IS_CONTROL_STACK clause use > > call_into_lisp ) > > > > > > And also patch load-symbol in src/compiler/hppa/macros.lisp, but > > that was a hppa only bug and is reported in an other mail. > > > > The errors I get below would be interesting to compare to an mips > > build. > > > > finally running make.sh: > > > > obj/from-xc/src/code/late-setf.lisp-obj > > obj/from-xc/src/code/late-format.lisp-obj > > obj/from-xc/src/code/sxhash.lisp-obj > > obj/from-xc/src/code/signal.lisp-obj > > obj/from-xc/src/code/late-defbangmethod.lisp-obj > > obj/from-xc/src/pcl/walk.lisp-obj > > [building initial core file in "output/cold-sbcl.core": > > writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :READ-ONLY> > > writing 4096 bytes [1 page] from #<SB!FASL::GSPACE :STATIC> > > writing 29159424 bytes [7119 pages] from #<SB!FASL::GSPACE > > :DYNAMIC> /(DESCRIPTOR-BITS INITIAL-FUN)=#X51AC48DD > > done] > > * //testing for consistency of first and second GENESIS passes > > //header files match between first and second GENESIS -- good > > > > real 12:36.2 > > user 10:29.5 > > sys 1:28.8 > > //entering make-target-2.sh > > //doing warm init - compilation phase > > This is SBCL 1.0.24.48.interrupts, 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. > > fatal error encountered in SBCL pid 1080: > > internal error too early in init, can't recover > > > > internal error #31 > > SC: 8, Offset: 20 0x00000040: even fixnum: 16 > > SC: 8, Offset: 14 $1= 0x5000ba4f: other pointer > > Welcome to LDB, a low-level debugger for the Lisp runtime > > environment. ldb> Backtrace: > > <Frame 0x7abea0a0 [interrupted], CODE: 0x514CD8BF, MAKE-HASH-TABLE, > > <no LRA>, PC: 0xd53> > > <Frame 0x7abea080, CODE: 0x50965077, !TYPECHECKFUNS-COLD-INIT, LRA: > > 0x5096521f, PC: 0x58> > > <Frame 0x7abea000, CODE: 0x51AC4787, !COLD-INIT, LRA: 0x51ac4a4f, > > PC: 0x170> ldb> > > > > regards, > > /larry > > These platforms/builds now work: > x86 threads > x86 unithread > x86-64 threads > ppc gencgc > ppc chenyeygc > alpha > > All on Linux. Alpha was a major pain due to long standing bugs. > > I don't have the opportunity to test with other operating systems, > and with HPPA, but who knows, even that may do better now. > > Mipsel/linux next. Mipsel/linux runs without a hitch. Finished running tests. Status: Unhandled error compiler.pure.lisp Expected failure: float.pure.lisp / NAN-COMPARISONS Unhandled error callback.impure.lisp Failure: compiler.impure.lisp / NESTED-INLINE-CALLS Failure: compiler.impure.lisp / NESTED-MAYBE-INLINE-CALLS Failure: compiler.impure.lisp / INLINE-CALLS Failure: compiler.impure.lisp / MAYBE-INLINE-CALLS Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346) Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353) Unexpected success: debug.impure.lisp / (THROW NO-SUCH-TAG) Expected failure: debug.impure.lisp / (TRACE ENCAPSULATE NIL) Expected failure: debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL) Failure: defstruct.impure.lisp / RAW-SLOT-EQUALP Expected failure: external-format.impure.lisp / (CHARACTER-DECODE-LARGE FORCE-END-OF-FILE) Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Expected failure: step.impure.lisp / STEP-START-FROM-BREAK Unhandled error stream.impure.lisp Unhandled error stream.impure.lisp Unhandled error stream.impure.lisp It takes ages to compile anyone has test results for a recent mipsel/linux build? |
From: Nikodemus S. <nik...@ra...> - 2009-02-05 11:12:55
|
2009/1/29 Gábor Melis <me...@re...>: Re these ones: >> Invalid exit status: clos-add-remove-method.impure.lisp >> Invalid exit status: clos-cache.impure.lisp >> Invalid exit status: clos-interrupts.impure.lisp >> Invalid exit status: compare-and-swap.impure.lisp >> Unhandled error dynamic-extent.impure.lisp >> Invalid exit status: gc.impure.lisp >> Invalid exit status: hash.impure.lisp >> Invalid exit status: signals.impure.lisp >> Invalid exit status: threads.impure.lisp >> Invalid exit status: timer.impure.lisp > I imagine the trunk is not so bad, or not so explicit about it at least. I suspect most of the invalid exist statuses from impure tests are due to thread-stack-freeing not interacting properly with fork() on Darwin (threads.pure.lisp leaves a thread stack or few lying around that gets released by multiple threads in later threaded tests -- or something like that). What are the results if you do mv thread.pure.lisp threads-1.impure.lisp and run the tests again? (So no threads are spawned in the parent image.) Also, I know I've seen the dynamic-extent.impure.lisp failure on threaded Darwin before: some interaction between threads and DX on Darwin, I believe. (Consing in a WITH-SPINLOCK, or something like that.) Cheers, -- Nikodemus |
From: Gábor M. <me...@re...> - 2009-02-05 12:21:55
|
On Jueves 05 Febrero 2009, Nikodemus Siivola wrote: > 2009/1/29 Gábor Melis <me...@re...>: > > Re these ones: > >> Invalid exit status: clos-add-remove-method.impure.lisp > >> Invalid exit status: clos-cache.impure.lisp > >> Invalid exit status: clos-interrupts.impure.lisp > >> Invalid exit status: compare-and-swap.impure.lisp > >> Unhandled error dynamic-extent.impure.lisp > >> Invalid exit status: gc.impure.lisp > >> Invalid exit status: hash.impure.lisp > >> Invalid exit status: signals.impure.lisp > >> Invalid exit status: threads.impure.lisp > >> Invalid exit status: timer.impure.lisp > > > > I imagine the trunk is not so bad, or not so explicit about it at > > least. > > I suspect most of the invalid exist statuses from impure tests are > due to thread-stack-freeing not interacting properly with fork() on > Darwin (threads.pure.lisp leaves a thread stack or few lying around > that gets released by multiple threads in later threaded tests -- or > something like that). What are the results if you do How threads and fork interact is "described" here: http://www.opengroup.org/onlinepubs/009695399/functions/fork.html "A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. " The consequently part seems unnecessarily restrictive, but who knows what a kernel may decide to keep around that's used in the implementation of non-async-signal-safe functions. I'm not sure I buy this, but this guy did: https://bugzilla.redhat.com/show_bug.cgi?id=169838 (at the bottom). Although the test case does not work anymore ... |
From: Nikodemus S. <nik...@ra...> - 2009-02-05 14:56:20
|
2009/2/5 Gábor Melis <me...@re...>: >> I suspect most of the invalid exist statuses from impure tests are >> due to thread-stack-freeing not interacting properly with fork() on >> Darwin (threads.pure.lisp leaves a thread stack or few lying around >> that gets released by multiple threads in later threaded tests -- or >> something like that). What are the results if you do > How threads and fork interact is "described" here: > http://www.opengroup.org/onlinepubs/009695399/functions/fork.html Sorry, I was unclear. I believe the culprit is the DELAY_THREAD_POST_MORTEM stuff in thread.c not being fork() aware. There may be other problems as well, but I'm pretty sure that is one place that needs love: children should not inherit their parents post mortem queues, because if they do we will end up releasing thread stacks of dead threads multiple times on Darwin (once per child process assuming the child process spawns enough threads). Cheers, -- Nikodemus |
From: Gábor M. <me...@re...> - 2009-02-05 15:32:07
|
On Jueves 05 Febrero 2009, Nikodemus Siivola wrote: > 2009/2/5 Gábor Melis <me...@re...>: > >> I suspect most of the invalid exist statuses from impure tests are > >> due to thread-stack-freeing not interacting properly with fork() > >> on Darwin (threads.pure.lisp leaves a thread stack or few lying > >> around that gets released by multiple threads in later threaded > >> tests -- or something like that). What are the results if you do > > > > How threads and fork interact is "described" here: > > http://www.opengroup.org/onlinepubs/009695399/functions/fork.html > > Sorry, I was unclear. > > I believe the culprit is the DELAY_THREAD_POST_MORTEM stuff in > thread.c not being fork() aware. There may be other problems as well, > but I'm pretty sure that is one place that needs love: children > should not inherit their parents post mortem queues, because if they > do we will end up releasing thread stacks of dead threads multiple > times on Darwin (once per child process assuming the child process > spawns enough threads). I'm sorry. You were quite clear I just brought this up because it was somewhat related ... > Cheers, > > -- Nikodemus |
From: Faré <fa...@gm...> - 2009-02-05 15:25:51
|
2009/2/5 Gábor Melis <me...@re...>: > On Jueves 05 Febrero 2009, Nikodemus Siivola wrote: >> 2009/1/29 Gábor Melis <me...@re...>: >> >> Re these ones: >> >> Invalid exit status: clos-add-remove-method.impure.lisp >> >> Invalid exit status: clos-cache.impure.lisp >> >> Invalid exit status: clos-interrupts.impure.lisp >> >> Invalid exit status: compare-and-swap.impure.lisp >> >> Unhandled error dynamic-extent.impure.lisp >> >> Invalid exit status: gc.impure.lisp >> >> Invalid exit status: hash.impure.lisp >> >> Invalid exit status: signals.impure.lisp >> >> Invalid exit status: threads.impure.lisp >> >> Invalid exit status: timer.impure.lisp >> > >> > I imagine the trunk is not so bad, or not so explicit about it at >> > least. >> >> I suspect most of the invalid exist statuses from impure tests are >> due to thread-stack-freeing not interacting properly with fork() on >> Darwin (threads.pure.lisp leaves a thread stack or few lying around >> that gets released by multiple threads in later threaded tests -- or >> something like that). What are the results if you do > > How threads and fork interact is "described" here: > http://www.opengroup.org/onlinepubs/009695399/functions/fork.html > > "A process shall be created with a single thread. If a multi-threaded > process calls fork(), the new process shall contain a replica of the > calling thread and its entire address space, possibly including the > states of mutexes and other resources. Consequently, to avoid errors, > the child process may only execute async-signal-safe operations until > such time as one of the exec functions is called. " > > The consequently part seems unnecessarily restrictive, but who knows > what a kernel may decide to keep around that's used in the > implementation of non-async-signal-safe functions. I'm not sure I buy > this, but this guy did: > https://bugzilla.redhat.com/show_bug.cgi?id=169838 (at the bottom). > Although the test case does not work anymore ... > Remember that you have to deal not just with the state kernel-side, but the state in all of your runtime, and the runtime of each and every of the libraries that are presently loaded. If you really want to do some non-trivial work on the child side before it calls execve or without calling it, you may want to hold some kind of lock before you fork to all the resources that you may need in the child, and to reinitialize the state of all mutexes, threads, etc., provide hooks for libraries to do the same, and play well with pthread_atfork. It's not impossible, but it's mind-boggling, and likely to trigger many lurking bugs and lack of reinitialization feature in various libraries. Not a good expected bang per buck. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Suicidal terrorists may have short shelf lives. -- John McCarthy |
From: Gábor M. <me...@re...> - 2009-02-05 15:56:36
|
On Jueves 05 Febrero 2009, Faré wrote: > 2009/2/5 Gábor Melis <me...@re...>: > > On Jueves 05 Febrero 2009, Nikodemus Siivola wrote: > >> 2009/1/29 Gábor Melis <me...@re...>: > >> > >> Re these ones: > >> >> Invalid exit status: clos-add-remove-method.impure.lisp > >> >> Invalid exit status: clos-cache.impure.lisp > >> >> Invalid exit status: clos-interrupts.impure.lisp > >> >> Invalid exit status: compare-and-swap.impure.lisp > >> >> Unhandled error dynamic-extent.impure.lisp > >> >> Invalid exit status: gc.impure.lisp > >> >> Invalid exit status: hash.impure.lisp > >> >> Invalid exit status: signals.impure.lisp > >> >> Invalid exit status: threads.impure.lisp > >> >> Invalid exit status: timer.impure.lisp > >> > > >> > I imagine the trunk is not so bad, or not so explicit about it > >> > at least. > >> > >> I suspect most of the invalid exist statuses from impure tests are > >> due to thread-stack-freeing not interacting properly with fork() > >> on Darwin (threads.pure.lisp leaves a thread stack or few lying > >> around that gets released by multiple threads in later threaded > >> tests -- or something like that). What are the results if you do > > > > How threads and fork interact is "described" here: > > http://www.opengroup.org/onlinepubs/009695399/functions/fork.html > > > > "A process shall be created with a single thread. If a > > multi-threaded process calls fork(), the new process shall contain > > a replica of the calling thread and its entire address space, > > possibly including the states of mutexes and other resources. > > Consequently, to avoid errors, the child process may only execute > > async-signal-safe operations until such time as one of the exec > > functions is called. " > > > > The consequently part seems unnecessarily restrictive, but who > > knows what a kernel may decide to keep around that's used in the > > implementation of non-async-signal-safe functions. I'm not sure I > > buy this, but this guy did: > > https://bugzilla.redhat.com/show_bug.cgi?id=169838 (at the bottom). > > Although the test case does not work anymore ... > > Remember that you have to deal not just with the state kernel-side, > but the state in all of your runtime, and the runtime of each and > every of the libraries that are presently loaded. > > If you really want to do some non-trivial work on the child side > before it calls execve or without calling it, you may want to hold > some kind of lock before you fork to all the resources that you may > need in the child, and to reinitialize the state of all mutexes, > threads, etc., provide hooks for libraries to do the same, and play > well with pthread_atfork. It's not impossible, but it's > mind-boggling, and likely to trigger many lurking bugs and lack of > reinitialization feature in various libraries. Not a good expected > bang per buck. What I was thinking is that one could in theory stop all threads at safe randezvous points with a single locking primitive, say a semaphore and forking should become safe to do. Granted, taking unwind-protect cleanups into account, in Lisp this kind of safe point could only exist very near the bottom of stack rendering it effectively equivalent to killing all the others threads. But in C, within a single application that point about only async-signal-safe function being allowed is worded too strongly. Because this text is intended to be authoritive it grates on me, it's similar to the careless definition of async-signal-safety: they could have said that it's allowed to call all functions from signal handlers as long as the signal in question does not interrupt a non-async-signal-safe function (with little or no additional constraint on their implementation), instead they declare a small number of them safe and keep silent on all the others ... Anyway, for SBCL this does not matter much, perhaps there could be a warning from sb-posix:fork() when there is more than one thread. > [ François-René ÐVB Rideau | Reflection&Cybernethics | > http://fare.tunes.org ] Suicidal terrorists may have short shelf > lives. -- John McCarthy |
From: Gábor M. <me...@re...> - 2009-02-06 15:36:17
|
On Miércoles 28 Enero 2009, Gábor Melis wrote: > Hullo > > I've cleaned up a bit what's mostly my Christmas hacking branch to > make commits more self contained and the progression more logical. > Fetch it from the interrupts branch of my git tree [1]. For the whole > list of changes see the commit log [2]. > > To summarize here, to interrupt handling has been cleaned up with > numerous bugs fixed, lot of assertions added. No real time signals > are used any more. It's possible to use timers and interrupt-thread > without risking running out of stack. WITHOUT-GCING is faster. > Stopping the world is faster. Added binding and alien stack > exhaustion mechanism. Made SHOW in the runtime useful for debugging > threading and signal related issues. Added --disable-ldb, > --lose-on-corruption runtime options. > > On x86 linux, all tests pass, even the notorious disabled timer > tests. There is no doubt that there are bugs left and even less that > I have broken all other platforms and most applications in the > process. > > For this reason I'd appreciate testers giving it a whirl and report > back. Please build with ldb. When reporting problems please: > - write a small test case if you can > - include the backtrace from ldb ("ba 1000") > - include the backtrace from gdb > gdb -p <process-id> > (gdb) thread apply all ba > (gdb) thread apply all call backtrace_from_fp($ebp,1000) > (substitute $ebp with $rbp or whatever depending on the platform) > - if the problem is not obvious, please enable QSHOW, QSHOW_SAFE and > QSHOW_SIGNALS, try to reproduce the problem and include the whole > output > - describe the platform and OS > > Testers with cheneygc platforms are especially welcome. > > Cheers, Gábor > > PS: the branch is subject to rebasing > PS/2: x86-64 calls pthread_getspecial in > arch_os_get_current_thread(), but it's not async signal safe. That > could deadlock in theory. > > [1] http://quotenil.com/git/sbcl.git > [2] http://quotenil.com/git/?p=sbcl.git;a=shortlog;h=interrupts I've rebased the interrupts branch onto 1.0.25.10 and some effort was spent on producing a good history, cleaning up fixes, squashing, reordering commits as needed. Hence, this would go in commit by commit. The testing that I can do has been done. MIPSel, Alpha, x86, x86-64, ppc are verified to work with Linux. No testing was done on Sparc and with non-linux OSes. I'm planning to commit it in a week, until then you may want to test some of the untested builds: - anything with *BSD - WIN32 - Sparc - HPPA Cheers, Gabor |
From: Cyrus H. <ch...@bo...> - 2009-02-06 22:09:47
|
I've been seeing this on Darwin: ... ::: Running (:BACKTRACE) fatal error encountered in SBCL pid 49494(tid 8447488): fault in heap page 7845 not marked as write-protected boxed_region.first_page: 0, boxed_region.last_page -1 Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> On Feb 6, 2009, at 7:36 AM, Gábor Melis wrote: > On Miércoles 28 Enero 2009, Gábor Melis wrote: >> Hullo >> >> I've cleaned up a bit what's mostly my Christmas hacking branch to >> make commits more self contained and the progression more logical. >> Fetch it from the interrupts branch of my git tree [1]. For the whole >> list of changes see the commit log [2]. >> >> To summarize here, to interrupt handling has been cleaned up with >> numerous bugs fixed, lot of assertions added. No real time signals >> are used any more. It's possible to use timers and interrupt-thread >> without risking running out of stack. WITHOUT-GCING is faster. >> Stopping the world is faster. Added binding and alien stack >> exhaustion mechanism. Made SHOW in the runtime useful for debugging >> threading and signal related issues. Added --disable-ldb, >> --lose-on-corruption runtime options. >> >> On x86 linux, all tests pass, even the notorious disabled timer >> tests. There is no doubt that there are bugs left and even less that >> I have broken all other platforms and most applications in the >> process. >> >> For this reason I'd appreciate testers giving it a whirl and report >> back. Please build with ldb. When reporting problems please: >> - write a small test case if you can >> - include the backtrace from ldb ("ba 1000") >> - include the backtrace from gdb >> gdb -p <process-id> >> (gdb) thread apply all ba >> (gdb) thread apply all call backtrace_from_fp($ebp,1000) >> (substitute $ebp with $rbp or whatever depending on the platform) >> - if the problem is not obvious, please enable QSHOW, QSHOW_SAFE and >> QSHOW_SIGNALS, try to reproduce the problem and include the whole >> output >> - describe the platform and OS >> >> Testers with cheneygc platforms are especially welcome. >> >> Cheers, Gábor >> >> PS: the branch is subject to rebasing >> PS/2: x86-64 calls pthread_getspecial in >> arch_os_get_current_thread(), but it's not async signal safe. That >> could deadlock in theory. >> >> [1] http://quotenil.com/git/sbcl.git >> [2] http://quotenil.com/git/?p=sbcl.git;a=shortlog;h=interrupts > > I've rebased the interrupts branch onto 1.0.25.10 and some effort was > spent on producing a good history, cleaning up fixes, squashing, > reordering commits as needed. Hence, this would go in commit by > commit. > > The testing that I can do has been done. MIPSel, Alpha, x86, x86-64, > ppc > are verified to work with Linux. No testing was done on Sparc and with > non-linux OSes. > > I'm planning to commit it in a week, until then you may want to test > some of the untested builds: > - anything with *BSD > - WIN32 > - Sparc > - HPPA > > Cheers, Gabor > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills > and code to > build responsive, highly engaging applications that combine the > power of local > resources and data with the reach of the web. Download the Adobe AIR > SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Gábor M. <me...@re...> - 2009-02-07 11:23:46
|
On Viernes 06 Febrero 2009, Cyrus Harmon wrote: > I've been seeing this on Darwin: > > ... > > ::: Running (:BACKTRACE) > > fatal error encountered in SBCL pid 49494(tid 8447488): > fault in heap page 7845 not marked as write-protected > boxed_region.first_page: 0, boxed_region.last_page -1 > > > Welcome to LDB, a low-level debugger for the Lisp runtime > environment. ldb> I take it builds without problems including the contribs? Backtrace from ldb and gdb may help to diagnose. Nothing that should cause this stands out to me immediately, what would help most is bisecting. That said, I think the logic in gencgc_handle_wp_violation (where this error comes from) is: - potentially subject to visibility problems on write_protected_cleared - racy because of the page is unprotected first and write_protected_cleared is set second I think the compiler is not allowed to reorder os_protect with the flag setting. Anyway, getting free_pages_lock in the else branch should help with both problems. But I don't think this is what happens in practice. Cheers, Gabor |
From: Gábor M. <me...@re...> - 2009-02-09 21:17:07
Attachments:
handle-wp.diff
|
On Sábado 07 Febrero 2009, Gábor Melis wrote: > On Viernes 06 Febrero 2009, Cyrus Harmon wrote: > > I've been seeing this on Darwin: > > > > ... > > > > ::: Running (:BACKTRACE) > > > > fatal error encountered in SBCL pid 49494(tid 8447488): > > fault in heap page 7845 not marked as write-protected > > boxed_region.first_page: 0, boxed_region.last_page -1 > > > > > > Welcome to LDB, a low-level debugger for the Lisp runtime > > environment. ldb> > > I take it builds without problems including the contribs? Backtrace > from ldb and gdb may help to diagnose. Nothing that should cause this > stands out to me immediately, what would help most is bisecting. > > That said, I think the logic in gencgc_handle_wp_violation (where > this error comes from) is: > - potentially subject to visibility problems on > write_protected_cleared - racy because of the page is unprotected > first and > write_protected_cleared is set second > > I think the compiler is not allowed to reorder os_protect with the > flag setting. > > Anyway, getting free_pages_lock in the else branch should help with > both problems. But I don't think this is what happens in practice. I still doubt that this is being triggerred, but the attached patch should allow us to see a bit more clearly. > > Cheers, Gabor |
From: Cyrus H. <ch...@bo...> - 2009-02-09 22:56:34
|
Thanks for the patch. Running with that I see: ::: Success (:INFODB :READ) infodb test done ::: Running (:BACKTRACE) fatal error encountered in SBCL pid 56816(tid 8463872): fault in heap page 6517 not marked as write-protected boxed_region.first_page: 0, boxed_region.last_page -1 Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> backtrace Backtrace: 0: Foreign function ldb_monitor, fp = 0xad59138, ra = 0x9425 1: Foreign function lose, fp = 0xad59168, ra = 0x64c1 2: Foreign function gencgc_handle_wp_violation, fp = 0xad591a8, ra = 0x1444f 3: Foreign function memory_fault_handler, fp = 0xad591c8, ra = 0xfdef 4: Foreign function signal_emulation_wrapper, fp = 0xad591e8, ra = 0x103e6 5: Foreign function os_get_runtime_executable_path, fp = 0xad59218, ra = 0xffd0 6: Foreign function os_get_runtime_executable_path, fp = 0xad595b8, ra = 0xffd0 7: SB-PRETTY::END-LOGICAL-BLOCK 8: (COMMON-LISP::FLET WITH-PRETTY-STREAM-367) 9: SB-IMPL::%PRINT-UNREADABLE-OBJECT 10: (COMMON-LISP::LABELS WITH-CIRCULARITY-DETECTION-BODY-2225) 11: (SB-C::HAIRY-ARG-PROCESSOR COMMON-LISP::PPRINT-FILL) 12: SB-PRETTY::OUTPUT-PRETTY-OBJECT 13: (SB-C::HAIRY-ARG-PROCESSOR COMMON-LISP::PRIN1) 14: SB-DEBUG::ENSURE-PRINTABLE-OBJECT 15: (COMMON-LISP::FLET WITH-PRETTY-STREAM-168) 16: (SB-C::TL-XEP SB-DEBUG::PRINT-FRAME-CALL) 17: (SB-C::TL-XEP SB-DEBUG::MAP-BACKTRACE) 18: (SB-C::HAIRY-ARG-PROCESSOR SB-DEBUG::BACKTRACE) 19: (COMMON-LISP::LAMBDA ()) 20: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[G856]862) 21: (COMMON-LISP::FLET SB-THREAD::WITH-MUTEX-THUNK) 22: (COMMON-LISP::FLET WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]448) 23: SB-THREAD::CALL-WITH-MUTEX 24: (COMMON-LISP::LAMBDA ()) 25: Foreign function call_into_lisp, fp = 0xad59f18, ra = 0x1806c 26: Foreign function funcall0, fp = 0xad59f38, ra = 0x32d6 27: Foreign function new_thread_trampoline, fp = 0xad59f78, ra = 0xe123 28: Foreign function _pthread_start, fp = 0xad59fc8, ra = 0x9215f095 29: Foreign function thread_start, fp = 0xad59fec, ra = 0x9215ef52 On Feb 9, 2009, at 1:16 PM, Gábor Melis wrote: > On Sábado 07 Febrero 2009, Gábor Melis wrote: >> On Viernes 06 Febrero 2009, Cyrus Harmon wrote: >>> I've been seeing this on Darwin: >>> >>> ... >>> >>> ::: Running (:BACKTRACE) >>> >>> fatal error encountered in SBCL pid 49494(tid 8447488): >>> fault in heap page 7845 not marked as write-protected >>> boxed_region.first_page: 0, boxed_region.last_page -1 >>> >>> >>> Welcome to LDB, a low-level debugger for the Lisp runtime >>> environment. ldb> >> >> I take it builds without problems including the contribs? Backtrace >> from ldb and gdb may help to diagnose. Nothing that should cause this >> stands out to me immediately, what would help most is bisecting. >> >> That said, I think the logic in gencgc_handle_wp_violation (where >> this error comes from) is: >> - potentially subject to visibility problems on >> write_protected_cleared - racy because of the page is unprotected >> first and >> write_protected_cleared is set second >> >> I think the compiler is not allowed to reorder os_protect with the >> flag setting. >> >> Anyway, getting free_pages_lock in the else branch should help with >> both problems. But I don't think this is what happens in practice. > > I still doubt that this is being triggerred, but the attached patch > should allow us to see a bit more clearly. > >> >> Cheers, Gabor > <handle- > wp > .diff > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills > and code to > build responsive, highly engaging applications that combine the > power of local > resources and data with the reach of the web. Download the Adobe AIR > SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com_______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Nikodemus S. <nik...@ra...> - 2009-02-17 14:29:33
|
2009/2/10 Cyrus Harmon <ch...@bo...>: > ::: Success (:INFODB :READ) > infodb test done > ::: Running (:BACKTRACE) > fatal error encountered in SBCL pid 56816(tid 8463872): > fault in heap page 6517 not marked as write-protected > boxed_region.first_page: 0, boxed_region.last_page -1 > > > Welcome to LDB, a low-level debugger for the Lisp runtime environment. > ldb> This still occurs with 1.0.25.54: I strongly suspect something funny with the Darwin/Mach stuff. On occasion I've also seen Darwin signal a SIGSEGV via handler, not the Mach magic as it's supposed to. ...but great work! Cheers, -- Nikodemus |
From: Gábor M. <me...@re...> - 2009-02-16 22:38:22
|
All linux platforms except mipsel are tested and work. I've committed the whole branch as 1.0.25.13 - 1.0.25.54. Cheers, Gábor |