freenode/#clasp - IRC Chatlog
Search
16:08:56
drmeister
Bounds checking has been on for these latest builds and I was generating backtrace frames for debugging in bclasp - I've turned those off and checking the timing.
17:34:16
drmeister
Thats after turning off bounds checking on every array index and bbacktrace frame eneraion
18:47:19
Bike
drmeister: just saw your messages. git bisect might be overkill given that there have only been four commits since the working one. could you see if it works on 0f94365?
19:36:55
Colleen
frgo: drmeister said at 2017.05.18 15:57:33: The new way functions are calling each other may require some adjustments to defcallback.
19:40:14
frgo
While you both wrestled with git I enjoyed a QSO (a talk over radio) with Guadeloupe - some 8000 km away from Germany using my ham radio gear - there being nice weather while we have cold rainy weather here.
19:54:56
Bike
that commit changes how cell creation works, but i don't think i can even guess what the problem is without knowing where it's braking
19:56:12
drmeister
It should have been writing to a CONS cell but the tag on the object being written to was that of a tagged VaList_S* pointer - but a memory location that indicated it was on the heap and not the stack.
19:57:13
drmeister
I'll bring it up in the debugger and show you what I've got - it's sketchy because of the lack of debugging info higher up.
21:20:02
drmeister
The last nibble 0xd is #b1101 #b101 is the tag for a VaList_S* tagged pointer. That should have an address like 0x7ffff... on the stack.
21:20:21
Bike
well, what that commit does is move create-cell instructions later in functions (previously they were all concentrated at the entry point)
21:20:38
drmeister
But Common Lisp code shouldn't cause low level problems like this. It's clearly a problem in Clasp - interacting with something weird in the CL.
21:21:22
Bike
so if you have like (loop for i below 5 collect (let ((x i)) (lambda () x))) it'll create cells in the loop.
21:23:18
Bike
it's possible i did something wrong so that a variable that's supposed to hold a cell is never initialized, or something.
21:29:51
drmeister
What if it's moved the cc_makeCell to later but left the cc_writeCell in the entry block? It would be writing to unintialized memory.
21:31:26
drmeister
The cc_makeCell is called, it allocates a CONS cell on the heap and returns it to be stored in the instructions output.
21:32:09
drmeister
But I'm not sure what ensures that the write to a cell has to happen after the allocation of the cell.
21:32:55
Bike
https://github.com/Bike/SICL/blob/master/Code/Cleavir/HIR-transformations/compute-ownership.lisp#L66-L89 this
21:40:04
drmeister
Another data point - if I start the compilation again mislib.lisp compiles fine and it crashes later on.
21:41:10
drmeister
But that should be bclasp generated code - which doesn't use cc_writeCell or cc_makeCell
21:54:27
drmeister
I'll put in a trap that will signal an error if a cc_writeCell gets a non cons cell.
21:56:36
drmeister
The CL backtrace doesn't make sense on second look. The convert-form is bclasp generated code and does not use cc_writeCell.
21:57:44
drmeister
This (http://llvm.org/docs/DebuggingJITedCode.html) and suggestions from #llvm have never worked for me.
1:37:50
drmeister
There are untagged pointers higher in the stack trace that I'm putting in tests/traps for.
2:02:52
drmeister
Bike: What do you think about a 'lint' for HIR/MIR? Something that checks to see if it's well formed?
2:04:42
drmeister
I'm suspecting that a writeCell is being invoked before a makeCell - but I'm not sure.
2:04:49
Bike
if you mean for stuff like "a cell is created before it's used" that's a little hard to check
2:12:00
drmeister
The stack above that call is weird - there are bad tagged pointers for function calls.