A segmentation fault when running sleep()

[Da Zheng]

Hi,

I'm testing my implementation of ddekit and run into a problem as follow:
I create a new ddekit thread (ddekit thread is implemented based on cthreads) 
and set its name. Whenever a ddekit thread exits, it cleans up its own 
environment and frees its name by itself (I allocate space for each thread 
name). After a ddekit thread exits, the main thread gets a segmentation fault 
if it calls sleep(). After a little more test, I find the problem: sleep() 
somehow references the new thread's name. If the new thread's name isn't freed, 
the testing program runs well.

I run the testing program in gdb and can see the place where the segmentation 
fault occurs.
(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

It's quite weird, as it shows that mach_msg calls evc_wait. I searched glibc 
for evc_wait and didn't see any place where evc_wait is called. I searched for 
mach_msg, but am not sure which mach_msg implementation is used by my program. 
I can find two mach_msg implementations which are in mach/msg.c and 
hurd/intr-rpc.h respectively.

Can anyone tell me where is the real implementation of mach_msg in glibc? Why 
mach_msg() or evc_wait() needs to reference a new cthread's name?

Thank you,
Zheng Da