Re: A segmentation fault when running sleep()

[Da Zheng]

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