<abu[7]>
I can reproduce on Debian, but not on Termux
<abu[7]>
Don't worry, must be a simple logical error
<tankf33der>
debian ok, alpine crash
<tankf33der>
freebsd crash
<abu[7]>
Strange, this was not a big change
<abu[7]>
Must be some stupid mistake
<tankf33der>
ok, no hurry
<abu[7]>
I don't get it! It is a minimal chance
<abu[7]>
Seems a compilation issue. If I insert a 'dbg' call, it vanishes.
<tankf33der>
freebsd - llvm15, alpine - llvm17, both crashed
<abu[7]>
No idea
<abu[7]>
I have a blackout it seems
<tankf33der>
trying llvm-16 on openbsd
<abu[7]>
No, it is a logical error on my side
<tankf33der>
openbsd failed too, Debian still ok :)
<abu[7]>
Here Termux OK but Debian crashes
<abu[7]>
I revert the release for now, to prevent disaster
fuxoft has joined #picolisp
<fuxoft>
Hello. I've got a question which is probably more about Linux terminal and less about PicoLisp: I've got a PicoLisp script that endlessly calculates audio data and streams them to speakers using aplay. This script cannot be stopped using Ctrl + C. How can I occassionally check from PicoLisp if Ctrl + C (or something else) was pressed and act
<fuxoft>
accordingly (I.e. kill the generator)? Something like "Is Ctrl+C present in the keyboard input buffer? If not, generate another 10000 samples, repeat."
fuxoft has quit [Quit: Client closed]
<abu[7]>
Why can it not be stopped with ^C?
<abu[7]>
In repl, ^C breaks
<abu[7]>
breakpoint I mean
<abu[7]>
wher no repl was started, ^C terminates
fuxoft has joined #picolisp
<abu[7]>
SIGINTR
<fuxoft>
When I press Ctrl C, the system sends SIGINTR to my PicoLisp script and I handle it how...?
<abu[7]>
It is hardcoded
<fuxoft>
So I should be able to interrupt my script by pressing Ctrl + C? I am unable to.
<fuxoft>
Only "^C" appears in the terminal.
<abu[7]>
If you start a repl, you get a debug breakpoint
<tankf33der>
first time was in your pil21 development period
<abu[7]>
You mean "using"?
<tankf33der>
i played with pil21 every day since it was released
<abu[7]>
Good :)
<abu[7]>
Now I looked at the coredump, but see np useful info
<abu[7]>
Is it possibly an optimizer bug?
<tankf33der>
no, not so easy
<tankf33der>
i've tried three different llvm
<tankf33der>
this is stack
<abu[7]>
I saw problems with -O3 often over the years in several compilers
<tankf33der>
eh
<abu[7]>
ok, on Debian -O2 does not help
<tankf33der>
what llvm version ?
<abu[7]>
16.0.6
<tankf33der>
llvm18 is ok on latest debian
<tankf33der>
address sanitizer didnot help, all ok
fuxoft has quit [Quit: Client closed]
<abu[7]>
On Termux I have 18.1.7
<tankf33der>
stable
<abu[7]>
No crash on Termux
<abu[7]>
-O1 gives no crash on Debian too
<tankf33der>
maybe structures overlay
<abu[7]>
How?
<tankf33der>
because you added something
<abu[7]>
I don't think so. Nothing added recently, and the struct sizes are calculated automatically
<tankf33der>
what you changed recently?
<tankf33der>
auto updater detected something new
<tankf33der>
and now everything is working
<abu[7]>
I did a small change this morning (a 'cond' to a smaller 'cond' and an 'if'), and then reverted back to have a working public release on software-lab
<tankf33der>
ok, works
<abu[7]>
Yes, but with yesterdays problems
<tankf33der>
yeap
<abu[7]>
ie non-sym tag
<abu[7]>
(co 1 7) (co 2 7)
<abu[7]>
The change this morning fixed that
<abu[7]>
The only way I see atm is -O1
<tankf33der>
never stepped-in in so many releases
<abu[7]>
:)
<abu[7]>
You think -O is not the real reason?
<tankf33der>
It will be a magical turn of events.
<abu[7]>
I see no logical reason
<tankf33der>
so many releases, so many OS
<abu[7]>
T
<abu[7]>
But most crasch with -O3, right?
<tankf33der>
yeap
<abu[7]>
Debian works only with -O1
<abu[7]>
llvm 16
<abu[7]>
ok, I check the generated optimized result in picolisp.s
<abu[7]>
Tedious. Give up.
<abu[7]>
Should I try llvm 18 on Debian?
<abu[7]>
Did you have cases where it did *not* work in 18?
<tankf33der>
never
<tankf33der>
all these years from start
<abu[7]>
never worked? or never tried?
<tankf33der>
always works
<abu[7]>
in 18?
<tankf33der>
yeap
<abu[7]>
Hmm
<abu[7]>
Here on Termux too
<abu[7]>
What would you do?
<abu[7]>
Version check in Makefile?
<abu[7]>
-O1 vs. -O3
<abu[7]>
or don't you think it is the optimizer?
<tankf33der>
i cannot believed this LLVM's issue
<abu[7]>
It is possible that the optimizer chokes because now a longjmp() happens to be at the end of a 'cond'
<abu[7]>
a flow change
<tankf33der>
is it the only longjmp call ?
<abu[7]>
Perhaps clang never outputs such code
<abu[7]>
No, very many
<abu[7]>
throw, co, yield, err
<tankf33der>
all these works
<abu[7]>
all based on setjump/longjmp
<abu[7]>
Yes, and
<abu[7]>
now the only change is a little change in the flow
<abu[7]>
The longjmp's of course work. But a longjmp() call never returns, and the optimizer knows that probably, and can do fancy things at the end of a cond statement where hewould normally compile a jump after the function returns (different in case of functions like longjump(), exit() etc.)
<abu[7]>
That's what an optimizer does
<tankf33der>
this is sounds reasonable now
<tankf33der>
i like this idea
<abu[7]>
The developers test only with clang
<abu[7]>
Is -O1 a lot slower?
<tankf33der>
let me check
<tankf33der>
1.8 sec -O3
<tankf33der>
1.816 sec -O3
<tankf33der>
1.816 sec -O1
<abu[7]>
oh
<abu[7]>
I try on Termux
<abu[7]>
Same speed, and the size is a uittle smaller!
<abu[7]>
*little
<tankf33der>
what if add noreturn to longjmp call
<abu[7]>
It has
<tankf33der>
do you see no longjmp call in binary output
<tankf33der>
?
<abu[7]>
Yes, it is a function
<abu[7]>
libc
<abu[7]>
call void @longjmp(i8* %60, i32 1)
<abu[7]>
unreachable
<abu[7]>
(in base.ll)
<abu[7]>
Without -O at all it gets 20% slower
<abu[7]>
but still smaller!!
<tankf33der>
size does not matter
<abu[7]>
Right
<tankf33der>
how to prove this is llvm's issue ?
<abu[7]>
Good question!
<abu[7]>
In any case it seems pil does not need -O3 or -O2
<tankf33der>
yeap
<abu[7]>
Shall I release with -O1 and you test on your systems?
<tankf33der>
yeap
<abu[7]>
👍
<abu[7]>
Done
<tankf33der>
debian machine which worked
<tankf33der>
no crashes in co
<abu[7]>
Great!
<tankf33der>
oops
<tankf33der>
stop
<tankf33der>
forget
<abu[7]>
:(
<tankf33der>
i wrote shit
<tankf33der>
again:
<tankf33der>
debian machine which always worked before
<tankf33der>
now crashes in co
<abu[7]>
Oh
<tankf33der>
next tests are useless
<abu[7]>
sigh
<tankf33der>
this is prove this is not llvm's issue
<abu[7]>
hmm
<tankf33der>
freebsd crashes
<tankf33der>
alpine-linux ok
<abu[7]>
Revert to -O3 ?
<tankf33der>
insane.
<tankf33der>
no
<tankf33der>
You still have time
<abu[7]>
T
<tankf33der>
you have to return back to the bug when you will have enough energy