IRC channel logs

2021-06-13.log

back to list of logs

<oriansj>which is why cc_x86 is virtually impossible to find with a standard web search but M2-Planet is rather easy to find.
<stikonas>oriansj: mes problems that I saw are cause by you having slightly different version of nyacc
<stikonas>even when I tried to add my own, I think embedded nyacc was used
<stikonas>(due to wrong order in GUILE_LOAD_MODULES)
<stikonas>I can try to check a bit more tomorrow...
<stikonas>but with files replaced, qsort.c builds
<stikonas>so no need to replace C++ style comment
<oriansj>stikonas: thank you finding that failure in my selection. We should update mes-m2 to reflect that error and thus enable the next stage0-posix update to solve that problem.
<Melg8[m]> @gia i've rechecked usage of your custom memory allocator with guards (my mistake was that i didn't call make after changing source (here are changes to malloc so it doesnt complian about size of allocations https://paste.debian.net/1201031/) now, i did and here is results. It ran for almost 3 days, and crashed on free. here is full log: https://paste.debian.net/1201030/ Questions are - any ideas, why/where it happened? second - any ideas on
<Melg8[m]>how to make this reproducible in less than 3 days, even if i will fix it) any suggestions on further investigation directions?)
***terpri is now known as robin
<Hagfish>that reminds me that i think some fuzzers are capable of taking a crash log and generating a minimal test case, but i suppose that isn't quite relevant here
<gio>Melg8[m]: I don't know what's the problem off my head, I'd have to debug it.
<gio>That happened using USE_CHECKED_MALLOC?
<gio>Ah wait, with those changes there is little doubt you're running into problems. Those assertions were there for a reason.
<gio>Especially the "too many allocations" one.
<Melg8[m]>@gio okay, why?)
<Melg8[m]>why too many, is too many)?
<Melg8[m]>and how i could correctly expand this to handle more allocations
<gio>Melg8[m]: That allocator initializes at the beginning (in _malloc_init) a static table in which every allocation is recorded forever (i.e., it is not removed once that area is freed). So once its rows are all full, nothing can be allocated anymore.
<gio>This is regulated by the constant MALLOC_MAX_NUM.
<gio>In line of theory you can raise that limit, but eventually you risk to exhaust the memory available to your machine. And the allocator is not able to check that, I think, random wrong things will just start to happen.
<gio>Given that it is also extremely slow, I don't think it is a very useful tool at this point. It is only useful in the early stages of G bootstrapping.
<Melg8[m]>@gio i increased +const MALLOC_MAX_NUM 10000000 - so that would be functioning in right way?
<gio>I don't know what is the right number. I'm not even sure there is a right number.
<gio>You might run out of memory before the number is large enough to work until the end.
<stikonas>oriansj: hmm, even with correct nyacc there are some problems. So qsort.c works fine now. even tcc.c compiles fine but then linking fails (when running mes-m2 --no-auto-compile -e main /after/bin/mescc.scm -- -o mes-tcc -L /after/lib tcc.s -l c+tcc)
<stikonas>so there must be some other difference...
<oriansj>stikonas: well that is frustrating.
<stikonas>oriansj: I do have a working version of mes (the one currently used in live-bootstrap, so it's not super frustrating
<stikonas>would be worse if nothing worked
<Hagfish> https://utcc.utoronto.ca/~cks/space/blog/programming/Rust1BackwardIncompatibility
<Hagfish>"I'm sure that Rust people have a whole series of good explanations for why all of this was necessary and why it's a good thing that I can no longer build older versions of Firefox"
<Hagfish>actually, according to the HN discussion, the problem might be the hacky way Firefox is developed, not Rust itself
<Hagfish> https://news.ycombinator.com/item?id=27491512
<stikonas>well, rust is incompatible. You have to compile every intermediate version of rust in order to boostrap it
<stikonas>you can't skip anything
<stikonas>so if Firefox is developed in a hacky way, so is Rust
<Hagfish>apparently there is a special mode of the Rust compiler for skipping some checks, so that Rust can bootstrap itself, but Firefox abuses that
<Hagfish>i guess you could say that makes them both hacky, yes
<stikonas>yes, but it can still only bootstrap version n from version n-1
<stikonas>version n can't be built with n-2
<NieDzejkob>My pet theory is that most of it is the fact that they remove the feature() annotations immediately after they stabilize a feature
<oriansj>NieDzejkob: my pet theory is that software compatibility is a choice that developers sometimes say no to. Sometimes for justified reasons and sometimes because they honestly didn't give a crap about the people who depended on their software.
<oriansj>which perhaps is the greatest strength of NixOS and Guix; they can handle those cases smoothly.
***dongcarl6 is now known as dongcarl