# 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/libc.so.6
> #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/libX11.so.6
> #4 0x4013170b in XkbGetUpdatedMap () from /usr/X11R6/lib/libX11.so.6
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
`libc.so.6', 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.
spl
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://world.std.com/~xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/
This archive was generated by hypermail 2b29 : Sat Jun 17 2000 - 10:32:04 EDT