freenode/#clasp - IRC Chatlog
Search
14:06:38
drmeister
::notify Bike - The latest sicl breaks the compilation of cclasp. I switched back to the call-with-variable-bound function but that didn't fix it. So I reset the sicl repo to commit 8f63732 (the one I had yesterday) - that builds through the problem.
14:11:35
drmeister
::notify Bike Debugging this problem the normal way will be challenging because there is no debug info on the code that is generating the problem. It's JITted Cleavir code. Maybe git bisect could help here?
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.