SV: SV: SV: SV: SV: SV: [elephant-devel] Memory error with Elephant
Petter Egesund
Petter.Egesund at kunnskapsforlaget.no
Tue Aug 22 12:18:30 UTC 2006
Hi;
I have done some debugging. It seems the problem of serializing integers is caused by mixing of the types int and integer in the foreign interface?
I change the function read-int in the package memutil.lisp to:
(defun pread-int (buf offset)
"Read a 32-bit signed integer from a foreign char buffer."
(declare (optimize speed (safety 1) (debug 1))
(type (alien (* char)) buf)
(type fixnum offset))
(print "Offset: ") (print offset)
(the (signed-byte 32)
(deref (cast (sap-alien (sap+ (alien-sap buf) offset) (* char))
(* int))))) ;; !!!!!!!!!!!!! Changed from (* integer)
After this the integer-test runs fine. I will do some more testing.
Cheers,
Petter Egesund
-----Opprinnelig melding-----
Fra: Ian Eslick [mailto:eslick at csail.mit.edu]
Sendt: 21. august 2006 16:11
Til: Petter Egesund
Kopi: Robert L. Read; eslick at media.mit.edu; Ian Eslick
Emne: Re: SV: SV: SV: SV: SV: [elephant-devel] Memory error with Elephant
Interesting. That explains the source of our problem (serializing
integers) but I still don't understand why. Even if the 4 byte assumption in lisp keeps us from expanding the buffer streams appropriately the write should still write the first 8 bytes correctly and thus be able to read it correctly. It almost looks like it is writing 4 bytes but reading 8.
1) Try replacing the #x45 with #x00 in my test code
The other test is to see what is actually being put into the buffer stream.
2) replace #x45 with #x40302010 and add the following code instead of the buffer-read-int at the end:
(loop for i from 0 upto 16 do
(format t "byte ~A: ~A~%" i (buffer-read-byte bs)))
Ian
Petter Egesund wrote:
>
>
> ----------------------------------------------------------------------
> --
> *Fra:* Robert L. Read [mailto:read at robertlread.net]
> *Sendt:* 19. august 2006 22:26
> *Til:* Petter Egesund
> *Kopi:* eslick at media.mit.edu; Ian Eslick
> *Emne:* Re: SV: SV: SV: SV: [elephant-devel] Memory error with
> Elephant
>
> Personally, the fact that buffer-write-int in memutil.lisp assumes a
> 4-byte integer:
> (defun buffer-write-int (i bs)
> "Write a 32-bit signed integer."
> (declare (optimize (speed 3) (safety 0))
> (type buffer-stream bs)
> (type (signed-byte 32) i))
> (with-struct-slots ((buf buffer-stream-buffer)
> (size buffer-stream-size)
> (len buffer-stream-length))
> bs
> (let ((needed (+ size 4)))
> (when (> needed len)
> (resize-buffer-stream bs needed))
> (write-int buf i size)
> (setf size needed)
> nil)))
> While the c-code version of write-int in libmemutil.c uses the
> "sizeof(int)" paradigm seems fragile on a 64-bit architecture:
>
> void write_int(char *buf, int num, int offset) {
> memcpy(buf+offset, &num, sizeof(int)); }
>
> I would like to know if "sizeof(int)" is 8 or 4 as compiled.
> A simple C program (or reading the f-ing manual) would answer that
> question.
> An awful hack that would let us test things would be to hard-wire "4"
> in place of
> "sizeof(int)" in the libmemutil.c file; I don't know enough about
> UFFI and sap-alien to know if that would work.
>
> A better solution is to expose a C-function that simply gives the size
> of an integer in bytes to LISP (it could be added to libmemutil.c
> file) and then have memutil.lisp use that in place of the assumption
> "4".)
>
> How this changes the typing in memutil.lisp, I'm not sure ---- can
> we/should we force the
> AMD64 to use 32-bit integers, or should we rewrite memutil.lisp to
> determine based on its compilation environment the size of an integer?
> Either solution is better than what we have now.
>
>
> On Sat, 2006-08-19 at 20:53 +0200, Petter Egesund wrote:
>> It looks like below. Certainly not 35.
>>
>> Petter
>>
>> -------
>>
>> ELE> (defun fixnum-test ()
>> (with-buffer-streams (bs)
>> (buffer-write-int #x23 bs)
>> (buffer-write-int #x45 bs)
>> (reset-buffer-stream bs)
>> (buffer-read-int bs)))
>> ; in: LAMBDA NIL
>> ; (ELEPHANT-MEMUTIL:BUFFER-WRITE-INT 69 ELEPHANT::BS)
>> ; --> BLOCK ELEPHANT-MEMUTIL::WITH-STRUCT-SLOTS SYMBOL-MACROLET LET
>> WHEN ; --> COND IF PROGN ; ==>
>> ; (ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM ELEPHANT-MEMUTIL::BS
>> ; ELEPHANT-MEMUTIL::NEEDED)
>> ;
>> ; note: doing signed word to integer coercion (cost 20)
>>
>> ; (ELEPHANT-MEMUTIL:BUFFER-WRITE-INT 35 ELEPHANT::BS)
>> ; --> BLOCK ELEPHANT-MEMUTIL::WITH-STRUCT-SLOTS SYMBOL-MACROLET LET
>> WHEN ; --> COND IF PROGN ; ==>
>> ; (ELEPHANT-MEMUTIL:RESIZE-BUFFER-STREAM ELEPHANT-MEMUTIL::BS
>> ; ELEPHANT-MEMUTIL::NEEDED)
>> ;
>> ; note: doing signed word to integer coercion (cost 20) ; ;
>> compilation unit finished
>> ; printed 2 notes
>> FIXNUM-TEST
>> ELE> (fixnum-test)
>> 296352743459
>> ELE>
>>
>>
>>
>>
>>
>>
>> -----Opprinnelig melding-----
>> Fra: Ian Eslick [mailto:eslick at csail.mit.edu
>> <mailto:eslick at csail.mit.edu>]
>> Sendt: 19. august 2006 20:21
>> Til: Petter Egesund
>> Kopi: eslick at media.mit.edu <mailto:eslick at media.mit.edu>; Robert L.
>> Read; Ian Eslick
>> Emne: Re: SV: SV: SV: [elephant-devel] Memory error with Elephant
>>
>> What happens if you write two fixnums and read a fixnum by hand?
>>
>> (defun fixnum-test ()
>> (with-buffer-streams (bs)
>> (buffer-write-int #x23 bs)
>> (buffer-write-int #x45 bs)
>> (reset-buffer-stream bs)
>> (buffer-read-int bs)))
>>
>> Running this function should return 35 (#x23).
>>
>> Ian
>>
>> Petter Egesund wrote:
>> > Hi, thanks for advices.
>> >
>> > I have had a quick look. It seems the problem lies in the
>> > serializing, which might be illustrated by the fact that the error
>> > occurs when entering these small lines;
>> >
>> > (in-package "ELEPHANT")
>> > (defvar str (coerce "this is a test" 'base-string))
>> > (ser-deser-equal
>> > str)
>> >
>> > I have had a look at the code, a rather wild guess might be that the problem is related to the function (buffer-read-fixnum bs) combined with reading from the buffer? Seems like byte-length, endian and stuff like this is relevant?
>> >
>> > I have not had other problems with the 64-bit Sbcl so far. I have been running a few other programs, like a web-server and some parser stuff. The 32-bits version did run, but it had problems with linking to libraries (which might probably be solved). On my private PC which is a 32-bits Slackware, everything seems to work well, Elephant also.
>> >
>> > I will try to do some tracing on Tonday/Tuesday.
>> >
>> > Cheers,
>> >
>> > Petter
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > -----Opprinnelig melding-----
>> > Fra: Ian Eslick [mailto:eslick at csail.mit.edu
>> > <mailto:eslick at csail.mit.edu>]
>> > Sendt: 19. august 2006 01:11
>> > Til: Robert L. Read
>> > Kopi: Petter Egesund; Ian Eslick
>> > Emne: Re: SV: SV: [elephant-devel] Memory error with Elephant
>> >
>> > I got my head wrapped around Elephant again recently so I'd be happy to assist. I'm on vacation this week and the latter part of next week so won't be highly responsive, but I think this is such a major problem it actually should be quite easy to track down.
>> >
>> > I did observe that it appears to be unbounded primitives like bignum and strings that fail.
>> >
>> > Some possible candidates off the top of my head:
>> > - When reading a fixnum back for the length of a string, bignum, etc we are actually reading adjacent
>> > values causing the allocator to request a string length in the gigabytes...
>> > - Also, length calculation in memutil.lisp may mismatch with the
>> > actual string length
>> > - Some memutil.lisp system-dependent parameter such as byte-length, etc might not be setup properly for AMD 64 systems.
>> >
>> > Don't forget that the SBCL 64-bit implementation is new so if compiled
>> > for native AMD-64 it might have a bug. Have you tried a 32-bit SBCL on
>> > your AMD-64 CPU?
>> >
>> > Anyway, see if you can trace serialize and (labels serialize %serialize) as well as deserialize and %deserialize put a break at the entry point to each so you can allow computation to continue at each step and see why we're getting the strange memory requests. Then just create a buffer-stream using 'with-buffer-streams' and try serializing a string to it, resetting the stream and reading the string back using deserialize (all buffer stream methods are in src/memutil/memutil.lisp).
>> >
>> > That should get you close to the problem.
>> >
>> > Thanks for the help, I'll pitch in as I can.
>> >
>> > Cheers,
>> > Ian
>> >
>> >
>> > Robert L. Read wrote:
>> >
>> >> Ughh --- you make a kind and generous offer, which I would
>> >> definitely accept if I weren't so busy with other things.
>> >>
>> >> How about this?
>> >> You spend some time, a few hours maybe, trying to get the simplest
>> >> serialization tests working. If you can clearly reduce it to the
>> >> first first test that fails and perhaps track it down to the
>> >> module or the assumption in question, then I will log into your
>> >> computer and either debug it further, or see if there is (for
>> >> example), a simple improvement in the serializer that will let it get further.
>> >>
>> >> On Fri, 2006-08-18 at 22:58 +0200, Petter Egesund wrote:
>> >>
>> >>> A quick guess is that this has nothing to do with the
>> >>> BDB-backend, it seems it fails before it reaches the database point?
>> >>>
>> >>> I am not sure where to start debugging, but I can offer you a
>> >>> user on the AMD64 if that could be of any help?
>> >>>
>> >>> Anyhow I will try to do some small debugging - this package works
>> >>> so well on my private 32-bits Linux...
>> >>>
>> >>> Petter
>> >>>
>> >>> -----------------------------------------------------------------
>> >>> ---
>> >>> -
>> >>> ---
>> >>>
>> >>> *Fra:* Robert L. Read [mailto:read at robertlread.net
>> >>> <mailto:read at robertlread.net>]
>> >>> *Sendt:* 18. august 2006 22:51
>> >>> *Til:* Petter Egesund
>> >>> *Kopi:* Elephant-devel mailing list
>> >>> *Emne:* Re: SV: [elephant-devel] Memory error with Elephant
>> >>>
>> >>>
>> >>> Well, its good we know this ---- there is zero hope of getting
>> >>> Elephant to work until we solve this problem.
>> >>>
>> >>> My hunch would be this has to do with the AMD64.
>> >>>
>> >>> It is entirely possible that the serializer makes some assumption
>> >>> that isn't true on AMD64; the serializer gets into some
>> >>> byte-representation issues that could fail there.
>> >>>
>> >>> If you would like to debug it, I would be happy to answer your
>> >>> questions. I hope to use a 64-bit processor in my own business
>> >>> soon, but I don't have one available now.
>> >>>
>> >>> Does anyone else have this working on a 64 bit processor?
>> >>>
>> >>>
>> >>> On Fri, 2006-08-18 at 22:37 +0200, Petter Egesund wrote:
>> >>>
>> >>>> Thanks for answering!
>> >>>>
>> >>>> I did run one test, the not-so-good result was like below. Any clues?
>> >>>>
>> >>>> Cheers,
>> >>>>
>> >>>> Petter
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------
>> >>>>
>> >>>> ; SLIME 2006-04-20
>> >>>> CL-USER> (asdf:operate 'asdf:load-op :ele-bdb)
>> >>>> ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/ele-bdb.asd
>> >>>> into ; #<PACKAGE "ASDF0"> ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/uffi.asd into ; #<PACKAGE "ASDF1"> ;
>> >>>> registering #<SYSTEM UFFI {1002EB0B41}> as UFFI ; registering
>> >>>> #<SYSTEM ELE-BDB {10034A6441}> as ELE-BDB ; loading system
>> >>>> definition from /home/pe/.sbcl/systems/elephant.asd into ;
>> >>>> #<PACKAGE "ASDF0"> ; registering #<SYSTEM ELEPHANT {100260E571}>
>> >>>> as ELEPHANT
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> PERSISTENT-SLOTS
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function OLD-PERSISTENT-SLOTS
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> UPDATE-PERSISTENT-SLOTS
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> INDEXED-RECORD
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> OLD-INDEXED-RECORD
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> UPDATE-INDEXED-RECORD
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> MAKE-NEW-INDEXED-RECORD
>> >>>> STYLE-WARNING: implicitly creating new generic function REMOVED-INDEXING?
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> REGISTER-INDEXED-SLOT
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> UNREGISTER-INDEXED-SLOT
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> REGISTER-DERIVED-INDEX
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> UNREGISTER-DERIVED-INDEX
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> PREVIOUSLY-INDEXED ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/cl-base64.asd into ; #<PACKAGE "ASDF0"> ;
>> >>>> registering #<SYSTEM CL-BASE64 {1003993E91}> as CL-BASE64 ;
>> >>>> registering #<SYSTEM CL-BASE64-TESTS {1003C546C1}> as
>> >>>> CL-BASE64-TESTS ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/kmrcl.asd into ; #<PACKAGE "ASDF0"> ;
>> >>>> registering #<SYSTEM KMRCL {1003345D31}> as KMRCL
>> >>>> STYLE-WARNING: implicitly creating new generic function GET-CON
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> CONTROLLER-PROPERTIES
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> SET-ELE-PROPERTY
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> GET-ELE-PROPERTY
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> ENSURE-MARKED-VERSION
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> CONTROLLER-VERSION
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> UP-TO-DATE-P
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> UPGRADABLE-P
>> >>>> STYLE-WARNING: implicitly creating new generic function UPGRADE
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function FLUSH-INSTANCE-CACHE
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> DROP-POBJECT
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> MAP-BTREE
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> EMPTY-BTREE-P
>> >>>> STYLE-WARNING: implicitly creating new generic function CLASS-INDEX-CACHED?
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> DETERMINE-SYNCH-METHOD
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> SET-DB-SYNCH
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> INDEXED-SLOT-WRITER
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> CLASS-INDEXEDP-BY-NAME
>> >>>> STYLE-WARNING:
>> >>>> implicitly creating new generic function
>> >>>> FIND-INVERTED-INDEX-NAMES
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> WIPE-CLASS-INDEXING
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> COPY-BTREE-CONTENTS
>> >>>> STYLE-WARNING: implicitly creating new generic function
>> >>>> BUILD-BTREE-INDEX NIL
>> >>>> CL-USER> (asdf:operate 'asdf:load-op :elephant-tests)
>> >>>> ; loading system definition from
>> >>>> /home/pe/.sbcl/systems/elephant-tests.asd
>> >>>> ; into #<PACKAGE "ASDF0">
>> >>>> ; registering #<SYSTEM ELEPHANT-TESTS {10038A95E1}> as
>> >>>> ELEPHANT-TESTS ; registering #<SYSTEM ELEPHANT-TESTS-BDB
>> >>>> {1003B28C91}> as ; ELEPHANT-TESTS-BDB ; loading system
>> >>>> definition from /home/pe/.sbcl/systems/rt.asd into ; #<PACKAGE
>> >>>> "ASDF0"> ; registering #<SYSTEM :RT {1003F11531}> as RT NIL
>> >>>> CL-USER> (in-package "ELEPHANT-TESTS")
>> >>>> #<PACKAGE "ELEPHANT-TESTS">
>> >>>> ELE-TESTS> (setf *default-spec* *testbdb-spec*)
>> >>>> (:BDB "/home/pe/.sbcl/site/elephant/tests/testdb/")
>> >>>> ELE-TESTS> (do-backend-tests)
>> >>>> ; compiling file "/home/pe/.sbcl/site/elephant/tests/testsleepycat.lisp" (written 19 FEB 2006 05:53:02 AM):
>> >>>> ; compiling (IN-PACKAGE "ELE-TESTS") ; compiling (DEFVAR ENV) ;
>> >>>> compiling (DEFVAR DB) ; compiling (DEFUN PREPARE-SLEEPYCAT ...)
>> >>>> ; compiling (DEFTEST PREPARES-SLEEPYCAT ...) ; compiling (DEFUN
>> >>>> TEST-SEQUENCE1 ...) ; compiling (DEFTEST TEST-SEQ1 ...) ;
>> >>>> compiling (DEFUN TEST-SEQUENCE2 ...) ; compiling (DEFTEST
>> >>>> TEST-SEQ2 ...) ; compiling (DEFUN CLEANUP-SLEEPYCAT ...) ;
>> >>>> compiling (DEFTEST CLEANSUP-SLEEPYCAT ...)
>> >>>>
>> >>>> ; /home/pe/.sbcl/site/elephant/tests/testsleepycat.fasl written
>> >>>> ; compilation finished in 0:00:00 Doing 115 pending tests of 115
>> >>>> tests total.
>> >>>> FIXNUMS FIXNUM-TYPE-1
>> >>>> Test BIGNUMS failed
>> >>>> Form: (ARE-NOT-NULL (IN-OUT-EQUAL 10000000000) (IN-OUT-EQUAL -10000000000)
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (EXPT 2 I)))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (- (EXPT 2 I))))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (- (EXPT 2 I) 1)))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (- 1 (EXPT 2 I))))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (EXPT 3 I)))
>> >>>> (LOOP FOR I FROM 0 TO 2000 ALWAYS
>> >>>> (IN-OUT-EQUAL (- (EXPT 3 I)))))
>> >>>> Expected
>> >>>> values: T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> Actual value: #<SB-KERNEL::MEMORY-FAULT-ERROR {1002897E31}>.
>> >>>> FLOATS
>> >>>> Test RATIONALS failed
>> >>>> Form: (ARE-NOT-NULL (IN-OUT-EQUAL 1/2) (IN-OUT-EQUAL -1/2)
>> >>>> (IN-OUT-EQUAL (/ 1 MOST-POSITIVE-FIXNUM))
>> >>>> (IN-OUT-EQUAL (/ 1 MOST-NEGATIVE-FIXNUM))
>> >>>> (IN-OUT-EQUAL
>> >>>> (/ MOST-POSITIVE-FIXNUM MOST-NEGATIVE-FIXNUM))
>> >>>> (IN-OUT-EQUAL (/ (EXPT 2 200) (EXPT 3 300)))
>> >>>> (IN-OUT-EQUAL (/ (EXPT 2 200) (- (EXPT 3
>> >>>> 300))))) Expected values: T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> T
>> >>>> Actual value: #<DIVISION-BY-ZERO {10028F0B41}>.
>> >>>> Test BASE-STRINGS failed
>> >>>> Form: (ARE-NOT-NULL
>> >>>> (IN-OUT-EQUAL (MAKE-STRING 0 :ELEMENT-TYPE 'BASE-CHAR))
>> >>>> (IN-OUT-EQUAL (COERCE "this is a test" 'BASE-STRING))
>> >>>> (IN-OUT-EQUAL
>> >>>> (MAKE-STRING 400 :INITIAL-ELEMENT (CODE-CHAR 127) :ELEMENT-TYPE
>> >>>> 'BASE-CHAR))) Expected values: T
>> >>>> T
>> >>>> T
>> >>>> Actual value: #<SB-KERNEL::MEMORY-FAULT-ERROR {100291E3F1}>.
>> >>>> Heap exhausted: 8517255168 bytes available, 498216206416 requested. PROCEED WITH CAUTION!
>> >>>> [Condition of type SB-KERNEL::HEAP-EXHAUSTED-ERROR]
>> >>>>
>> >>>> Restarts:
>> >>>> 0: [ABORT-REQUEST] Abort handling SLIME request.
>> >>>> 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD
>> >>>> "repl-thread" {1003511531}>)
>> >>>>
>> >>>> Backtrace:
>> >>>> 0: (SB-KERNEL::HEAP-EXHAUSTED-ERROR 8517255168 498216206416)
>> >>>> 1: ("foreign function: call_into_lisp")
>> >>>> 2: ("foreign function: funcall2")
>> >>>> 3: ("foreign function: gc_heap_exhausted_error_or_lose")
>> >>>> 4: ("foreign function: gc_find_freeish_pages")
>> >>>> 5: ("foreign function: gc_alloc_large")
>> >>>> 6: ("foreign function: alloc_tramp")
>> >>>> 7: ((LABELS ELEPHANT::%DESERIALIZE) #<unavailable argument>)
>> >>>> 8: (IN-OUT-EQUAL "this is a test")
>> >>>> 9: (SB-INT:EVAL-IN-LEXENV (IN-OUT-EQUAL "this is a test")
>> >>>> #<NULL-LEXENV>)
>> >>>> 10: (SB-INT:EVAL-IN-LEXENV (PROGN (IN-OUT-EQUAL "this is a
>> >>>> test"))
>> >>>> #<NULL-LEXENV>)
>> >>>> 11: (SB-INT:EVAL-IN-LEXENV (NULL (PROGN (IN-OUT-EQUAL "this is
>> >>>> a
>> >>>> test"))) #<NULL-LEXENV>)
>> >>>> 12: (SB-INT:EVAL-IN-LEXENV (IS-NOT-NULL (IN-OUT-EQUAL "this is
>> >>>> a
>> >>>> test")) #<NULL-LEXENV>)
>> >>>> 13: (SB-INT:EVAL-IN-LEXENV (ARE-NOT-NULL (IN-OUT-EQUAL "")
>> >>>> (IN-OUT-EQUAL "this is a test") (IN-OUT-EQUAL (MAKE-STRING 400
>> >>>> :INITIAL-ELEMENT #))) #<NULL-LEXENV>)
>> >>>> 14: ((FLET REGRESSION-TEST::%DO))
>> >>>> 15: (REGRESSION-TEST::DO-ENTRY #S(REGRESSION-TEST::ENTRY :PEND
>> >>>> T :NAME STRINGS :PROPS NIL :FORM (ARE-NOT-NULL (IN-OUT-EQUAL "")
>> >>>> (IN-OUT-EQUAL "this is a test") (IN-OUT-EQUAL #)) :VALS (T T T))
>> >>>> #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {100337B2F1}>)
>> >>>> 16: (REGRESSION-TEST::DO-ENTRIES*
>> >>>> #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {100337B2F1}>)
>> >>>> 17: (REGRESSION-TEST::DO-ENTRIES
>> >>>> #<SWANK-BACKEND::SLIME-OUTPUT-STREAM {100337B2F1}>)
>> >>>> 18: (DO-BACKEND-TESTS (:BDB
>> >>>> "/home/pe/.sbcl/site/elephant/tests/testdb/"))
>> >>>> 19: (SB-INT:EVAL-IN-LEXENV (DO-BACKEND-TESTS) #<NULL-LEXENV>)
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ________________________________
>> >>>>
>> >>>> Fra: elephant-devel-bounces at common-lisp.net
>> >>>> <mailto:elephant-devel-bounces at common-lisp.net>
>> >>>> <mailto:elephant-devel-bounces at common-lisp.net
>> >>>> <mailto:elephant-devel-bounces at common-lisp.net>>
>> >>>> [mailto:elephant-devel-bounces at common-lisp.net
>> >>>> <mailto:elephant-devel-bounces at common-lisp.net>
>> >>>> <mailto:elephant-devel-bounces at common-lisp.net
>> >>>> <mailto:elephant-devel-bounces at common-lisp.net>>] På vegne av
>> >>>> Robert L. Read
>> >>>> Sendt: 18. august 2006 22:04
>> >>>> Til: Elephant bugs and development
>> >>>> Emne: Re: [elephant-devel] Memory error with Elephant
>> >>>>
>> >>>>
>> >>>> That mystifies me. I can only conjecture that it is somehow related to your environment.
>> >>>>
>> >>>> Even thought it may seem strange since that simplest of
>> >>>> functionality doesn't work, you might wish to execute the test.
>> >>>> If, for example, there were an infinite loop in the serializer
>> >>>> when compiled in your environment, the larges suite of automated tests might reveal that, as opposed to a problem with BDB, for example.
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>>
More information about the elephant-devel
mailing list