<Regenaxer>
You can then put also styles to <ul> and <li>
<rob_w>
i am wrapping it to function, as i need it a few times , then i will test that too
<Regenaxer>
good
<Regenaxer>
tankf33der here?
<Regenaxer>
It seems we still have a gc bug :(
<tankf33der>
here
<Regenaxer>
hi :)
<rob_w>
Regenaxer: the <ul> seems to not work for me
<Regenaxer>
oh
<tankf33der>
hi all
<rob_w>
hi tankf33der
<tankf33der>
Regenaxer: how bug triggered? any hints?
<Regenaxer>
tankf33der, when I make the newest release with ../pil, I get
<Regenaxer>
llvm-as: base.ll:87216:11: error: expected value token ret i64 void
<Regenaxer>
the 'void' is wrong
<tankf33der>
something new.
<Regenaxer>
It outputs correct code with pil64
<tankf33der>
i test almost all releases and did last 10 or 20.
<Regenaxer>
or with -"gc 999"
<Regenaxer>
I did always build with pil21
<Regenaxer>
If I just remove one line from the source, it works
<Regenaxer>
A real heisenbug again
<Regenaxer>
tough to find
<tankf33der>
i always did the same
<Regenaxer>
Can you see if it reproduces on your system?
<Regenaxer>
I just released that version
<tankf33der>
i will do asap
<Regenaxer>
thanks!
<Regenaxer>
I can reproduce on Termux and Debian
<Regenaxer>
It seems to depend on *exact*ly that source
<Regenaxer>
so that gc happens in just the right moment
<Regenaxer>
*if* you can reproduce, please try with your gc+
<Regenaxer>
Perhaps we can find the faulty function
<tankf33der>
ok
<Regenaxer>
I think I saw exactly that error in the beginning
<Regenaxer>
then we found some gc issues, and it vanished
<Regenaxer>
But now I think we never fixed it :(
<Regenaxer>
From the place of the wrong code, I think it has to do with the global '*Phi'
<Regenaxer>
It must be one of the functions that maintain *Phi
mtsd has quit [Quit: mtsd]
<tankf33der>
80% done, no problems so far
<Regenaxer>
difficult
<Regenaxer>
I'm meanwhile inspecting all related sources
<Regenaxer>
Could you reproduce the error without gc+ ?
<tankf33der>
yes
<tankf33der>
pil21 cant create base.ll
<Regenaxer>
good!
<tankf33der>
with gc+
<tankf33der>
oops
<tankf33der>
without gc+
<tankf33der>
.
<Regenaxer>
Well, pil21 can create base.ll, but that one line is wrong
<tankf33der>
yeap.
<Regenaxer>
I suspect that with gc+ we cannot reproduce it any longer
<Regenaxer>
Any change in the code makes the point move somewhere else
<Regenaxer>
Ideally we could somehow trace both pil21 and pil64 and see where it gets different
<Regenaxer>
I try to 'trace' some functions, redirect stderr to files, and 'diff' those
<Regenaxer>
Hmm, as soon as I start in debug mode with '+', the error disappears :(
<Regenaxer>
Can't pin it down
orivej has quit [Ping timeout: 260 seconds]
<Regenaxer>
It must be a function which is seldom called
<beneroth>
interupt?
<Regenaxer>
Then it would not happen each time and on every system
<Regenaxer>
It must be gc
<Regenaxer>
if we call (gc 999) or start in debug mode, it disappears
<Regenaxer>
But surely not timing-related
<Regenaxer>
I know the result appears here:
<Regenaxer>
(for L (cdr (asoq X *Phi))
<Regenaxer>
(when (cadr L)
<Regenaxer>
(prin
<Regenaxer>
" " (cadr L) " = phi "
<Regenaxer>
<Regenaxer>
*Phi has NIL in one of the car's
<Regenaxer>
So every place that manages *Phi is relevant
<Regenaxer>
There are not so many places
<Regenaxer>
It is modified *only* in (de phi (Lbl Var)
peterhil has joined #picolisp
<Regenaxer>
assoc, conc, list, queue
<Regenaxer>
I checket those visually, but think they look good
<Regenaxer>
queue is the only one used seldom
<Regenaxer>
hmm
<Regenaxer>
or it is not *Phi but *Curr, it is 'cons'ed into the list
<Regenaxer>
if *Curr were NIL ...
<Regenaxer>
No, it is more complicated
<Regenaxer>
The lists is patched during forward references
<Regenaxer>
so it can be everywhere :(
<Regenaxer>
(list Var NIL (cons *Curr ...
<Regenaxer>
the NIL is patched
<tankf33der>
still playing, no result.
<Regenaxer>
yeah, I think gc+ changes the env, so it will not happen
<beneroth>
assoc in place of asoq?
<beneroth>
hm
<beneroth>
sounds like the only way is playing around
<Regenaxer>
yeah
<beneroth>
and in the end its something obvious in hindsight, I hate those...
<Regenaxer>
right, always!
<Regenaxer>
You think assoc would change something?
<beneroth>
no, just random poking around. I have no expertise.
<Regenaxer>
Any idea welcome
<beneroth>
the (when (cadr)) cannot be it
<Regenaxer>
I think it causes the missing line
<Regenaxer>
most surely
<Regenaxer>
or the whole line is missing
<Regenaxer>
I put a 'msg' there and tried to 'diff'
<beneroth>
are all negative branches correctly handled? meaning (asoq) when X or *Phi is NIL, cdr when called with nil... such things... (well I'm sure you tested everything out of it...)
<Regenaxer>
but the line contains (box)ed symbols
<Regenaxer>
so always different
<beneroth>
hm
<beneroth>
anonymous boxes are pretty close to pointer games :)
<Regenaxer>
:)
<Regenaxer>
it needs to generate symbols
<Regenaxer>
for forward labels iirc
<beneroth>
so memory allocation, therefore (gc) makes the difference...
<Regenaxer>
right
<beneroth>
question is then if the error happens during allocation, or in the input which causes them...
<beneroth>
hm
<beneroth>
just random ideas
<Regenaxer>
memory allocation happens all the time
<beneroth>
I'm on a hard deadline, no time to play around :(
<beneroth>
yeah
<Regenaxer>
already when reading the source .l files
<Regenaxer>
No worry!
<beneroth>
internal memory allocation for local bindings? e.g. internal stuff from (for) ?
<beneroth>
hm
<beneroth>
you probably better search yourself than listening to my random ramblings :)
<Regenaxer>
It must be something seldom
<Regenaxer>
No, thanks for input! :)
<Regenaxer>
If it were a common, often used function, we would have found it I think
<beneroth>
if its not memory allocation, than maybe in the step when this new memory gets written or read... and something was not written correctly, which might be the cause - or the cause is in the input issueing the memory operations...
<Regenaxer>
all of tankf33der's tests
<beneroth>
could be very special case of something common...
<beneroth>
but yeah
<Regenaxer>
All of those gc things are errors in stack saves
<Regenaxer>
saving intermediate results
<tankf33der>
all trivial tests passed.
<tankf33der>
no lucky so far.
<Regenaxer>
T
<beneroth>
can you somehow verify intermediate results / intermediate stack state?
<Regenaxer>
yes, tankf33der's gc+ test does that
<Regenaxer>
it forces a gc at any possible point
<Regenaxer>
hoping to get a crash
<beneroth>
nice idea
<tankf33der>
running under clang's sanitizer.
<beneroth>
profiling with valgrind?
<Regenaxer>
Valgrind wont help
<Regenaxer>
it adresses mallocs
<beneroth>
T
<beneroth>
its in the internal memory handling
<beneroth>
right, i see
<Regenaxer>
but malloc is only for large heap chunks
<Regenaxer>
or some strings in native calls etc
<beneroth>
T
<Regenaxer>
Perhaps we can improve gc+ ?
<beneroth>
something writes too much or too little somewhere, it sounds like
<Regenaxer>
Not waiting for crash
<Regenaxer>
but active checks?
<beneroth>
or giving more output, which steps were happening right before crash?
<Regenaxer>
yes
<beneroth>
or repeating the issue until crash is found multiple times
<beneroth>
a fuzzy oracle
<beneroth>
yeah active checks
<Regenaxer>
Problem is that it crashes not at all
<beneroth>
I see
<Regenaxer>
Just forgets data
<beneroth>
gc+ should output something so you can re-run the exact same test, kinda a list of the random choices it took
<Regenaxer>
yes, and then diff with the correct version
<Regenaxer>
if the memory is destroyed, it is from somewhere else
<beneroth>
(buf) or BUFSIZ
<Regenaxer>
only (buf)
<beneroth>
BUFSIZ is always the same?
<beneroth>
const
<Regenaxer>
yes, a const
<Regenaxer>
This outfile stuff is used all the time
<beneroth>
so maybe (buf) happens somehow to be smaller than BUFSIZ?
<Regenaxer>
the problem may be at some distant point
<beneroth>
yeah tricky chained bug
<beneroth>
T
<beneroth>
usually one needs C++ to produce such :P
orivej has joined #picolisp
<Regenaxer>
well, on that level we are close
<Regenaxer>
to C++ like stuff
<Regenaxer>
(struct outFile
<Regenaxer>
(ix 8 i64) # Buffer index
<Regenaxer>
(fd 4 i32) # File descriptor
<Regenaxer>
(buf BUFSIZ i8) # Buffer
<Regenaxer>
(tty 1 i1) ) # TTY flag
<Regenaxer>
the buffer is fixed size in the struct
<Regenaxer>
So it does not help
<beneroth>
when is this struct instanced? on every (Out:) fresh?
<Regenaxer>
yes, every out channel has its own
<Regenaxer>
Same code in all pils
<Regenaxer>
since pil-1998 iirc
aw- has joined #picolisp
<Regenaxer>
pil32 and pil64, not mini or ersatz I think
<beneroth>
maybe add some code which always initializes the buffer during instancing - I know you don't want to do that in general, but I would expect the error to vanish then
<Regenaxer>
Anyway, well-tested
<Regenaxer>
I think it is not related to that buffer
<beneroth>
maybe log sizes of writes/reads to that buffer
<beneroth>
no?
<Regenaxer>
not at all
<Regenaxer>
it is a symptom
<Regenaxer>
not the cause
<beneroth>
ah you mean it is just a side effect that it shows in that region of memory
<Regenaxer>
yes
<beneroth>
a stack overflow somewhere
<Regenaxer>
No overflow
<beneroth>
but then the error should show differently in different test runs
<Regenaxer>
I'm not sure what that error means anyway
<Regenaxer>
what "uninitialized"?
<Regenaxer>
makes no sense
<beneroth>
memory that was never written
<beneroth>
makes sense in C/C++
<beneroth>
you should not read it
<Regenaxer>
By checking patterns?
<beneroth>
(unless you want pseudo random values)
<beneroth>
by tracking all memory writes/reads
<beneroth>
int i; (print "%i", i);
<beneroth>
i is used uninitialized.
<beneroth>
its value is quasi random (leftover from whatever happened to be at that place in RAM before)
<Regenaxer>
yes, on the stack
<Regenaxer>
but on malloc'ed mem?
<beneroth>
same
<Regenaxer>
in that buffer?
<beneroth>
malloc does not set the values
<Regenaxer>
how can it detect? Write a pattern?
<Regenaxer>
0xDEADFACE
<beneroth>
I used memcpy or so (must lookup the exact name) to initialize such buffers
<beneroth>
or keep a list of a memory ranges which were never written to, when a read falls in that range -> error
<Regenaxer>
checks CPU memory accesses?
<Regenaxer>
every load and store?
<Regenaxer>
Anyway
<Regenaxer>
putStdout is surely not wrong
<Regenaxer>
As I said
<Regenaxer>
the problem must be a seldom-used thing
<Regenaxer>
else we would have seen at all those tests
<Regenaxer>
and we self-build pil21 since months
<Regenaxer>
such putStdout stuff would never work
<Regenaxer>
[0x72100000000c, 8) looks like stack
<Regenaxer>
typical stack area
<Regenaxer>
8-aligned
<Regenaxer>
hmm
<Regenaxer>
'c' is not 8-aligned
<tankf33der>
must be afk.
<tankf33der>
cu.
<tankf33der>
some complex codebase is still running under gc+.
<Regenaxer>
ok
<Regenaxer>
Maybe it is indeed not gc
<Regenaxer>
but some wrong pointer somewhere else
<Regenaxer>
Would also vanish with changed initial setup
rob_w has quit [Remote host closed the connection]
<Regenaxer>
'fully' returns a different result in one of 18561 calls
<Regenaxer>
digging into it
<tankf33der>
how you got all results?
<Regenaxer>
I put 'msg' in the code and compare pil64 and pil21