Hi, Thank you for your previous mail.
Samuel Thibault wrote: > Hello again, > > Da Zheng, le Tue 15 Dec 2009 13:51:09 +0800, a écrit : >> (gdb) run >> Starting program: /root/hurd/ddekit_test/test >> test1 thread starts at 1260701688 >> test1 thread wakes up at 1260701691 >> test1 thread enter a semaphore at 1260701691, timeout: 1 >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x0105f88c in evc_wait () from /lib/libc.so.0.3 >> (gdb) info stack >> #0 0x0105f88c in evc_wait () from /lib/libc.so.0.3 >> #1 0x01060089 in mach_msg () from /lib/libc.so.0.3 >> #2 0x0110bb1e in sleep () from /lib/libc.so.0.3 >> #3 0x08049ad7 in thread_test () at main.c:302 >> #4 0x08049b61 in main (argc=1, argv=0x125fda4) at main.c:318 > > Please make sure that it's really this kernel thread that generates the > SIGSEGV. I have fixed this problem now. It was caused by a bug in my ddekit implementation. It freed some memory it shouldn't free. > >> It's quite weird, as it shows that mach_msg calls evc_wait. > > That could be a glitch of some other mechanism. You can use disassemble > 0x01060089 to check what's really there and l * 0x01060089 to check > which precise file that comes from. disassemble is really useful:-) I really need to learn more about gdb. I do see that evc_wait is called by mach_msg, but I cannot see evc_wait is called either by any functions in glibc or by any in the build tree. but 'l * 0x01060089' shows me no source file for the address. I think it's because mach_msg is in the c library which doesn't have any debugging information. > >> I can find two mach_msg implementations which are in mach/msg.c and >> hurd/intr-rpc.h respectively. > > See the comment of intr-rpc.h: that implementation of mach_msg is only > used for mig-generated functions. So the one we use by ourselves is in mach/msg.c, but it seems it simply calls the system call directly. no evc_wait is called. Zheng Da
