From: Douglas K. <do...@go...> - 2014-08-12 02:14:10
|
I think it might be the issue I just pointed out in 800c9ca62fee092020d It's a surefire explanation for this in one of the threads: 4: Foreign function post_signal_tramp, fp = 0x7ffff5f95ea0, ra = 0x42aaa0 5: SB-KERNEL::STRING=* 6: SB-IMPL::FIND-SYMBOL* 7: SB-INT::INTERN* 8: SB-FASL::AUX-FOP-INTERN ... On Mon, Aug 11, 2014 at 9:34 PM, Douglas Katzman <do...@go...> wrote: > I would have thought '437490' ("Fix discrepancies in handling toplevel > forms") to be a more likely culprit. The parallel-load test has no > toplevel SETQ of any kind, either for a special or global var. > At least, I've gotten a test to hang on "fix discrepancies" but not on > "setq global is fopcompilable" after hundreds of iterations. > > So my guess would be that using compiler macros makes fewer things > fopcompilable which makes more things need to produce machine code, and I > think there's a probably-pre-existing threading issue that is exposed. > i.e. the comment at the top of load.lisp says "Because this code is > mutually recursive with the compiler, we use the **WORLD-LOCK**" which is > pretty clearly not true. It is touching stuff the compiler touches, but > _without_ protecting itself. > > Are you absolutely certain you could make it hang with the "setq global" > and not the next change too? > > > On Mon, Aug 11, 2014 at 8:04 PM, Jan Moringen < > jmo...@te...> wrote: > >> Hi, >> >> as reported by reb and myself in #sbcl, the test >> load.impure.lisp:parallel-fasl-load sometimes hangs when the >> sb-safepoint feature is enabled. I observed this on Linux x86 and Linux >> x86_64. It may or may not occur on MacOS (our MacOS build slave has >> become so unreliable that I had to stop using it). >> >> I bisected the problem to this commit (with some remaining uncertainty >> due to the hanging not occurring deterministically, but the previous >> commit passed the test 100 times, so is at least unlikely to be bad): >> >> commit 0ad7c5ca279e332b616666e92782ca1ec8e15f16 >> Author: Douglas Katzman <do...@go...> >> Date: Tue Jul 29 08:54:26 2014 -0400 >> >> SETQ of a :global variable is fopcompilable. >> >> These are the commits I tested more thoroughly after having formed the >> initial suspicion: >> >> bad 623d15fa9e04f958ad597ffd10b7170edbdcc87e Type-class lint >> removal >> bad 71e1bd4be8be59a647763eb346e81e32192ebcab Implement another >> atomic globaldb (INFO) primitive operation. >> bad 437490ed66172686a3f9d1d264b66fa2cfb2bb8e Fix discrepancies >> in handling toplevel forms per CLHS 3.2.3.1 >> bad 0ad7c5ca279e332b616666e92782ca1ec8e15f16 SETQ of a :global >> variable is fopcompilable. >> good 447119c2d244f6463226eac3e49d57b72df34f78 x86[-64]: fix >> %MORE-ARG-VALUES for 'skip' operand other than zero >> >> The script I used for bisecting is attached. It should be able to >> reproduce the problem, maybe after increasing the number of repetitions. >> >> Kind regards, >> Jan >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Sbcl-devel mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> >> > |