Hello! On Sun, May 28, 2023 at 12:13 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > > task /bin/bash(1) decreasing a bogus port 82650 by 1, most probably a bug. > > bash: ../sysdeps/mach/hurd/mig-reply.c:84: __mig_dealloc_reply_port: > > Unexpected error: (os/kern) invalid name. > > > > the console warning is expected, we get the same with hurd-i386. But the > > bash port deallocation is bogus indeed. > I commented the assert for now, and got a shell :D
You mean interactive bash works? \o/ And -- I assume you're using the full Hurd console?, not streamio on Mach console like me? The port error is interesting; 82650 is clearly not a port name, so it's not a port use-after-free / double free, it's some bad/invalid memory. Hmm. Is something overwriting our TCB? Do you think this is happening after running a signal / RPC interruption? Or after a timeout? Is there any easy way to reproduce this? (now that you must have disabled the assertion in your initrd-amd64.img) On Sun, May 28, 2023 at 12:31 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > BTW it's as simple as > > symbol-file > ./usr/lib/debug/.build-id/3e/a2af77859e5cfd5c1b726d81f135bfbfb3d1f0.debug > > (the build id is visible in the `file binary` output) Yes, I understand that much. But I probably want to do add-symbol-file rather than just symbol-file, to use multiple symbol files at the same time (say, one for gnumach, one for /bin/bash, one for libc.so, one for libpthread.so, one for ld.so, ...). And it wants the address of .text, which I normally do provide -- when the .text and the debuginfo are in the same binary. But with debuginfo being in a separate binary... I'm not sure how this all is supposed to work. Is there still a .text in the debuginfo ELF? (I think there is, but it's NOBITS?) What address do I plug in? It all "just works" nicely on a full distro, GDB even loads (or down-loads, with debuginfod) the matching debuginfo files automatically without me having to do anything. But now that I have to do it manually, I'm unsure how it's supposed to work, and there are no docs or explanations. On Sun, May 28, 2023 at 04:34 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > And rumpdisk as well :) > > [ 2.9500050] wd3 at atabus5 drive 0 > [ 2.9500050] wd3: <QEMU HARDDISK> > [ 2.9500050] wd3: drive supports 16-sector PIO transfers, LBA48 addressing > [ 2.9500050] wd3: 50001 MB, 101589 cyl, 16 head, 63 sec, 512 bytes/sect x > 102402048 sectors > [ 2.9600050] wd3: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 > (Ultra/100), NCQ (32 tags) > [ 2.9600050] wd3(ahcisata0:3:0): using PIO mode 4, DMA mode 2, Ultra-DMA > mode 5 (Ultra/100) (using DMA), NCQ (31 tags) > > and it seems to be working :D Yay, this is so cool! You could make an attempt to boot off the rumpdisk then? On Sun, May 28, 2023 at 05:20 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > > lwip seems to be crashing for now. > > After disabling stack-protector again, > > # ping -c 1 8.8.8.8 > PING 8.8.8.8 (8.8.8.8): 56 data bytes > 64 bytes from 8.8.8.8: icmp_seq=0 ttl=115 time=20.000 ms 🎉 So technically, if nano works, we could start working on that blog post :D What was the failing stack protector on, this time? It makes sense that thread_set_state needs to be built without a stack protector, compared to i386, because we now use it in early startup, whereas we didn't on i386 -- but what could be a x86_64-specific issue with lwip? On Sun, May 28, 2023 at 5:20 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > If people want to play with it, I have updated the image on > > https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz > > of course, since the second stage of debootstrap doesn't work yet, > nothing is configured, so you have to configure everything by hand to > get almost anything to work. It has various .deb packages available in > /var/cache/apt/archives that can be unpacked with dpkg -i Cool, thanks, I'll check it out -- and awesome work all around :) More questions: has there been any news on getting official hurd-amd64 Debian packages? I see there has been a response to the thread [0]. [0]: https://lists.debian.org/debian-hurd/2023/05/msg00031.html And on that note, any news about the Rust GSoC project? Wasn't there supposed to be a community bonding period? Also, what do we do about [1][2]? [1]: https://mail.gnu.org/archive/html/bug-hurd/2023-05/msg00287.html [2]: https://mail.gnu.org/archive/html/bug-hurd/2023-05/msg00288.html Sergey