Can somebody please summarize what the different members of the pthread_rwlock_t means?
struct { int __lock; unsigned int __nr_readers; unsigned int __readers_wakeup; unsigned int __writer_wakeup; unsigned int __nr_readers_queued; unsigned int __nr_writers_queued; int __writer; int __shared; unsigned long int __pad1; unsigned long int __pad2; /* FLAGS must stay at this position in the structure to maintain binary compatibility. */ unsigned int __flags; } __data;I am debugging one deadlock where the lock states looks like:
{__data = { __lock = 2, __nr_readers = 24644, __readers_wakeup = 28432136, __writer_wakeup = 24644, __nr_readers_queued = 0, __nr_writers_queued = 0, __writer = 0, __shared = 0, __pad1 = 0, __pad2 = 0, __flags = 0}, __size = "\002\000\000\000D`\000\000\bױ\001D`", '\000' <repeats 41 times>, __align = 105845174042626}And the thread is blocked while trying to acquire read lock on it. Is the lock structure looks sane?
The operating system is CentOS 7.6, with glibc-2.17-260.el7_6.3.x86_64.
91 Answer
Current versions of GNU libc (version 2.25 and later) ship gdb extensions that will decode the members of various pthread structures, including pthread_rwlock_t. However, looking at the code for this extension, it expects the contents of pthread_rwlock_t to be quite different from what you have shown, so manually applying it to your data dump will be of no use. For the same reason, I can't tell you what the fields mean.
If you tell us exactly which Linux distribution you are using, its age, and what the output of running /lib/libc.so.6 as if it were a program is (if that file doesn't exist, look for it in subdirectories of /lib and /lib64), we might be able to be more helpful.
It would also be worth attempting to move your program onto a newer Linux distribution and seeing if you can still reproduce the problem. Then you can use the gdb extensions yourself.
5