On Thu, Oct 19, 2023 at 06:29:07PM +0200, Olav Smorholm wrote: > On Thu, Oct 19, 2023 at 03:05:01PM +0200, Olav Smorholm wrote: > > On Wed, Oct 18, 2023 at 11:21:06PM +0200, Olav Smorholm wrote: > > > Tried to reproduce, but with no substitutes and no grafts. > > > Wed Oct 18 18:48:34 2023] mes[19410]: segfault at 0 ip 0000000001016085 > > > sp 00000000ffff5044 error 6 in mes[1000000+18000] likely on CPU 4 (core > > > 8, socket 0) > > > [Wed Oct 18 18:48:34 2023] Code: 60 01 01 e8 71 ef ff ff 83 c4 04 85 c0 > > > b8 00 00 00 00 89 45 fc b8 00 00 00 00 bb 00 00 00 00 50 89 d8 8b 5d fc > > > 01 d8 89 c3 58 <88> 03 85 c0 c9 c3 3a 00 61 73 73 65 72 74 20 66 61 69 6c > > > 3a 20 00 > > > > > > Which should be the first, and perhaps only one before conf and tests. > > > Reported as guix binary requested with caveats that while GNU, i tend to > > > opt > > > for UNIX crashy. and could be hard to chase with coincidence mixed in; > > > hard to chase. > > > > took much longer with --no-grafts and --no-substitutes, but this also > > showed up again, but not the seed. > > > > [Thu Oct 19 12:18:54 2023] xsltproc[5943]: segfault at 7fffff7fefe0 ip > > 00007ffff7b952ce sp 00007fffff7fefb0 error 6 in > > libc.so.6[7ffff7b2a000+167000] > > > > still fairly sure its from guix building. > > > > [Tue Oct 17 21:33:19 2023] process > > 'bootstrap-seeds/POSIX/x86/kaem-optional-seed' started with executable stack > > Reboot, and by not checking, into rebuild kernel without the pattern > init unsafe hardening options. For an hour and half, the only thing I > see is this: > Thu Oct 19 16:57:16 2023] process > 'store/5srp88m0d10qxnb49c3sa2a186kjy6xz-tcc-boot-0.9.27/bin/tcc' started with > executable stack > > Instead of the seed, and no mes segfaults, and will do this again. > It's a bit of a stretch to say I had a rodent i here segfaulted my way > out of, but I dont live in any of the relevant information structures > between compiler assembly, running code and debuggers. Nor familiarity > enough to say why tcc is said to be started with executable stack > instead of the seed as above. I am just fairly certain that something > isn't house clean in what is inherently complicated and bootstrap that > touches many fundamental things. >
Another reboot with more hardening things: process 'store/9cfq2h8sa5f6cgrhdgadlxwkf00vmgf5-gcc-mesboot1-4.6.4/bin/gcc' started with executable stack and absolutely no segfaults. either bugs got more clever, or this isn't house clean.