IRC channel logs
2026-07-10.log
back to list of logs
<rrq>I'm using "Debian GNU/Hurd forky/sid amd64" with some spurious stack curroption but would like to confirm which mig and gnumach versions to use. <rrq>currently I have mig commit cb48044 and gnumach commit e56301bd <rrq>apparently it gains a trap in "sleep" due to ret wit 0x0 on stack, which happens by "call mach_msg" in "sleep" <damo22>mig version only applies to what was used to build userspace? <rrq>hmm now it trapped on syscall rax=-25.. entered a "kernel debugger" ? <rrq>might that be due to me instruction stepping ? <rrq>I'm debugging user code, which traps on sleep(30)... seems to be in mach_msg of sleep <rrq>and seems to be just after syscall -25 <rrq>(the syscall is followed by ret, and the stack then has 0x0 on top) <rrq>I suppose it concerns the libc0.3:hurd-amd64 version 2.42-16 <rrq>mmm seems to concern percpu_get <rrq>maybe not. I see mach_msg having an uncnditional syscall -25, but I can't reconsile that with the mig source <sneek>solid_black, you have 1 message! <sneek>solid_black, gfleury says: I remember you made a translator that emulates an epoll, if I'm not mistaken, back when you were working on Wayland. Any chance you could put it online if possible? <solid_black>please let me know if you manage to build / make use of this, whether the code makes sense, etc <rrq>ok. I have the repeatable "trap" in sleep in my larger test program... I now made a sleeptest program and that seems to not "trap", so presumable my larger program has a badness <solid_black>fwiw, I have previously seen gnumach abort when trying to single-step over 'syscall' in GDB <rrq>the actual sleep delay seems to be with the mach_msg; is it so? <solid_black>yes, so as you can see from my link above, the way sleep is implemented, it just does a mach_msg_rcv with a timeout on a port that we know no-one will send messages to <solid_black>so the wait times out, then it destroys the port and returns <solid_black>(cool thing is, this is only dependent on Mach, not Hurd -- as various things in glibc in fact are) <rrq>the larger program also uses pthreads; might that cause trouble? <solid_black>does the userland program fault on 'ret' with 0x0 on the stack as the return address? is that it? <solid_black>(well, in that case it should fault on executing 0x0, not on 'ret' per se) <rrq>well, without tracing, the sleep call consistently gains a trap <solid_black>and wdym be trap exactly? a Mach trap? a fault/exception? SIGTRAP? <rrq>the trap output in gdb points at the "ret" following the syscall <solid_black>you should be able to see the instruction it gets that on, is that the ret? <solid_black>ah also, by any chance, could it just be the age-old "GDB breakpoints are broken in new threads" thing? <rrq>yes, and *$(rsp-8) = 0x0 <rrq>I get that info when running without breakpoints <solid_black>'retq' loads the value from *rsp, then increments rsp <solid_black>but yeah, try to list threads and see if any of them actually ran into a breakpoint <rrq>mm it's a "ret" instruction, but *($rsp-4) is also 0x0 of course <rrq>I thought it fetches the addres and increments rsp, then gains an MM trap <solid_black>sneek: later tall gfleury: EPOLL_CTL_MOD is unimplemented as you can see <rrq>I can rerun and look at more of the stack. Though it shouldn't trap? <solid_black>I'm trying to say there are two things at play: 1. you're misreading what 'ret' does (it reads & pops *rsp, not *(rsp-8)) <solid_black>2. the whole Hurd signal system has a bug that makes it appear, in GDB, that a thread has received SIGTRAP out of nowhere when in fact a different thread has hit a genuine breakpoint <rrq>hmm I'm used to $rsp be incremented (the pop) before the trap happens, in which case the "ret" instruct used that prior stacj value..but maybe that gdb problem is what plays in <solid_black>in any case, whatever goes wrong there with 'ret', it would generate SIGSEGV or SIGBUS or SIGILL, not a SIGTRAP <rrq>yes. *rsp does have the proper value to return into mach_msg... <rrq>hmm so I can't use gdb <solid_black>a hack I use is to compile a single-threaded version for debugging <rrq>pity ^C doesn't work in db :( <solid_black>really, someone (me) should fix the aforementioned issues with signals/gdb <rrq>:) ... selecting a different thread and do "si" is not the way to go either :) <rrq>without gdb, my program says it's failing at reading a UDP socket, which is one of the other threads <solid_black>so is that your own network stack implementation, like pfinet and lwip? <rrq>no this originates as a linux program <rrq>it's fine opeing a UDP socket, but fails at the read call ... <rrq>line 1778 creates the fd (for ipv4) <rrq>1791 binds it "successfully" <rrq>1836 creates the reader thread <rrq>right. there shouldn't be any UDP message (yet) <rrq>maybe it doesn't like IP_PKTINFO <rrq>I think I read somehwere that IP_PKTINFO wasn't supported... but I meslead myself with the gdb thread thingy <rrq>shouldn't trap though... just fill up the packet buffer and then start discarding <rrq>I've also made a small patch re the use of "tap, to rather use an eth-multiplexer <rrq>and actually that might be what breaks <rrq>yes :( sorry to bother you... it works "fine" using stdio, but my tap attempt doesn't work (and I got stuck in the gdb problem) <rrq>so in short, I need a tap translator <rrq>well it's for network packets <rrq>level 2 tunneling (over UDP) <solid_black>yes, but (I think others agreed with me that) on the Hurd, you don't need a special tap/tun mechanism, something as simple as fifo would do the job <solid_black>because network inteerfaces are just files/stream like everything else <rrq>I thought so and therefore used the eth-multiplxer, on the ide I could read/write packets to it <solid_black>what does that have to do with the eth multiplexer though? <solid_black>on traditional unix, tun/tap is a separate network interface <solid_black>I'm suggesting the same here, make a FIFO somewhere (/tmp/my-tuntap), let your tunnel sit at one end of it, and add the other end to fpinet <solid_black>well, you might need a bit more than a plain FIFO (you likely want to guarantee bidirectionality, and packet boundaries), but you get the idea <rrq>isn't pfinet only level 3 (IP) ? <rrq>it can be used as tun interface but not tap <rrq>tap device code is imported to the netdde source but not used in compiling netdde <solid_black>it exposes TCP/UDP (PF_INET) to its clients, and emits ethernet frames to the underlying network interfaces <rrq>yes, what I'd like to have is the level 2 device tor read/writh with <solid_black>and I'm saying you make something like a FIFO and add that as a network interface to pfinet, then pfinet will write its layer-2 eth frames there, and you will read them <solid_black>and the other way around, you would emit your layer 2 eth frames, and pfinet will decode them and maybe recognize them as TCP packets or something <solid_black>I'm not really a networking person, maybe it does not <rrq>no that won't be sufficient; it won't become a level 2 (ethernet) tunnel <rrq>server might run ./rrqnet -vvv -4 -t /dev/tap0 4563 0.0.0.0/0 <rrq>to accept tunneled packets on UDP port 4563 to enter the server on that tap0 device <solid_black>yes, but what would that /dev/tap0 be and do? and how would that differ from my scheme above? <rrq>well it is a tap device, and notionally similar to an eth device <solid_black>yes, so, like my scheme above? I'm not getting the difference :| <solid_black>ok, so eth-multiplexer is using/exposing Mach device APIs, not Hurd I/O ones, so actual FIFO won't work <rrq>level 2 packets are between ethernet devices, identified by mac addresses, whereas TCP/UDP are between IP "devices" identified by IP addresses <rrq>afaict the linux tap code is included for netdde but not used <rrq>taps are created dynamically, and don't belong to the gardware like eth devices do <solid_black>what I'm saying is, for the Hurd, we shouldn't even need the Linux tap code, we should be able to just have a simple FIFO-like device node <solid_black>or not even a separate node, your tunnel could implement device_read/device_write directly <solid_black>tun/tap exists on Unix because the fs/devices and network interfaces are distinct concepts <solid_black>but on the Hurd, they are one and the same, so there's no need for such a concept <rrq>well /dev/eth0 is no available for read/write <rrq>aiui pfinet provides translation between read/rite level 3 packets and networking device <rrq>I would be looking for the similar between level 2 packets and networking <solid_black>I assu,e /dev/eth0 uses Mach device API (device_read/device_write) and not Hurd I/O API (io_read/io_write) <solid_black>perhaps you could try to wrap it into a streamio instance, and then read/write into it using Hurd APIs <rrq>ah... yes, doesn't crash the server side... <rrq>no errors, but the UDP servicing doesn't seem to work ... not sure I dare to gdb it :) <rrq>hmm streamio.open() just hangs ? <rrq>hmm so streamio doesn't provide an fd by "open" ? waits for underlying device to service device_open maybe ?