<aw->
tankf33der: great work helping Regenaxer to test pil21, it's really admirable
<tankf33der>
:)
<Regenaxer>
Great, that rules out 'for' too
<Regenaxer>
So it is a general problem, not related to a specific function
<Regenaxer>
I hope I don't need to rewrite *everything*
libertas has quit [Ping timeout: 260 seconds]
<Regenaxer>
Now in 'cons', not inside 'gc'
<Regenaxer>
Do you have the asm instruction?
<tankf33der>
#0 cons () at picolisp.s:33923
<tankf33der>
33923 movq (%rax), %rcx
<Regenaxer>
thx
<Regenaxer>
Null pointer
libertas has joined #picolisp
orivej has joined #picolisp
<Regenaxer>
Can't reproduce a crash with all variants
<Regenaxer>
Perhaps it really depends on the llvm version?
<tankf33der>
i dont think so
<tankf33der>
already repeated on llvm7
<tankf33der>
today
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #picolisp
<beneroth>
Regenaxer, nothing to worry or do about, but I just found out that (rel foo (+IdxFold +Ref +String)) (notice the +Ref, which is wrong/should not be there) leads to immediate segfault (during the +index construction)
<beneroth>
pil64
<beneroth>
dunno if this is acceptable or if I should investigate and maybe we can adapt some T message to give an error instead of ugly segfault
<beneroth>
I guess somehow a symbol which is not a func gets executed somehow
<Regenaxer>
Thanks beneroth!
<Regenaxer>
Perhaps you can look with 'traceAll' to see where it fails
<beneroth>
ok will investigate
<beneroth>
later today
<beneroth>
must be in +index construction
<Regenaxer>
As you say, nothing to worry about ;)
<beneroth>
T
<beneroth>
just cost me some time now, I was so happy to having finished import parsing and db schema, and then it just.. segfaults xD
<Regenaxer>
yes, the +IdxFold calls the +Ref indexing several times
<beneroth>
yeah question is which T message causes the segfault :)
<beneroth>
it's an invalid combination, but immediate segfault is a bit harsh :)
<Regenaxer>
Ah, still in T ?
<beneroth>
I believe so
<Regenaxer>
so not yet indexing
<Regenaxer>
ok
<Regenaxer>
no worry
<beneroth>
yes, just loading of the schema definition
<beneroth>
no data operation
orivej_ has quit [Ping timeout: 256 seconds]
<tankf33der>
(loop
<tankf33der>
(let L (list 1))
<tankf33der>
)
<tankf33der>
this is smallest thing i can create which crash on modified gc.
<tankf33der>
crash on ~54K iteration.
elioat has joined #picolisp
<beneroth>
maybe its the memory allocation
<tankf33der>
or races between gc and stack operations.
<tankf33der>
or heap corruption while racing between gc and stack.
<beneroth>
that sounds very mean
<Regenaxer>
yeah
<Regenaxer>
Memory allocation does not happen in the above loop
<Regenaxer>
Just adding and removing stack structures (binding 'L' in this case)
<Regenaxer>
Unfortunatel none of the cases crash here
<Regenaxer>
I take a closer inspection of 'gc' itself latea
<Regenaxer>
later
<tankf33der>
ok
orivej has joined #picolisp
orivej has quit [Read error: Connection reset by peer]
orivej has joined #picolisp
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
<tankf33der>
found more small code to crash with modified gc.