Re: XForms: More on the subject of threads

From: Steve Lamont (
Date: Sat Jun 17 2000 - 10:28:23 EDT

  • Next message: Paolo Prandini: "R: XForms: More on the subject of threads"

    # To subscribers of the xforms list from Steve Lamont <spl@blinky.UCSD.Edu> :

    > Anyway here is the back trace of the test program after being
    > locked with a keypress:
    > (gdb) bt
    > #0 0x4022a24a in sigsuspend () from /lib/
    > #1 0x401a0d89 in __pthread_lock (lock=0x804dc28, self=0x401a7200)
    > at restart.h:32
    > #2 0x4019e976 in __pthread_mutex_lock (mutex=0x804dc18) at mutex.c:84
    > #3 0x40128931 in _XLockDisplay () from /usr/X11R6/lib/
    > #4 0x4013170b in XkbGetUpdatedMap () from /usr/X11R6/lib/

    Hm. It certainly looks as if there's a deadlock situation. Some
    other thread has probably gotten hold of the lock. Can you look at
    the other threads and see if any of the others have the lock?

    Perhaps by looking at the innards of the mutex you can figure out
    which thread has grabbed the lock.

    I'm not sure what the Linux `pthread_mutex_t' definition is. Under
    Solaris there is a member `__pthread_mutex_lock' which contains what
    appears to be the owner of the lock. If you can figure out the
    internal structure of that, perhaps by digging into the source for
    `', you may be on the trail of something.

    It does certainly seem as if there's some problem in Xlib itself with
    more than one thread snagging the display lock.

    Check the `gdb' documentation for info on debugging threads if you
    haven't done so already. The command

            info threads

    will tell you what threads are currently running.

            thread THREADNO

    will make THREADNO the current thread.

    To unsubscribe, send the message "unsubscribe" to or see
    XForms Home Page:
    List Archive:

    This archive was generated by hypermail 2b29 : Sat Jun 17 2000 - 10:32:04 EDT