theruran has joined #picolisp
ygrek has joined #picolisp
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
ygrek has quit [Remote host closed the connection]
rob_w has joined #picolisp
rob_w has quit [Ping timeout: 246 seconds]
rob_w has joined #picolisp
bjorkintosh has quit [Ping timeout: 260 seconds]
beneroth has quit [Quit: Leaving]
bjorkintosh has joined #picolisp
bjorkintosh has joined #picolisp
rob_w has quit [Remote host closed the connection]
bjorkintosh has quit [Ping timeout: 260 seconds]
bjorkintosh has joined #picolisp
ygrek has joined #picolisp
<
tankf33der>
hi all
<
tankf33der>
i have pushed fix for alpine linux port of picolisp and pipeline failed with ppc64le segfault while running built-in tests.
<
tankf33der>
i will install asap.
<
abu[7]>
Hi tankf33der!
<
abu[7]>
Interesting
<
tankf33der>
ppc64le crashes on coroutine
<
tankf33der>
(co 'a (* 3 4))
<
tankf33der>
crash!
<
abu[7]>
Hmm - stack perhaps
<
tankf33der>
will you check or ignore ?
<
abu[7]>
I don't know how to check
<
abu[7]>
Would be good if we knew where exactly it cashes
<
tankf33der>
trying run gdb without success
<
bjorkintosh>
since you tried it without success, try doing it this time
_with_ success.
* bjorkintosh
helped there.
<
tankf33der>
i added -g and omit pointers to clang in makefile
<
tankf33der>
not ok
<
abu[7]>
Very strange address
<
tankf33der>
i see it again and again
<
abu[7]>
0x707070707070717 is used as a fill marker in pil stack segments
<
abu[7]>
src/flow.l
<
tankf33der>
i run ./bin/picolisp
<
tankf33der>
without flow.l
<
abu[7]>
so some wrong indirection
<
abu[7]>
src/flow.l is the source
<
abu[7]>
(memset ... 7 ...)
<
abu[7]>
Thus we know it is a stack frame access problem
<
abu[7]>
But no idea about the real reason
<
tankf33der>
miss align?
<
tankf33der>
maybe ppc64le needs special clang keys
<
abu[7]>
not impossible
<
abu[7]>
align I mean
<
tankf33der>
new issue, summaryzing
<
tankf33der>
seems bigmath
<
tankf33der>
memoization
<
tankf33der>
(fibo 100) or 1000 works
<
tankf33der>
10000 crash this way
<
abu[7]>
Is there really a stack overflow?
<
tankf33der>
unknown.
<
tankf33der>
llvm 19.1.4
<
tankf33der>
latest 19.1.7
<
abu[7]>
version should not matter here
<
tankf33der>
i believe you
<
tankf33der>
if you modify somehow sources and i can run it here
<
abu[7]>
What happens if you run
<
abu[7]>
: (let N 0 (recur (N) (recurse (printsp (inc N)) (flush))))
<
abu[7]>
Should be something like
<
abu[7]>
1804 1805 1806 1807 1808 1809 1810 1811 !? ((N) (recurse (printsp (inc N)) (flush))) T -- Stack overflow ?
<
abu[7]>
Looks good
<
abu[7]>
So fibo should not overflow, uses less stack
<
tankf33der>
rest are all passed in pil21-tests
<
abu[7]>
Cached fibo does of course crash if stack frames exist
<
abu[7]>
: (co 'a (loop (yield)))
<
abu[7]>
-> ((a . 62) (T . 251) . 64)
<
abu[7]>
: (fibo 10000)
<
abu[7]>
!? ((N) (if (>= 2 N) 1 (+ (fibo (dec N)) (fibo (- N 2)))))
<
abu[7]>
T -- Stack overflow
<
abu[7]>
Give up: No stack
<
abu[7]>
But not with larger stack sizes
<
tankf33der>
(stack 128 128)
<
tankf33der>
crashes
<
abu[7]>
crashes here too
<
abu[7]>
(overflow)
<
abu[7]>
(stack 9999 9999) works
<
abu[7]>
~/pil21 ./pil misc/fibo.l +
<
abu[7]>
: (gc 400)
<
abu[7]>
: (stack 9999 9999)
<
abu[7]>
: (co 'a (loop (yield)))
<
abu[7]>
: (cachedFibo 10000)
<
abu[7]>
-> 336447648764317832666216..
<
tankf33der>
right now i think cache issue is not a problem
<
tankf33der>
false positive
<
abu[7]>
legal stack overflow ;)
<
abu[7]>
But coroutines
<
tankf33der>
short afk.
<
abu[7]>
I'm tired too
<
tankf33der>
lets continue if you have energy later
<
tankf33der>
or lets ignore it
<
tankf33der>
afk. sleep.
ygrek has quit [Ping timeout: 264 seconds]