All alpine autobuilders fail in tests using 2.0.11 #1197
Comments
|
It looks like 2.0.12-pre is also now failing on drone :(. Though this is since 2.0.11. 4935 worked; since 4936, we're dead in the water. |
|
I've been trying to reproduce this locally, and failing. Need to get a core file exfiltrated from the docker. |
|
Finally got it reproduced! |
|
|
OK, I can reproduce this locally now just by running in |
|
I see what's happening, though I have no idea why: in |
|
|
|
Hrmmm, I don't like that segfault, but we have this resolved and tests are now passing. I'd like to try further to reproduce and chase down that segfault, though. |
|
the segfault was a failure to check a result in the reels tests. resolved. we're done here! |
|
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15708 we look good! all alpine builds are now passing =]. |
This release was all about fixing the unit tests, which have been mysteriously breaking on the Arch autobuilder recently: dankamongmen/notcurses#1197
|
2.0.12 tests are crashing on x86 :( |
so i saw. =[ do you have any insight as to why they would all be green in the pipeline attached to the PR, but then one would break somewhere further down the line? the build logs for that pipeline clearly show the tests being run on x86, and succeeding. =[ |
btw is your "keeper of mazes" a reference to the Ariadne of mythology, she of the gold thread? |
|
the CI environment is a bit different than the actual buildservers. on the buildservers, we capture stdout and stderr file descriptors and redirect them to files. i do not believe we do this on CI. |
|
i had to block notcurses on x86 so that our x86 buildserver would move onto trying to build other packages, but would be happy to help debug this.
yes, I work on a lot of security-related code inside and outside alpine, as well. seemed like a good fit. |
|
I have set up an x86 alpine install and built notcurses in it manually with abuild: I then ran I then ran the testsuite with stdout and stderr captured like the buildservers do: In my test environment, its just frozen, which is a behavior different than the buildserver even though the FDs are captured the exact same way. |
|
Running this a few more times, I cannot get it to crash and I cannot get it to segfault on a bare x86 VM. |
|
Running the tester program directly also does not crash. I'm honestly baffled as to why the buildserver is failing reliably, but the failure is not reproducible in a test environment. |
|
Hmm, when your code sees that stdout is not a TTY, it tries to open |
|
Bam! If I replace /dev/tty with something bogus (say, a FIFO), we get an immediate segfault in notcurses-tester. |
|
Opened #1212 with a likely fix. |
…ves FTBFS on x86 See dankamongmen/notcurses#1197 for more information.
awesome. i'm at work at the moment, but will be able to look at this again this evening. so distressing -- i figured out why we were breaking on s390x, only to start breaking on x86! i definitely intend to get this fixed, just didn't yet have the heart to do so the other day =]. |
|
Marking this tentatively closed, in the hope that @kaniini 's patch fixes us up. I might go ahead and package Alpine 2.1.0 (they're on 2.0.12 currently) with @kaniini 's patch in the APKBUILD, and that way bring them up to speed while also getting a test prior to 2.1.1. I'd really love to stop breaking their autobuilder. |
|
Unfortunately on the latest try, it doesn't fix us up. With the help of @Ikke, I was able to get the CTest log from the builder: Going to dig a little bit into this test. |
|
Hot damn, y'all are CHAMPIONS. I'm on it as well. The piles stuff is all new from 2.0.x, and I haven't yet written anything that really exercises it, so I'm not surprised to see potential problems there. |
|
tally-ho! |
|
for all those playing at home, it's likely that whatever's affecting us in |
|
|
Ah, linked list corruption. That's what my guess was going to be based on looking at the code. |
absolutely, i am the suck. i'll have it fixed in 10min, but you're welcome to race if you'd like =]. SHOULDA USED RUST. |
|
and by the way i can't thank you and @Ikke enough, nor the rest of Alpine. i've no idea why yours is the only config that caught this, but you've done me a tremendous service. |
|
ok yeah, in |
|
musl's malloc-ng malloc implementation catches a lot of bugs like these. if you're interested, i could set up alpine-based CI using github actions. |
i've got a ci server at https://drone.dsscaw.com:4443/ (or i did, anyway; it apparently has stopped), that i've been meaning to throw alpine onto. the musl observation is a compelling one. certainly don't let me stop you from setting up whatever you'd like, of course, but yeah throwing an alpine build into |
|
with that said, if you're offering to do this because you're interested in getting involved with notcurses, i'd be delighted to have you aboard, and am happy to let you take over whatever you'd like. |
|
i've got a fix for this. valgrind now runs clear. |
|
I do have some interest in notcurses; for example I am interested in using it as a basis for a replacement Alpine installer, modelled after FreeBSD's bsdinstall. |
well i've no idea as to what kind of time you want to put into it, but so long as you don't go committing into my C core without letting me know =], i'm happy to make you a collaborator. alternatively, you can just send PRs and know you're on the fast track for approval, heh =]. i'm honored to have people of your competence interested in my humble little project, and @joseluis can hopefully vouch for my willingness to explain my mysterious/inscrutable codes and comments via mail. |
|
also, i'm delighted to hear of potential use in an alpine installer. feel free to hit me at nickblack@linux.com with any questions you run into, and be liberal with the feature request button. 2.1.1 adds progress bars (already visible in the |
Looks like we've got it this time. |
boom! definitely a team effort. thank you for restoring a bit of my faith in humanity and free software. |
dankamongmen commentedDec 10, 2020
I cut 2.0.11 for Alpine Edge today, confident that we'd fixed the s390x problem there. The good news is that s390x no longer errors out differently from the others. The bad news is that all now fail :(. Gotta fix this before 2.1.0.
The text was updated successfully, but these errors were encountered: