IRC channel logs
2025-03-17.log
back to list of logs
<ekaitz>uuuh mes-m2's assert_msg fail with segfaults <ekaitz>so yeah janneke i think we have segfaults in the assert function <ekaitz>in mes-gcc works, but in mes-m2 segfaults <ekaitz>the good part is it segfaults when the assert fails <ekaitz>so the effect is similar to the assert failing <ekaitz>janneke: your master branch includes the "don't run main twice" issue? <ekaitz>oh forget it, yes it does include it <ekaitz>janneke: it also segfaults in master <ekaitz>also there's a really interesting way to reproduce <janneke>is this with a newer m2-planet or so? <janneke>i'm pretty user master was tested in the bootstrap <ekaitz>this is with mes' master branch as it is <ekaitz>the thing is, the failure only happens when assert_msg(0, "whatever"); happens <ekaitz>the thing is, this assert_msg segfaults, instead of actually asserting and printing the message <ekaitz>but as the assert shouldn't happen in normal execution, we don't see that <janneke>eh, i believe assert is /implemented/ as segfault <ekaitz>hah thanks that you mentioned it because I was starting to go into the rabbit hole <ekaitz>in any case, when we build crt1.c there's a character in the strings that is escaped but is not considered in the escape character parsing, that's also very interesting <ekaitz>i realized that because I put an assert in the default case and it crashed <ekaitz>oh it's a \ for newline cancelation <ekaitz>and we are not doing that properly I think <ekaitz>i found it because i converted many ifs to a switch <ekaitz>so i just copied what guile does <ekaitz>it's not much, but it's something <ekaitz>and i'm getting used to mes codebase and your weird curly bracket indentation :) <janneke>it's the emacs default too, of course <ekaitz>i know... i don't like the curly bracket position though :) <ekaitz>and probably like it in the future <stikonas>ekaitz: any speeds up you noticed from if/else -> switch conversion or negligible? <ekaitz>stikonas: that's a very good question, but I'm going to answer it with a second question: do you have any suggestion for a benchmark I should try? <ekaitz>stikonas: but that takes a lot of time to build... yeah <stikonas>at some point I think I tried running calgrind on mes <fossy>btw stikonas, i have reproduced the "rm: remove write-protected regular file" thing on bubblewrap... <fossy>yes, it appears to be random <fossy>i'd much prefer to fix the underlying problem <fossy>something appears to be causing many files to be extracted ro in bubblewrap mode <stikonas_>it's not like the whole unpacked archive has wrong umask... <fossy>i'm uncertain about that, but it's strange that i'm getting different ones to you <fossy>perl-5.6.2, coreutils-5.0 thus far <fossy>we have proper tar by that time <stikonas_>at some point we need to also update to the new release of stage0-posix <stikonas_>but until janneke releases new mes, we would have to manually copy x86 defines from m2libc to mes source... <fossy>maybe would fix it, who knows <ekaitz>stikonas: so i want to make some benchmarking but only leave the full mescc check for the more detailed check <ekaitz>that's not very real though because it's not going to trigger the gc in the same way <ekaitz>i could use the scheme benchmarks <stikonas>most of the time is probably spent in eval.c file <stikonas>if I recall correctly in eval_apply() function <ekaitz>but that's not very meaningful right now <ekaitz>stikonas: my goal is to rewrite the evaluator <stikonas>yeah, I was just thinking maybe switch port already helped there a bit, since that file is very heavy on if/else if <stikonas>but yes, bytecode interpreter should help more