From: Rosanna B. <gu...@ac...> - 2007-05-29 14:15:15
|
<html> <body> <p>Greetings.<br> Would you be interested in a home job that allows you to earn up to $10000 per month? No start up fees, no envelope stuffing nonsense.<br> <br> We proudly present Amato Logistics Co. Ltd.<br> <br> The job we offer will not affect your present career, it will only take a small part of your time. <br> The only things you need to have to start running your business with our company are reliable Internet/E-mail access and checking/savings bank account. <br> And of course your decency and willingness to earn.<br> <br> The first vacancy is Transfer manager:<br> The nature of the job is payment processing. <br> It is related to online banking operating the funds from either our company or our partners to designated bank account approved by our <br> manager keeping specified money transaction fee as a commission for your services (usually between $150 to $500, no less than $150 per transfer).<br> <br> You will receive the funds which our customers/resellers send directly to you and forward it to us or our agents (less your commission)via one of chosen money transfer agencies.<br> The job is rather simple and you won't need any special knowledge to become our partner, though we do require that you are able to act on a very short notice. <br> We can afford to pay such a decent commission only because we keep our customers happy with our promptness.<br> <br> And the second is Shipment manager.<br> The job we offer is related to mail. It is an easy part time job that doesnt require leaving your main occupation. <br> You will be receiving mail and packages for our clients, either repack them or ship them further out following our managers instructions. <br> <br> <br> For those who look for career opportunities its a chance of becoming a part of our team in the future (based on your performance), <br> team in which you will be highly respected and decently rewarded - just think about this! We will be hoping to hear from you soon. <a href="mailto:yl...@bu...">yl...@bu...</a><br> <br> <br> If you would like to get our application form please email us with your request. No fees are asked, just leave your contact details: "random e-mail"<br> <br> Write us to: <a href="mailto:yl...@bu...">yl...@bu...</a><br> <br> We would appreciate your continued patronage and get in touch with you soon. Thank you!</p> </body> </html> |
From: Gerard R. <g.r...@fr...> - 2009-12-24 13:29:21
|
From: Gerard R. <g.r...@fr...> - 2009-12-24 13:29:26
|
From: Andrey G. G. <A.G...@in...> - 2014-04-29 03:39:51
|
A Gentoo user reports the problem compiling OpenAxiom with sbcl-1.1.17 and 1.1.16, see https://bugs.gentoo.org/show_bug.cgi?id=508990 ; compiling (DEFUN |bfOR| ...)CORRUPTION WARNING in SBCL pid 5624(tid 140737353508608): Memory fault at 0 (pc=0x100178c053, sp=0x7ffff6c8ec90) The integrity of this image is possibly compromised. Continuing with fingers crossed. CORRUPTION WARNING in SBCL pid 5624(tid 140737353508608): Memory fault at 40200066 (pc=0x100159ef30, sp=0x7ffff6c8e5a0) The integrity of this image is possibly compromised. Continuing with fingers crossed. CORRUPTION WARNING in SBCL pid 5624(tid 140737353508608): Memory fault at 40200066 (pc=0x100159ef30, sp=0x7ffff6c8dd10) The integrity of this image is possibly compromised. Continuing with fingers crossed. Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. (no restarts: If you didn't do this on purpose, please report it as a bug.) debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD "main thread" RUNNING {1002F363E3}>: Unhandled memory fault at #x40200066. Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. (no restarts: If you didn't do this on purpose, please report it as a bug.) ... I don't use OpenAxiom myself, and cannot confirm this. FriCAS is compiled successfully. Andrey |
From: Christophe R. <cs...@ca...> - 2014-04-29 05:47:21
|
Hi, "Andrey G. Grozin" <A.G...@in...> writes: > A Gentoo user reports the problem compiling OpenAxiom with sbcl-1.1.17 and > 1.1.16, see https://bugs.gentoo.org/show_bug.cgi?id=508990 I guess the user should be asked whether this is a new problem, and if so, which sbcl version is the first to trigger this behaviour, or whether something has changed in OpenAxiom to make this happen? Isolating the problem to a particular change would definitely be helpful in debugging. Cheers, Christophe |
From: Andrey G. G. <A.G...@in...> - 2014-04-29 08:55:39
|
On Tue, 29 Apr 2014, Игорь Пашев wrote: > Could it be related to portage sandbox [1, 2] ? > [1] https://bugs.gentoo.org/show_bug.cgi?id=376213 > [2] https://sourceforge.net/p/open-axiom/mailman/open-axiom-help/thread/CAA...@ma.../ Probably, it's the same problem. sbcl happily compiles FriCAS (and maxima) in the sandbox. Is OpenAxiom much larger than FriCAS? Andrey |
From: Gabriel D. R. <gd...@in...> - 2014-04-30 15:58:47
|
On Tue, Apr 29, 2014 at 1:55 AM, Andrey G. Grozin <A.G...@in...>wrote: > On Tue, 29 Apr 2014, Игорь Пашев wrote: > >> Could it be related to portage sandbox [1, 2] ? >> [1] https://bugs.gentoo.org/show_bug.cgi?id=376213 >> [2] https://sourceforge.net/p/open-axiom/mailman/open-axiom-help/thread/ >> CAA...@ma.../ >> > Probably, it's the same problem. > > sbcl happily compiles FriCAS (and maxima) in the sandbox. Is OpenAxiom > much larger than FriCAS? The error you report happens in the very early stage of building the Boot translator with just a few functions loaded. The main OpenAxiom binary isn't built yet at that time. For what it is worth, I can't reproduce the problem on Mac OS X or openSUSE. So, it must be the sandbox feature as reported in the gentoo bug database. What are the typical limits when -sandbox is in effect? PS: I don't have access to a gentoo machine so it is hard for me to reproduce the issue. -- Gaby |
From: Orivej D. <or...@gm...> - 2014-04-29 08:57:07
|
1. I can reproduce the problem. It stems from SBCL being run effectively as "sbcl --eval ... < /dev/null". When SBCL enters debugger due to an error in the build process, it reads EOF, exits with code 0, and the build continues with this happening many times until finally SBCL encounters memory fault. To fix the build process apply this to config/open-axiom.m4: @@ -333,4 +333,4 @@ sbcl) axiom_quiet_flags='--noinform --noprint' - axiom_eval_flags='--no-sysinit --no-userinit --eval' + axiom_eval_flags='--no-sysinit --no-userinit --disable-debugger --eval' ;; and rebuild ./configure with ./build-setup.sh. 2. The first actual error is this: make[2]: Entering directory '/var/tmp/portage/sci-mathematics/open-axiom-1.4.2/work/open-axiom-1.4.2/src/boot' ../../src/driver/open-axiom --execpath=../lisp/lisp --make --main="|AxiomCore|::|topLevel|"\ --system=../../x86_64-unknown-linux-gnu \ --prologue='(pushnew :open-axiom-boot *features*)' \ --output=strap/bootsys --load-directory=strap strap/utility.fasl strap/tokens.fasl strap/includer.fasl strap/scanner.fasl strap/pile.fasl strap/ast.fasl strap/parser.fasl strap/translator.fasl Unhandled SB-INT:SIMPLE-FILE-ERROR in thread #<THREAD "main thread" RUNNING {1002D149B3}>: Couldn't load "strap/utility.fasl": file does not exist. 3. I'm going to investigate the cause of memory fault, but it should not concern OpenAxiom or Gentoo. |
From: Gabriel D. R. <gd...@in...> - 2014-05-02 14:58:04
|
Orivej, On Tue, Apr 29, 2014 at 1:43 AM, Orivej Desh <or...@gm...> wrote: > 1. I can reproduce the problem. It stems from SBCL being run effectively > as "sbcl --eval ... < /dev/null". When SBCL enters debugger due to an > error in the build process, it reads EOF, exits with code 0, and the > build continues with this happening many times until finally SBCL > encounters memory fault. To fix the build process apply this to > config/open-axiom.m4: > > @@ -333,4 +333,4 @@ > sbcl) > axiom_quiet_flags='--noinform --noprint' > - axiom_eval_flags='--no-sysinit --no-userinit --eval' > + axiom_eval_flags='--no-sysinit --no-userinit > --disable-debugger --eval' > ;; > Thanks for the detective work. I missed your message earlier. Applied your addition to the 1.4.3 branch of OpenAxiom: http://sourceforge.net/p/open-axiom/code/HEAD/tree/releases/1.4.3/ [...] > 3. I'm going to investigate the cause of memory fault, but it should not > concern OpenAxiom or Gentoo. > Please, let me know if you need me to run any test, or if you find anything. Thanks, -- Gaby |
From: Orivej D. <or...@gm...> - 2014-05-02 15:46:28
|
> > 1. I can reproduce the problem. It stems from SBCL being run effectively > > as "sbcl --eval ... < /dev/null". When SBCL enters debugger due to an > > error in the build process, it reads EOF, exits with code 0, and the > > build continues with this happening many times until finally SBCL > > encounters memory fault. > Thanks for the detective work. I missed your message earlier. My message "has been automatically rejected" from open-axiom-devel. Anyway, its second point (on the first actual error), and conclusion in the third were mistaken. > > 3. I'm going to investigate the cause of memory fault, but it should not > > concern OpenAxiom or Gentoo. So far I found that although corruption happens when ../../src/driver/open-axiom --execpath=../lisp/lisp --output=strap/ast.fasl --compile --load-directory=strap /var/tmp/portage/sci-mathematics/open-axiom-1.4.2/work/open-axiom-1.4.2/src/boot/strap/ast.clisp executes ../lisp/lisp --noinform --end-runtime-options --noprint --no-sysinit --no-userinit --end-toplevel-options -- --output=strap/ast.fasl --compile --load-directory=strap /var/tmp/portage/sci-mathematics/open-axiom-1.4.2/work/open-axiom-1.4.2/src/boot/strap/ast.clisp in BUILDDIR/src/boot in the sandbox, the latter command by itself completes compilation with no error. |
From: 73budden . <bud...@gm...> - 2015-11-19 14:02:07
|
Hi! I initially posted to sbcl-devel, but now I see sbcl-help is more adequate place for this question. I use SBCL 1.3.0 on Windows 7 32 bit, disabled DEP and antivirus (which conflicts to SBCL and some other programs too). I copied SBCL executables to another location and start it from cmd file. There are :swank, :clcon-server, :hunchentoot, :postmodern in my lisp image, and tried some load test. My hunchentoot web page handler connects to postgres, retrieves simple query, prints that data and output of (room) to the page, closes database connection and returns. Most of the output, excluding *trace-output* is processed by SWANK and passed to clcon tcl/tk frontend via sockets (no essential difference to EMACS). *trace-output* is printed just to SBCL's black console. Also I run (sb-ext:gc :full t) every 3 seconds to avoid memory overflow (in a dedicated thread). *evaluation-mode* is :interpret. I tuned Hunchentoot to catch errors in worker threads (setting *catch-errors-p* to true). I arranged things so that I send ~30 simultaneous queries to the server. In a time, SBCL printed several times a backtrace of error in hunchentoot worker thread like this: [2015-11-19 15:51:42 [ERROR]] Unrecognized widetag #x72 in reconstitute-object Backtrace for: #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:27155" RUNNING {2617ACE1}> 7: ((FLET #:H0 :IN HUNCHENTOOT:HANDLE-REQUEST) #<SIMPLE-ERROR "Unrecognized widetag #x~2,'0X in reconstitute-object" {280CE1F1}>) 8: (SIGNAL #<SIMPLE-ERROR "Unrecognized widetag #x~2,'0X in reconstitute-object" {280CE1F1}>) 9: (ERROR "Unrecognized widetag #x~2,'0X in reconstitute-object" 114) 10: (SB-VM::RECONSTITUTE-OBJECT 167483394) 11: (SB-VM::MAP-OBJECTS-IN-RANGE #<CLOSURE (LAMBDA (SB-VM::OBJ TYPE SB-VM::SIZE) :IN SB-VM::TYPE-BREAKDOWN) {27C82E95}> 167483394 167484386) 12: ((FLET #:WITHOUT-GCING-BODY-380 :IN SB-VM::MAP-ALLOCATED-OBJECTS)) 13: (SB-VM::MAP-ALLOCATED-OBJECTS #<CLOSURE (LAMBDA (SB-VM::OBJ TYPE SB-VM::SIZE) :IN SB-VM::TYPE-BREAKDOWN) {27C82E95}> :DYNAMIC) 14: (SB-VM::TYPE-BREAKDOWN :DYNAMIC) 15: (SB-VM:MEMORY-USAGE :PRINT-SPACES T :COUNT-SPACES (:DYNAMIC) :PRINT-SUMMARY NIL :CUTOFF 0.05) 16: (ROOM :DEFAULT) After that, SBCL stopped responding in a few minutes. Several 10000's of queries were served by hunchentoot totally. After that, I took stack traces of some SBCL threads with sysinternals Process Explorer: Thread 1476: ntdll.dll!KiFastSystemCallRet kernel32.dll!WaitForSingleObjectEx+0x43 kernel32.dll!WaitForSingleObject+0x12 sbcl.exe!pthread_cond_wait+0x124 sbcl.exe!thread_in_safety_transition+0x308 sbcl.exe!handle_exception+0x66e sbcl.exe!exception_handler_wrapper+0x28 ntdll.dll!RtlRaiseStatus+0xb4 sbcl.exe!gc_alloc_large+0x8b2 ntdll.dll!LdrGetDllHandleEx+0x272 KERNELBASE.dll!GetModuleHandleW+0x51 ntdll.dll!ZwSetEvent+0xc KERNELBASE.dll!SetEvent+0x10 sbcl.exe!futex_wake+0xcf Thread 6156: ntdll.dll!KiFastSystemCallRet kernel32.dll!WaitForSingleObjectEx+0x43 kernel32.dll!WaitForSingleObject+0x12 sbcl.exe!pthread_cond_wait+0x124 sbcl.exe!thread_in_lisp_raised+0x1d5 sbcl.exe!handle_exception+0x680 sbcl.exe!exception_handler_wrapper+0x28 ntdll.dll!RtlRaiseStatus+0xb4 LIBEAY32.dll!SRP_create_verifier+0xb0b0 ntdll.dll!EtwSetMark+0x1faa ntdll.dll!EtwpNotificationThread+0xaa ntdll.dll!RtlInitializeExceptionChain+0x1e0 ntdll.dll!ZwTestAlert+0xc ntdll.dll!RtlAllocateActivationContextStack+0x12a ntdll.dll!NtContinue+0xc ntdll.dll!LdrInitializeThunk+0x1a 22576: ntdll.dll!KiFastSystemCallRet kernel32.dll!WaitForSingleObjectEx+0x43 kernel32.dll!WaitForSingleObject+0x12 sbcl.exe!pthread_cond_wait+0x124 sbcl.exe!gc_stop_the_world+0x284 sbcl.exe!call_into_c+0x24 sbcl.exe!call_into_lisp+0x90 sbcl.exe!funcall0+0x47 sbcl.exe!check_pending_gc+0x21d sbcl.exe!thread_interrupted+0xc1 sbcl.exe!handle_exception+0x626 sbcl.exe!exception_handler_wrapper+0x28 ntdll.dll!RtlRaiseStatus+0xb4 sbcl.exe!alloc_overflow_ecx+0x12 (room) retrieved with web page not long before lockout was Dynamic space usage is: 84,127,600 bytes. Read-only space usage is: 3,240 bytes. Static space usage is: 3,200 bytes. Control stack usage is: 3,896 bytes. Binding stack usage is: 496 bytes. Control and binding stack usage is for the current thread only. Garbage collection is currently enabled. Breakdown for dynamic space: 20,211,888 bytes for 29,713 code objects. 12,315,832 bytes for 223,106 simple-vector objects. 11,572,744 bytes for 1,446,593 cons objects. 11,346,936 bytes for 127,959 simple-character-string objects. 7,829,496 bytes for 197,094 instance objects. 6,187,136 bytes for 44,893 simple-array-unsigned-byte-8 objects. 4,869,520 bytes for 60,787 simple-array-unsigned-byte-32 objects. 11,198,800 bytes for 685,913 other objects. 85,532,352 bytes for 2,816,058 dynamic objects (space total.) What should I do next, what to read, what to study, how to debug, how to diagnose? Thanks! |
From: Stas B. <sta...@gm...> - 2015-11-19 15:28:50
|
"73budden ." <bud...@gm...> writes: > Hi! > > I initially posted to sbcl-devel, but now I see sbcl-help is more > adequate place for this question. > > I use SBCL 1.3.0 on Windows 7 32 bit, disabled DEP and antivirus > (which conflicts to SBCL and some other programs too). I copied SBCL > executables to another location and start it from cmd file. > > There are :swank, :clcon-server, :hunchentoot, :postmodern in my lisp > image, and tried some load test. My hunchentoot web page handler > connects to postgres, retrieves simple query, prints that data and > output of (room) to the page, closes database connection and returns. > Most of the output, excluding *trace-output* is processed by SWANK and > passed to clcon tcl/tk frontend via sockets (no essential difference > to EMACS). *trace-output* is printed just to SBCL's black console. > > Also I run (sb-ext:gc :full t) every 3 seconds to avoid memory > overflow (in a dedicated thread). > > *evaluation-mode* is :interpret. I tuned Hunchentoot to catch errors > in worker threads (setting *catch-errors-p* to true). > > I arranged things so that I send ~30 simultaneous queries to the > server. In a time, SBCL printed several times a backtrace of error in > hunchentoot worker thread like this: > > [2015-11-19 15:51:42 [ERROR]] Unrecognized widetag #x72 in reconstitute-object > Backtrace for: #<SB-THREAD:THREAD "hunchentoot-worker-127.0.0.1:27155" > RUNNING {2617ACE1}> > 7: ((FLET #:H0 :IN HUNCHENTOOT:HANDLE-REQUEST) #<SIMPLE-ERROR > "Unrecognized widetag #x~2,'0X in reconstitute-object" {280CE1F1}>) > 8: (SIGNAL #<SIMPLE-ERROR "Unrecognized widetag #x~2,'0X in > reconstitute-object" {280CE1F1}>) > 9: (ERROR "Unrecognized widetag #x~2,'0X in reconstitute-object" 114) > 10: (SB-VM::RECONSTITUTE-OBJECT 167483394) > 11: (SB-VM::MAP-OBJECTS-IN-RANGE #<CLOSURE (LAMBDA (SB-VM::OBJ TYPE > SB-VM::SIZE) :IN SB-VM::TYPE-BREAKDOWN) {27C82E95}> 167483394 > 167484386) > 12: ((FLET #:WITHOUT-GCING-BODY-380 :IN SB-VM::MAP-ALLOCATED-OBJECTS)) > 13: (SB-VM::MAP-ALLOCATED-OBJECTS #<CLOSURE (LAMBDA (SB-VM::OBJ TYPE > SB-VM::SIZE) :IN SB-VM::TYPE-BREAKDOWN) {27C82E95}> :DYNAMIC) > 14: (SB-VM::TYPE-BREAKDOWN :DYNAMIC) > 15: (SB-VM:MEMORY-USAGE :PRINT-SPACES T :COUNT-SPACES (:DYNAMIC) > :PRINT-SUMMARY NIL :CUTOFF 0.05) > 16: (ROOM :DEFAULT) > But what does it run ROOM? Sure, it should be more safe, but it's not really useful in a web-server. -- With best regards, Stas. |
From: 73budden . <bud...@gm...> - 2015-11-19 16:56:15
|
> But what does it run ROOM? Do you mean "why does it run ROOM"? This is just load test. My primary goal is to test if I can use SBCL as an application server, so running ROOM so frequently is not necessary. Is it unsafe? |
From: Stas B. <sta...@gm...> - 2015-11-19 16:57:57
|
"73budden ." <bud...@gm...> writes: >> But what does it run ROOM? > Do you mean "why does it run ROOM"? This is just load test. My primary > goal is to test if I can use SBCL as an application server, so running > ROOM so frequently is not necessary. Is it unsafe? Well, apparently it crashes. Can you trigger this without using ROOM? -- With best regards, Stas. |
From: 73budden . <bud...@gm...> - 2015-11-19 18:22:34
|
I tryed to reproduce the problem without room. Pages are created too fast, I'm unable to have 30 threads... but it crashed in several minutes. Then I removed "saver" thread which calls (gc :full t) every 3 seconds. It crashed approximately at the same time. I also tried Linux: Sbcl 1.2.7 Linux d8 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) i686 GNU/Linux File crash2.lisp seem to be rather innocent: (in-package :cl-user) (proclaim '(optimize (debug 3) (compilation-speed 0) (speed 0) (space 0) (safety 3))) (mapc 'require '(sb-bsd-sockets sb-posix sb-introspect sb-cltl2 asdf)) (defmethod asdf::perform-with-restarts :after (operation component) (format t "perform-with-restarts done with op ~S, compt ~S~%" operation component) (room) (sb-ext:gc :full t) ) (setf sb-impl::*default-external-format* :utf-8) (let ((quicklisp-init "~/ql.sbcl.l/setup.lisp")) (load quicklisp-init)) (proclaim '(optimize (debug 3) (compilation-speed 3))) (load (merge-pathnames "swank-loader.lisp" (ql:where-is-system :swank))) (swank-loader:init) (proclaim '(optimize (debug 3) (compilation-speed 0) (speed 0) (space 0) (safety 3))) (swank:create-server :port 4005 :dont-close t) (asdf:load-system :cl-fad) ; or :alexandria - it does not matter (break "If you are here, you didn't reproduce my problem") ;; EOF crash2.lisp I call it with sbcl --no-userinit --load /s2/clcon/crash2.lisp and see: perform-with-restarts done with op #<ASDF/LISP-ACTION:COMPILE-OP >, compt #<ASDF/COMPONENT:STATIC-FILE "alexandria" "LICENCE"> Dynamic space usage is: 52,446,816 bytes. Read-only space usage is: 3,496 bytes. Static space usage is: 2,240 bytes. Control stack usage is: 3,216 bytes. Binding stack usage is: 496 bytes. Control and binding stack usage is for the current thread only. Garbage collection is currently enabled. Heap exhausted during allocation: 0 bytes available, 8 requested. Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age 0: 131071 0 0 0 118097 0 0 0 0 483410504 314808 5368709 0 0 0,0000 1: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0,0000 2: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0,0000 3: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0,0000 4: 0 0 0 0 0 0 0 0 0 0 0 5368709 0 0 0,0000 5: 0 0 0 0 2006 809 12 0 76 10841616 737776 16210325 1929 56 0,0000 6: 0 0 0 0 8437 1709 0 0 0 41558016 0 2000000 8235 0 0,0000 Total bytes allocated = 535810136 Dynamic-space-size bytes = 536870912 GC control variables: *GC-INHIBIT* = true *GC-PENDING* = true *STOP-FOR-GC-PENDING* = false fatal error encountered in SBCL pid 14564(tid 3084576512): Heap exhausted, game over. Welcome to LDB, a low-level debugger for the Lisp runtime environment. without that gc-ing in asdf, my application (several Mb of sources) builds and works, but it crashes as soon I try to call (room) with the similar message. . |
From: 73budden . <bud...@gm...> - 2015-11-20 21:04:02
|
I built with :sb-fluid and :sb-xref-for-internals. I runned tests (according to INSTALL) and had some failures: Failure: debug.impure.lisp / BUG-310173 Expected failure: dynamic-extent.impure.lisp / (NO-CONSING SPECIALIZED-DX-VECTORS) Invalid exit status: gc.impure.lisp Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT Invalid exit status: smoke.impure.lisp Failure: threads.impure.lisp / FP-MODE-INHERITANCE-THREADS Invalid exit status: room.test.sh It looks like I have to remove :sb-fluid first of all. Then I built with only :sb-xref-for-internals, and I had only one test failure: Failure: threads.impure.lisp / FP-MODE-INHERITANCE-THREADS Is it ok or what should I do next? Now I'll try to build with all defaults and run tests again. |
From: Stas B. <sta...@gm...> - 2015-11-20 21:06:25
|
"73budden ." <bud...@gm...> writes: > I built with :sb-fluid and :sb-xref-for-internals. I runned tests > (according to INSTALL) and had some failures: > > Failure: debug.impure.lisp / BUG-310173 > Expected failure: dynamic-extent.impure.lisp / (NO-CONSING > SPECIALIZED-DX-VECTORS) > Invalid exit status: gc.impure.lisp > Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET > Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT > Invalid exit status: smoke.impure.lisp > Failure: threads.impure.lisp / FP-MODE-INHERITANCE-THREADS > Invalid exit status: room.test.sh > > It looks like I have to remove :sb-fluid first of all. > > Then I built with only :sb-xref-for-internals, and I had only one test failure: > > Failure: threads.impure.lisp / FP-MODE-INHERITANCE-THREADS > > Is it ok or what should I do next? Now I'll try to build with all > defaults and run tests again. It's a surprise sb-fluid even got built. -- With best regards, Stas. |
From: 73budden . <bud...@gm...> - 2015-11-20 21:38:57
|
Ok, I removed sb-fluid. Sorry, I should have done tests at the beginning. With all defaults I still have one test failure, Failure: threads.impure.lisp / FP-MODE-INHERITANCE-THREADS Is it ok or not? If it is not ok, what can be the reason and consequences? 2015-11-21 0:06 GMT+03:00, Stas Boukarev <sta...@gm...>: > "73budden ." <bud...@gm...> writes: > >> I built with :sb-fluid and :sb-xref-for-internals. I runned tests >> (according to INSTALL) and had some failures: >> >> Failure: debug.impure.lisp / BUG-310173 >> Expected failure: dynamic-extent.impure.lisp / (NO-CONSING >> SPECIALIZED-DX-VECTORS) >> Invalid exit status: gc.impure.lisp >> Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET >> Expected failure: packages.impure.lisp / IMPORT-SINGLE-CONFLICT >> Invalid exit status: smoke.impure.lisp >> Failure: threads.impure.lisp / FP-MODE-INHERITANCE-THREADS >> Invalid exit status: room.test.sh >> >> It looks like I have to remove :sb-fluid first of all. >> >> Then I built with only :sb-xref-for-internals, and I had only one test >> failure: >> >> Failure: threads.impure.lisp / FP-MODE-INHERITANCE-THREADS >> >> Is it ok or what should I do next? Now I'll try to build with all >> defaults and run tests again. > It's a surprise sb-fluid even got built. > > -- > With best regards, Stas. > |
From: Stas B. <sta...@gm...> - 2015-11-20 21:41:24
|
"73budden ." <bud...@gm...> writes: > Ok, I removed sb-fluid. Sorry, I should have done tests at the beginning. > > With all defaults I still have one test failure, > Failure: threads.impure.lisp / FP-MODE-INHERITANCE-THREADS > Is it ok or not? If it is not ok, what can be the reason and consequences? This is harmless. -- With best regards, Stas. |