Conference clt::cma

1500.0. "how to see sigmasks in NxM implementation" by COL01::LINNARTZ () Thu Mar 06 1997 15:58

    Hi,
    
    I've just found notes entry 8821 in Digital_unix and will ask for
    the patch. The problem was that I received an EINTR in sigwait/
    sigwaitinfo, even the signal was blocked. so I replaced sigwait
    with sigwaitinfo (changed the returncode section ;-( ) to obtain
    more info on what's happening. I was even more buffled seing the
    by the output. . errno was set to EINTR, but the siginfo structure
    only contained the signo set (to ALRM), (haven't implemented it as
    thread yet, other problems), but si_errno and si_code and the 
    other unions all were zero. some high slot's in the pad array
    had some data, which I couldn't relate to some debugging aid.
    Even I setup the needed actions in the mainthread, so that
    latter creation will inherit it, I wanted to doublecheck that
    everything is setup ok. 
    But how do you check a threads signal mask in a NxM implementation?
    I hope that kernel wise I looked at the right place by looking
    at the uu_share structure in the np_uthread. I guess the thread
    lib manipulates the mask, as it looked different than my mask
    in the program. 
    
    Is the only way to call pthread_sigmask out of the debugger,
    after having switched to it.
    the pthread_debug() isn't a totally satisfying answer, as the
    thread -f output changes the output after a period of time
    (I guess this is due to internal scheduling rules, as I 
    verified it with a pthread_sigmask call, and it still was set ok,
    even pthread_debug() reported no signals set.
    
    thanks for any hint on how to debug this
    
    Pit

    I'm getting you the sigwait patch soon, so maybe the other
    issues are less urgent. Looking at signal masks in the
    kernel (which I explained how to do in mail) only shows
    the threads the kernel knows about. I imagine the pthread
    command set in ladebug is the only way to see the signal state
    of threads blocked in user space.
    

>    the pthread_debug() isn't a totally satisfying answer, as the
>    thread -f output changes the output after a period of time
>    (I guess this is due to internal scheduling rules, as I 
>    verified it with a pthread_sigmask call, and it still was set ok,
>    even pthread_debug() reported no signals set.

No, "thread -f" will never change the output. It's strictly read-only. If the
output changes, its because the program is changing the state of the thread
over time. If the output of "thread -f" differs from the result of a real
program call to pthread_sigmask() at "the same time", then it's possible that
the debug library got spoofed because the thread was in some transition
between user & kernel states. I wouldn't trust a call to something like
pthread_sigmask, for example, from the debugger "call" command. Certainly not
unless the current thread was also the currently executing thread in the
process (the "trap" thread).

	/dave

    thanks,
    
    I'll look that I can write a small example showing this masked signal
    output behaviour. I trusted the pthread_debug, so I I traced for 
    call for sigprocmask/pthread_sigmask and even they weren't invoked
    the debug output of the masked changed (from totally empty/nothing
    masked) to the mask I've setuped in the main thread and back.
    
    Pit