freenode/#clasp - IRC Chatlog
Search
20:15:48
Bike
i'm crashing with only positive bignums so it's probably not the gc choking on negative sizes
20:30:08
Bike
and then you can run e.g. (let ((x (core:next-from-fixnum most-positive-fixnum))) (loop repeat 20 for i = x then (core:next-mul i x)))) until it dies
20:32:23
Bike
um, clasp? i'm not sure what you're asking. i build with cando in but i don't think that matters
20:42:18
Bike
it builds fine. everything still uses the old bignum arithmetic, it's just that the next-bignum arithmetic is also available.
21:08:26
drmeister
(loop repeat 10000 do (let ((x (core:next-from-fixnum most-positive-fixnum))) (loop repeat 20 for i = x then (core:next-mul i x))))
21:09:44
drmeister
What does this do? advance to the first bignum after most-positive-fixnum and then multiply by 0,1,2...19?
21:10:54
drmeister
I'd worry about writing past the end of the object. Try turning on guards and I'll find the function that checks the guards.
21:12:15
drmeister
Yeah - but other than that what could go wrong? There are no illegal values for the limb vector - right?
21:14:28
Bike
https://github.com/clasp-developers/clasp/blob/bignum/src/core/bignum.cc#L447-L465 as you can see, it allocates result_size limbs on the stack, then passes that (or one less) in as initial contents
21:18:25
drmeister
What about the mpn_ functions. What if they write outside the vector on the stack?
21:20:26
Bike
the requirements for mpn_mul are that neither size input is zero, the destination size is the sum of the input sizes, and the left size is at least as big as the right size.
21:25:01
drmeister
I put two extra elements in the array on the stack and wrote 0xccCCccCCccCCccCC into the first and last one and I'm writing into result_limbs+1
21:29:52
Bike
in the function I linked, result_size is the sum of two absolute values, so it's positive
21:40:46
drmeister
(loop repeat 10000000 do (let ((x (core:next-from-fixnum most-positive-fixnum))) (loop repeat 20 do (core:next-mul x x))))
21:51:46
drmeister
It depends on the DEBUG_GUARD_EXHAUSTIVE_VALIDATE being turned on. But that might slow down compilation quite a lot.
22:00:38
drmeister
I pushed a few changes, one to add (gctools:validate-object xxx) and the other to suppress that overload that linux hates.
22:01:11
Bike
" ../../src/gctools/memoryManagement.cc:342 Invalid object with header @ 0x125ea4b40 message: header stamps are invalid"
22:47:08
drmeister
I should write a function like ROOM that walks all of the memory and checks every object
22:52:37
Bike
"../../src/gctools/memoryManagement.cc:342 Invalid object with header @ 0x124bc2ab0 message: bad tail content"
22:54:21
drmeister
For some reason when I recompiled cclasp and bclasp images won't load on linux - so I have to rebuild cclasp
23:39:31
drmeister
So I get... ./../src/gctools/memoryManagement.cc:342 Invalid object with header @ 0x14425820 message: bad tail content
23:45:20
drmeister
From https://github.com/clasp-developers/clasp/blob/bignum/include/clasp/gctools/memoryManagement.h#L487
23:46:01
drmeister
I replicated info in the header incase something gets clobbered I can still reconstruct the info for the object.
23:48:13
drmeister
The _tail_start is 0x60 and the _tail_size is 0x60. The tail_size can vary from object to object and allocation to allocation in a random way to try and avoid bugs with registration and alignment.
23:50:41
drmeister
The header is at 0x14425820 and the client starts at 0x14425860 (vtable-ptr, badge, number of limbs, limbs(2))
23:51:47
drmeister
The tail SHOULD start at 0x14425820+0x60 = 0x14425880 - and it should contain 60 0xcc
23:52:30
drmeister
But the first 8 bytes of the tail contain 0x03ffffffffffffff - so we aren't calculating the size of the object properly when we are allocating it.
23:56:35
Bike
uh.... so what's the fix here? do you mean the wrong size is being passed to TheNextBignum_O::create?
23:59:25
drmeister
I'm not sure. But it looks like a mismatch somewhere between what the allocator things the layout of the object should be and what you are writing into it.
23:59:46
drmeister
I'll have to dig around some more. Right now my girls are dragging me out the door to get some groceries.