<Regenaxer>
But as it is heisen, trace may work or not :)
<Regenaxer>
Does behavior change if you do (gc 999) before test?
<beneroth>
trace works, shows pair returning, so it's not pair crashing
<beneroth>
gc 999 changes behaviour... no segfault
<Regenaxer>
OK, so it is a typical gc issue
<Regenaxer>
typical for such heisenbugs
<Regenaxer>
The reason lies before the crash happens
<beneroth>
ah with gc it still crashes, just much later
<beneroth>
yeah
<beneroth>
corrupt stack
<Regenaxer>
makes sense
<Regenaxer>
not stack but heap
<Regenaxer>
hard to localize
<beneroth>
problem is... with testing I find the small code change, which introduced this segfault... but I fear it's only triggered here, the corruption is somewhere else (many possibilities) :/
<Regenaxer>
Is it pil64?
<beneroth>
yeah
<Regenaxer>
Can you try pil21? It may behave differently
<Regenaxer>
or give an error
brandelune has quit [Quit: This computer has gone to sleep]
<Regenaxer>
Or does your code depend on pil64 somehow?
<beneroth>
pil21 runtime would be ok, but I might use some deprecated code I must clean up. this is the reason I haven't switched yet (well time needed to do that).
<Regenaxer>
I think usually only one point: "'arg' without arguments is not supported"
<Regenaxer>
ah, and cases of env offset args to \eval' and 'run'
<Regenaxer>
Do you have such cases?
<beneroth>
I believe so, yes. in DSL's
<Regenaxer>
I think switching to pil21 is really advisable
<beneroth>
T
<Regenaxer>
Best is to clean up the DSLs using (private) for all involved symbols
<beneroth>
Regenaxer, I put multiple (gc) calls into the code now. the segfault happens at X iterations of a function call. that implies that the corruption happens (execution-timewise) nearby and likely not much earlier, right?
<Regenaxer>
yes, usually a function being executed *while* next gc runs
<Regenaxer>
Can you make a core dump?
<Regenaxer>
ulimit -c unlimited
<Regenaxer>
Then we see with gdb and bt where it happens
<Regenaxer>
$ gdb pil21/bin/picolisp core
<Regenaxer>
...
<Regenaxer>
(gdb) bt
<Regenaxer>
...
<Regenaxer>
There are 2 possibilities
<Regenaxer>
1 it crashes *in* gc, then the heap was corrupted
<Regenaxer>
2 it crashes in some function whose data were wrongly collected
<Regenaxer>
(2) is more helpful usually
<beneroth>
thx, working on it
<Regenaxer>
Let's hope we find it
<beneroth>
I've enabled core dumping, but I cannot find the dump. Ubuntu 18.04. Internet says they are supposed to end up in /var/crash/
<Regenaxer>
You could (trace 'isa) to see the last call
<beneroth>
I think it's only pseudo-random that the segfault happens here, the corruption happens somewhere else
<Regenaxer>
yes
<beneroth>
problem is, it's a quite embedded piece of code which much context data, not feasible to mock up nor share
<Regenaxer>
the above pastebin does not crash here
<Regenaxer>
in pil21
<beneroth>
it probably entirely depends on the detailed structure of the Args list
<Regenaxer>
also not in pil64 (Termux)
<Regenaxer>
yeah
<Regenaxer>
and memory situation
<beneroth>
so you agree that the #works part should not have semantically any difference to the crashing variant (because 'isa implementation kinda does the same) and it must be a heisebug with a corrupted memory layout ?
<beneroth>
so even more memory situation, not Args
<beneroth>
ah btw. I do (gc) just before that code.
<Regenaxer>
both versions look ok
<Regenaxer>
Could use 'fish' probably
<beneroth>
I think (gc) has nothing to do with the issue. maybe (gc) moves the corruption around, but not causing it, I would think
<tankf33der>
How to run this code?
<tankf33der>
Your pastebin code does not contain Args list inside
<beneroth>
T. it is repeatedly called with another Args. deep nested lists.
<Regenaxer>
right, so my test here was meaningless
<tankf33der>
beneroth: add Args, it can not be repeated
<Regenaxer>
btw, the code seems not right
<beneroth>
T, that too xD
<Regenaxer>
in this examwle
<Regenaxer>
(isa as condition is alwyys true
<Regenaxer>
paren missing?
<Regenaxer>
((isa ...
<beneroth>
paren missing
<beneroth>
T
<Regenaxer>
ok
<Regenaxer>
anyway not the reason
<beneroth>
T
<beneroth>
it works correct now, but I fear still that the memory is corrupted.
<Regenaxer>
most probably
<beneroth>
which is potentially caused by any destructive function called long before this code comes, right?
<Regenaxer>
If it were pil21, we could compile some 'dbg' easily into the source of 'isa'
<Regenaxer>
right
<beneroth>
good advertisement :)
<Regenaxer>
can still be a gc issue
<Regenaxer>
pil21 also has a dbg
<tankf33der>
i did not receive a code with a crash
<Regenaxer>
I meant pil64 also has 'dbg'
<Regenaxer>
but harder to call
<tankf33der>
why you gonna add a dbg to isa call if you do not have a code crashes
<Regenaxer>
args must be pushed or so
<Regenaxer>
Not me
<Regenaxer>
beneroth could add
<tankf33der>
beneroth did not provide crashing code
<Regenaxer>
yes, cause it is complicated
<tankf33der>
picolisp code and data can be easily transferred from pc to pc
<beneroth>
I suspect the (fin Arg), that probably loops
<Regenaxer>
: (load "x")
<Regenaxer>
-----------------------------------
<Regenaxer>
[x:22] Stack overflow
<Regenaxer>
?
<beneroth>
oh nice
<beneroth>
do you have a good bakery nearby? I ought to send you a cake... :)
<Regenaxer>
haha, no, thanks! :)
<beneroth>
lets talk about that another time ;-)
<beneroth>
but I still don't see.. what is the semantic difference between the working and crashing variant?
<Regenaxer>
Good. We go on travel tomorrow, so unfortunately no time for a cake ;)
<beneroth>
ok
<Regenaxer>
Perhaps the stack suffices sometimes
<Regenaxer>
what if ulimit -s unlimited?
<beneroth>
I strongly suspect the (when (fin Args)) is logically wrong (I think it checks same endings multiple times?), but that is the same between both variants
<Regenaxer>
yes, still strange
<Regenaxer>
perhaps the stack overflow is also just a symptom?
<beneroth>
then I get "Killed" instead of segfaulting.. I guess killed by Linux out of memory manager
<Regenaxer>
corruption created some circularity
<Regenaxer>
yes
<Regenaxer>
stack unlimited gets killed eventually
<Regenaxer>
if you have swap, it gets slower and slower and then gets killed
<beneroth>
I think it must be the use of recurse.. though it's used extensively in both variants
<Regenaxer>
Let me try more
<beneroth>
the intention is, that all +Foo and +Bar gets found, wherever they are in this AST, even when the AST contains cons pairs.
<beneroth>
Args is factually an AST
<Regenaxer>
As I said, I would recommend 'fish'
<beneroth>
(well, prog)
<beneroth>
T
<beneroth>
Regenaxer, though what really is desired a 'fish which also checks atomar cdr values
<Regenaxer>
I think I knew what it is
<Regenaxer>
(uppc @)
<Regenaxer>
'@' is bound all the time to other values
<Regenaxer>
So you get infinite recursion
<Regenaxer>
(member @ ...) too
<beneroth>
yeah
<beneroth>
but the @ here should be quoted in Arg, not evaluated
<Regenaxer>
but it crashes on the first '@'
<beneroth>
T
<Regenaxer>
quote does not help
<Regenaxer>
it is not evaluated
<Regenaxer>
the value is taken
<Regenaxer>
but '@' is set in 'cond\
<Regenaxer>
'cond'
<Regenaxer>
always to new values
<beneroth>
right, the one which is used in (recur @)
<beneroth>
well no, before, in the condition
<beneroth>
you are right
<Regenaxer>
You should use 'fish\
<beneroth>
but the (uppc @) should not be evaluated or bound