theruran has quit [Quit: Connection closed for inactivity]
rob_w has joined #picolisp
<
tankf33der>
hi all
<
tankf33der>
keep have fun with co
<
tankf33der>
abu[7]: is it a problem ?
<
tankf33der>
: (stack)
<
tankf33der>
-> ((T . 63) (T . 250) . 64)
<
tankf33der>
double T
<
abu[7]>
Yes, this is a bug
<
abu[7]>
How did you manage?
<
abu[7]>
So easy. I thought it is checked (reentrant)
<
abu[7]>
I will investigate a little later
<
abu[7]>
Ah, I know already, If this is the
*first* co call, T is not running yet
<
abu[7]>
I'll fix the check
<
abu[7]>
Tharks tankf33der!
<
tankf33der>
testing
<
tankf33der>
seems ok
<
abu[7]>
I just moved the T check to the front
<
abu[7]>
Hmm, wait,
taleon has quit [Remote host closed the connection]
taleon has joined #picolisp
<
tankf33der>
new crash
<
tankf33der>
is this illegal? :/
<
tankf33der>
abu[7]: away in 30min
<
abu[7]>
OK. Not suse. At least it is difficult to handle
<
abu[7]>
Starting a co in the error handler of a co
<
abu[7]>
We are in a limited stack segment here
<
abu[7]>
I'm not sure what exactly goes wrong
<
abu[7]>
The error should be handled in main, but then its state is gone
<
abu[7]>
Perhaps this can be improved on the error handling side (?)
<
tankf33der>
i do not know
<
abu[7]>
Tbe old crashed co is not yet cleaned up, and a new one is started
<
taleon>
Core dump also under OpenBSD.
<
tankf33der>
this is core issue
<
abu[7]>
Everywhere
<
abu[7]>
Probably the pil error handler in repeatedly crashed coroutines
<
abu[7]>
error in error handling is a co segment
<
abu[7]>
I can't reproduce in a simpler setup
<
abu[7]>
Maybe it is not even co-related
<
abu[7]>
(let (* 3 4)
<
abu[7]>
Now '*' is 3
<
abu[7]>
As long as in this error handler
<
abu[7]>
So calling anything which multiplies is guaranteed to crash
<
abu[7]>
Which is correct behavior
<
abu[7]>
And this (co 'b (let N (* 3 4))) does it!!
<
abu[7]>
So it is explained!
<
abu[7]>
Everything OK
<
abu[7]>
: (let (* 3) (* 3 4))
<
abu[7]>
Segmentation fault
payphone has quit [Remote host closed the connection]
cpli has quit [Remote host closed the connection]
payphone has joined #picolisp
cpli has joined #picolisp
rob_w has quit [Remote host closed the connection]
msavoritias has joined #picolisp
msavoritias has quit [Ping timeout: 255 seconds]
msavoritias has joined #picolisp
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #picolisp
bjorkintosh has joined #picolisp
<
tankf33der>
Since I can't find bugs in a proper way, I am doing illegal things with coroutines.
<
tankf33der>
cannot resist.
<
abu[7]>
This is very good
<
abu[7]>
Finds also bugs
<
tankf33der>
pasting
<
tankf33der>
cannot paste text now
<
tankf33der>
lets try picture
<
tankf33der>
eats 100% CPU on (gc)
fuxoft_mobile has quit [Quit: Connection closed for inactivity]
<
abu[7]>
Behaves ok here
<
tankf33der>
~99% reoeatable
<
tankf33der>
latest ever pil21
<
abu[7]>
Hmm, not here on Termux
<
abu[7]>
I try Debian
msavoritias has quit [Ping timeout: 255 seconds]
<
abu[7]>
Indeed! Hangs :)
<
abu[7]>
Can be shorter
<
abu[7]>
Just a co error and then (gc) (stack)
<
tankf33der>
first versions were 20 lines
<
abu[7]>
Strange, only if (gc) (stack) is on the snme line
<
tankf33der>
entered line collected on first gc call
<
tankf33der>
i have got bt from gdb
<
tankf33der>
very short
<
abu[7]>
Can you show?
<
abu[7]>
OK, this does not help
<
abu[7]>
Killed in some infinite loop
<
abu[7]>
The strange thing is that it chokes on text on the command line
<
abu[7]>
also hangs
<
abu[7]>
An error is not needed
<
abu[7]>
(co 'a (co 'b 7))
<
abu[7]>
I'm wrong :)
<
abu[7]>
It is just the reader
*waiting*
<
abu[7]>
because of the comment ☺
<
abu[7]>
So it needs a co error
<
abu[7]>
I suspect a bug in llvm~repl
<
abu[7]>
and/or llvm~stdEval
<
abu[7]>
looks all good
<
abu[7]>
It it a Heisenbug. Can't reproduce on Termux
<
abu[7]>
It is not the error handler: (catch '("") (co 'a (co T)))
<
abu[7]>
Ui, even worse:
<
abu[7]>
: (catch '("") (co 'a (co T)))
<
abu[7]>
-> "Reentrant coroutine"
<
abu[7]>
Segmentation fault
<
tankf33der>
good night. afk.