bug#66610: Acknowledgement (potrace, po4a; guix bug, complete console output)

[Olav Smorholm <olavks@gmail.com>]

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.