IRC channel logs

<damo22>youpi: how do i find out what caused a mach_msg_trap, i assume it was some kind of signal but the backtrace doesnt show what happened

<damo22>all the threads that are waiting for either a timeout or for a condition are interrupted with a __mach_msg_trap but nothing is happening

<youpi>? they are not interrupted, they are calling it

<youpi>whatever RPC you call, you end up calling mach_msg(), which calls mach_msg_trap to actually perform the trap that switches to kernelland

<damo22>i see

<damo22>so gnumach is blocking on all of them?

<youpi>yes

<youpi>i.e. all RPCs are waiting for something

<damo22>there is a gsync call as well

<youpi>so a mutex

<youpi>or such

<damo22>#0 0x00000000010a9d9b in __GI__hurd_intr_rpc_mach_msg (msg=msg@entry=0x3bf7a20, option=option@entry=3, send_size=send_size@entry=112, rcv_size=rcv_size@entry=48, rcv_name=39, timeout=timeout@entry=0, notify=<optimized out>) at ./hurd/intr-msg.c:110

<damo22>#1 0x0000000001370d02 in __gsync_wait_intr (task=<optimized out>, addr=addr@entry=41490048, val1=val1@entry=0, val2=val2@entry=0, msec=msec@entry=0, flags=flags@entry=0) at ./build-tree/hurd-amd64-libc/mach/RPC_gsync_wait.c:187

<damo22>they all could be stuck waiting for that sem_timedwait ?

<youpi>if something forgot to give back a token in the semaphore, yes

<damo22>actually its a sem_wait with no timeout

<damo22>in check_pending_signals

<damo22>when i continue in gdb from that initial state, i get unknown signal ?

<damo22>'?'

<damo22>so maybe there is a signal being thrown with the wrong number?

<damo22>youpi: i ran the javac process again from start in gdb and i got a SIGTRAP

<damo22>in __GI___mach_msg_trap

<damo22>instead of attaching to the pid, i ran it completely in gdb

<damo22>then when i continue the process, i get a seg fault

<damo22>is that a bug in gnumach?

<damo22>i cant find the implementation of __mach_msg_overwrite_trap

<damo22>i think #0 0x0000000000007b21 in ?? () from /lib/ld-x86-64.so.1 threw a page fault?

<damo22>0000000000003b20 <_dl_debug_state>:

<damo22> 3b20: c3 ret

<damo22> 3b21: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) <----- why are we here?

<damo22> 3b28: 00 00 00

<damo22>...

<damo22>0000000000003b40 <openaux>:

<sam_>_dl_debug_state is a hook that gdb uses

<sam_>it looks specifically for that name

<damo22>i get a different back trace when i break on different functions, but the SIGTRAP occurs on other thread

<damo22>db> w debug_all_traps_with_kdb 1

<damo22>0xffffffff810c0900 0 = 0x1

<damo22>db> c

<damo22>root@zamhurd64:~# Stopped at 0x7b20: TODO

<damo22>>>>>> user space <<<<<

<damo22>0x7b20(...)

<damo22>0x22a0b(...)

<damo22>0x2766b(...)

<damo22>0x22895(...)

<damo22>0x23d41(...)

<damo22>0x22f08()

<Donjuanplatinum>Hello :D , How do you usually configure the C indentation in Emacs ? My emacs C indentation not match the hurd coding style.

<Arsen>the gnu style (which is default) should match it, no?

IRC channel logs

2026-08-29.log