ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
jibanes has quit [Ping timeout: 256 seconds]
jibanes has joined #picolisp
rob_w has joined #picolisp
mtsd has joined #picolisp
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #picolisp
mtsd has quit [Quit: Leaving]
orivej has quit [Ping timeout: 265 seconds]
mtsd has joined #picolisp
aw- has joined #picolisp
<Regenaxer> Hi aw-, welcome back!
<aw-> hi, thanks
orivej has joined #picolisp
<Regenaxer> tankf33der, I'm trying to locate the stress problem. Made a core, and it crashed in waitFd -> binRead -> cons
<Regenaxer> So it looks it is gc-related, perhaps not directly IPC
<Regenaxer> Can you also try to produce a core in various situations? Might give some hint
<Regenaxer> The problem is that it needs long runs until iy happens
<Regenaxer> I want to narrow it down
<Regenaxer> Just now I try with a bigger heap (gc 60) per child. If it does not crash, we have an indication that it is indeed gc-related
<Regenaxer> Meanwhile I'm manually inspecting the situation around the involved pieces of code
<Regenaxer> i.e. binRead
<Regenaxer> Perhaps you can run stress.l under gc+ (with a reduced number of processes)?
orivej has quit [Ping timeout: 260 seconds]
<tankf33der> tell me what to modify to reduce
<Regenaxer> I think no modification needed
<Regenaxer> But perhaps in gc+
<Regenaxer> ah, reduce processes?
<Regenaxer> (do 12 (do 99 (rand)
<Regenaxer> this means 99 child processes in parallel
<Regenaxer> So perhaps (do 12 (do 9 (rand)
<Regenaxer> not sure
<Regenaxer> perhaps 99 processes is ok too
<Regenaxer> just to see if we get any insight
<Regenaxer> I see if I can modify the interpreter to do some stack frame check
<tankf33der> trying
<Regenaxer> ha, found one bug! But not related here
<Regenaxer> (line T 1 2 3) leaves an unbalanced stack
<Regenaxer> will fix
<Regenaxer> But this kind of 'line' call does not happen in stress
<Regenaxer> Yes, seems this was the only case
<Regenaxer> I try to do more such plausability checks
<tankf33der> no crashes so far
<tankf33der> laptop is hot and noisy
<Regenaxer> oh
<Regenaxer> hmm
<Regenaxer> yeah, takes many random runs
<Regenaxer> OK, better save your hardware!
<Regenaxer> I think more
<Regenaxer> Hmm, something else became strange
<Regenaxer> The REPL ignores the first typed char now
<Regenaxer> Must have to do with the event handler :(
<tankf33der> sym-OK
<tankf33der> system-OK
<tankf33der> tomohiko-OK
<tankf33der> make: *** [Makefile:4: m] Segmentation fault (core dumped)
<tankf33der> it not stress, but something new
<Regenaxer> yeah
<tankf33der> io.l
<tankf33der> maybe line :)
<Regenaxer> I dont think so
<Regenaxer> It was wrong only for (line T 1 2 ...
<Regenaxer> not (line) or (line NIL) or (line T)
<Regenaxer> Very special call ;)
<Regenaxer> Found a stack-save bug in 'consTree'
<Regenaxer> 'Lst' was not safe
<tankf33der> (test (1 2 3) (~(1 2) 3))
<tankf33der> (test (1 3) (~(1 . 2) 3))
<tankf33der> these two lines crashes under gc+
<Regenaxer> oh, I see
<tankf33der> rest are OK
<tankf33der> keep running
<Regenaxer> Let me first fix the repl bug
<Regenaxer> Did you also observe it?
<tankf33der> yes, i cant enter first char
<Regenaxer> yeah, strange
<Regenaxer> Found it. Stupid mistake yesterday
<tankf33der> @lib/test.l crashes too
<Regenaxer> Really? I tested it here after any change
<tankf33der> :)
<tankf33der> this is not io.l, already disabled.
<tankf33der> something new.
<Regenaxer> Let me fix the repl bug and release
<Regenaxer> so that we are both on the same state
<Regenaxer> Released
<Regenaxer> I started stress/9 again
<Regenaxer> Will check (~(1 . 2) 3)) now
<tankf33der> @test.l crashes in test/src/main.l
<Regenaxer> For (~(1 2) 3)) or (~(1) 3)) it does not crash?
<Regenaxer> hmm, here full test.l passes
<tankf33der> $ pil21 +
<tankf33der> : (~(1 2) 3))
<tankf33der> Segmentation fault (core dumped)
<Regenaxer> Interesting
<Regenaxer> And what crashes in test/src/main.l?
<tankf33der> finding. reducing path.
<Regenaxer> ok
<Regenaxer> I check the read macro
<Regenaxer> I changed something a few days ago
<tankf33der> http://ix.io/2BfH
<tankf33der> this code crashes from main.l
<Regenaxer> Strange, I see nothing suspicious
<Regenaxer> Crashes only under gc+?
<tankf33der> yeap
libertas has quit [Quit: ZNC - https://znc.in]
libertas has joined #picolisp
<Regenaxer> (0 ~(1 2) 3) does not crash?
<tankf33der> no crash
<tankf33der> BTW:
<tankf33der> [mpech@lambda ~]$ /home/mpech/pil21/bin/picolisp
<tankf33der> Segmentation fault (core dumped)
<tankf33der> : (~(1) 3))
<tankf33der> : (~(1) 3))
<tankf33der> [mpech@lambda ~]$ pil +
<tankf33der> ?
<tankf33der> Bad input ')'
<tankf33der> [mpech@lambda ~]$
<tankf33der> pil21 crashes because of last ')'
<Regenaxer> ok, I think I know the problem of the ~ and gc
<Regenaxer> compiler builds wrong code
<Regenaxer> might also explain crash after ')'
<Regenaxer> I must understand why wrong code is generated
mtsd has quit [Quit: Leaving]
<Regenaxer> stress.l crashed
<tankf33der> still running here.
<Regenaxer> Here crashed in the first pass
<Regenaxer> similar place, cons in binRead
<Regenaxer> ok, first the ~ issue
<Regenaxer> Then perhaps (file)
<tankf33der> what llvm-config --version output of pc you running stress.l ?
<Regenaxer> This is surely irrelevant
<tankf33der> ok
<Regenaxer> llvm version
<Regenaxer> it is timing and memory
<Regenaxer> such things
<Regenaxer> Must happen at exactly the wrong place
<tankf33der> now running stress.l under 12-99
<Regenaxer> good
<Regenaxer> I know what the problem with ~ is
<Regenaxer> tricky case
<Regenaxer> OK, I think I fixed it
<Regenaxer> Released
<Regenaxer> Can you test ~ under gc+ again?
<tankf33der> sure.
<Regenaxer> Lets hope it is ok now
rob_w has quit [Remote host closed the connection]
<tankf33der> i see its ok now
<Regenaxer> Great! :)
<Regenaxer> gc+ is indeed helpful
<Regenaxer> What might be wrong with (file)?
<tankf33der> unknown
<Regenaxer> Perhaps the pathname?
<Regenaxer> Can you manually test the parts under gc+ ?
<Regenaxer> (file)
<Regenaxer> and (cons (tmp) "file" 1)
<tankf33der> let me try now.
Blukunfando has quit [Ping timeout: 258 seconds]
<Regenaxer> or is it the (load ..), i.e. reading the string?
<Regenaxer> I check (file)
<Regenaxer> hmm, (file) itself is too simple
<tankf33der> no crash if this:
<tankf33der> http://ix.io/2BfS
<Regenaxer> ok
<tankf33der> but crashes if i uncomment test
<Regenaxer> the matching?
<tankf33der> yea
<Regenaxer> (mapc trace '(test match file ...
<Regenaxer> Experiment in the repl
<tankf33der> only this combination, because all other tests always passed before.
<Regenaxer> single step or trace perhaps
<Regenaxer> yeah
<Regenaxer> But gc+ is very strict :)
<tankf33der> do you need backtrace ?
<Regenaxer> no
<Regenaxer> I think normal trace is best
<Regenaxer> perhaps file returns garbage which causes match to crash or so
<Regenaxer> trace lets you see what happens at each step
<Regenaxer> I need to know which primitive function fails
<tankf33der> $ pil21 t1.l +
<tankf33der> test : ("/home/mpech/.pil/tmp/315897/" "file" . 1) ((out (tmp "file") (println '(file))) (load (tmp "file")))
<tankf33der> file :
<tankf33der> Segmentation fault (core dumped)
<Regenaxer> good
<Regenaxer> hmm
<Regenaxer> but (file) is not *called* in the above, right?
<Regenaxer> ah
<Regenaxer> in (load ..)
<tankf33der> http://ix.io/2BfV
<tankf33der> i've added more functions and see:
<tankf33der> $ pil21 t1.l +
<tankf33der> cons : "/home/mpech/.pil/tmp/315951/" "file" 1
<tankf33der> cons = ("/home/mpech/.pil/tmp/315951/" "file" . 1)
<tankf33der> test : ("/home/mpech/.pil/tmp/315951/" "file" . 1) ((out (tmp "file") (println '(file))) (load (tmp "file")))
<tankf33der> (file)
<tankf33der> out = (file)
<tankf33der> out : "/home/mpech/.pil/tmp/315951/file" (file)
<tankf33der> load = NIL
<tankf33der> load : "/home/mpech/.pil/tmp/315951/file"
<tankf33der> match : ("/home/mpech/.pil/tmp/315951/" "file" . 1) NIL
<tankf33der> match = NIL
<tankf33der> out : 2 ((out (tmp "file") (println '(file))) (load (tmp "file"))) NIL
<tankf33der> ((out (tmp "file") (println '(file))) (load (tmp "file")))
<tankf33der> out = NIL
<Regenaxer> then crash?
<tankf33der> ping
<tankf33der> ping
<tankf33der> [t1.l:3] ("/home/mpech/.pil/tmp/315951/" "file" . 1) -- 'test' failed
<Regenaxer> (file) should be executed inside (load ...
<tankf33der> ?
<Regenaxer> Above the crash was directly in (file)
<Regenaxer> file :
<tankf33der> let me run again and post a full output
<Regenaxer> It seems inside (file)
<Regenaxer> but file does not do much
<Regenaxer> The heap is damaged before that probably
<tankf33der> http://ix.io/2BfW
<tankf33der> this is what i see when run file under pil64 and pil21
<tankf33der> this is a code:
<tankf33der> http://ix.io/2BfV
<tankf33der> i must run away in 10minis.
<Regenaxer> ok, me too
<Regenaxer> Let's continue later then
<Regenaxer> I'll think about it meanwhile
<tankf33der> ok
orivej has joined #picolisp
Blukunfando has joined #picolisp
<tankf33der> my experiments with file and load for pil21 and 64:
<tankf33der> http://ix.io/2Bh0
<Regenaxer> Wow, {FLEF5633064546}
<Regenaxer> Only with gc+ ?
<Regenaxer> The question is if the name is already wrong in the file structure, or just messed up by (file)
<Regenaxer> What if you produce an error?
<Regenaxer> It also prints the internal file
<Regenaxer> e.g. put (/ 1 0) into the file and (load) it
<tankf33der> anyway @lib/test.l still crashes, something new.
<tankf33der> doing (/ 1 0)
<Regenaxer> good
<tankf33der> $ pil21 +
<tankf33der> : (load "/home/mpech/file.l")
<tankf33der> [/home/mpech/file.l:1] !? (/ 1 0)
<tankf33der> Div/0
<tankf33der> ?
<tankf33der> $
<Regenaxer> Ah, good
<Regenaxer> [/home/mpech/file.l:1]
<Regenaxer> so the path is correct internally
<Regenaxer> Now it must be (file) itself
<Regenaxer> it must be 'mkStrE'
<Regenaxer> Ah!!!
<Regenaxer> Not 'mkStrE'
<Regenaxer> It is (file), it does not save the value from 'mkStrE'
<Regenaxer> Stupid error!
<tankf33der> reducing crash path, @lib/test.l
<tankf33der> reducing crash path, @test/lib.l
<Regenaxer> ok, thanks
<Regenaxer> I released fixed 'file'
<Regenaxer> can you try?
<Regenaxer> (file) is not used in stress.l though
<tankf33der> later, running another crash
<Regenaxer> ok, no hurry
<tankf33der> i have to stop and rebuild
<tankf33der> strange
<Regenaxer> ok
<Regenaxer> I'm checking 'binRead'
<Regenaxer> something strange
<Regenaxer> hm, no, is
<Regenaxer> ok
<Regenaxer> But it always crashed inside 'binRead'
<tankf33der> (file) is oko
<tankf33der> (file) is ok
<Regenaxer> Great, thx
<Regenaxer> Unfortunately not used in stress.l
<tankf33der> now all today issues closed.
<tankf33der> pil @lib/test.l +
<tankf33der> also ok
<Regenaxer> really?
<Regenaxer> You said something in lib (?)
<tankf33der> it was because of file
<tankf33der> crash between loads
<tankf33der> now all passed.
<Regenaxer> Good to know
<Regenaxer> So I start stress/9 again
<tankf33der> never crashed here :)
<tankf33der> i played all friday
<Regenaxer> Yeah
<Regenaxer> perhaps my setup
<Regenaxer> Or it is indeed fixed with today's changes
<Regenaxer> (though I doubt it)
<tankf33der> damn
<tankf33der> http://ix.io/2Bhl
<tankf33der> on my laptop with llvm10 this run is ok
<tankf33der> on envs's server with debian and llvm7 it crashed.
<tankf33der> i belive now sources are the same on two sides of run.
<tankf33der> maybe thats why you see crashes all the time and I never in llvm10.
<Regenaxer> oh
<tankf33der> yea.
<Regenaxer> It may be the same heisenbug as in stress.l
<tankf33der> tomorrow I will reduce debian run and find where it crashes.
<tankf33der> and it will be ok on llvm10! :)
<Regenaxer> Cool
<tankf33der> under gc+ !!!
<tankf33der> all i written above is under gc+
<Regenaxer> ok
<Regenaxer> I run these stress.l tests under Clang 9.0.1
<Regenaxer> (according to lib/sysdefs)
<tankf33der> ok
<tankf33der> or forgot to commit something.
<tankf33der> doing run again
<Regenaxer> How do you determine llvm versions?
<tankf33der> llvm-config --version
<Regenaxer> ok, I always forget ;)
<Regenaxer> also gives 9.0.1
<Regenaxer> (on the test server)
<Regenaxer> On Termux I have 10.0.1
<Regenaxer> but I don't do the stress test there
<Regenaxer> only with less processes
<tankf33der> fuh
<tankf33der> it was my mistake -
<tankf33der> llvm7 and llvm10 both ok now
<Regenaxer> I see
<tankf33der> afk.
<tankf33der> tired. :)
<Regenaxer> ok :)
<Regenaxer> nuff for today
<Regenaxer> Thanks a lot!
<Regenaxer> I keep stress/9 running
<Regenaxer> Perhaps repeating, until I get another core
<Regenaxer> stress/9 crashed
Blukunfando has quit [Remote host closed the connection]
Blukunfando has joined #picolisp