apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45248] testlockperf of apr_thread_rwlock_t stalls forever on i686 Linux / glibc 2 .7
Date Wed, 25 Jun 2008 22:58:04 GMT

Nix <nix@esperi.org.uk> changed:

           What    |Removed                     |Added
             Status|NEEDINFO                    |ASSIGNED

--- Comment #5 from Nix <nix@esperi.org.uk>  2008-06-25 15:58:03 PST ---
Fascinating. I tried to bisect the bug, only to find that it doesn't work as
far back as I can go (1.2.0 doesn't work, earlier versions require libtool
downgrades so I didn't go further back). I know for a fact that 1.2.6 worked
for me when I built it, so obviously something external to apr has changed.

>From my upgrade logs I strongly suspect glibc 2.5 -> 2.6.1 (I'm on 2.7 now,
going to 2.8 fairly shortly), although it could be the kernel, I suppose. I'll
do a test glibc reversion in a chroot and see how that flies.

(The distro, well, it was Linux From Scratch a decade before LFS was cool. My
autobuilders work well enough that I see no point using someone else's distro,
plus it means I get to find all sorts of interesting bugs like, well, this

Sorry for the gdb stupidity: I do know how to use it but not when under hay
fever drugs of this intensity ;}

Looking again (with 1.3.2), the two-thread case freezes up now.

apr_thread_rwlock_t Tests
    Initializing the apr_thread_rwlock_t                    OK
    Starting 2 threads    OK

  2 Thread 0x40250b90 (LWP 15230)  0x40000424 in __kernel_vsyscall ()
  1 Thread 0x4004f7e0 (LWP 15222)  0x40000424 in __kernel_vsyscall ()

(gdb) thread 1
[Switching to thread 1 (Thread 0x4004f7e0 (LWP 15222))]#0  0x40000424 in
__kernel_vsyscall ()
(gdb) bt
#0  0x40000424 in __kernel_vsyscall ()
#1  0x4b28b478 in pthread_join () from /lib/libpthread.so.0
#2  0x4002222f in apr_thread_join (retval=0xbf918a68, thd=0x9ce6328) at
#3  0x08048c97 in test_thread_rwlock (num_threads=2) at testlockperf.c:212
#4  0x08049228 in main (argc=Cannot access memory at address 0x0
) at testlockperf.c:276
(gdb) thread 2
[Switching to thread 2 (Thread 0x40250b90 (LWP 15230))]#0  0x40000424 in
__kernel_vsyscall ()
(gdb) bt
#0  0x40000424 in __kernel_vsyscall ()
#1  0x4b290ec2 in __lll_lock_wait () from /lib/libpthread.so.0
#2  0x4b28de60 in pthread_rwlock_wrlock () from /lib/libpthread.so.0

If I continue, the lock is released and the three-thread case sweeps by without
problems. If I run it under GDB directly rather than attaching, it never hangs.

I tried running it under valgrind to drastically change the performance
profile, and bingo, a three-thread hang, last displayed:

apr_thread_rwlock_t Tests
    Initializing the apr_thread_rwlock_t                    OK
    Starting 3 threads    OK

Unfortunately interrupting valgrind while hung isn't very useful: the interrupt
happens while you're inside the valgrind VM, and that confuses gdb's unwinder
(on account of that VM being relocated) so that all you get is something like

#0  0x3807211c in ?? ()
#1  0x38746cf0 in ?? ()
#2  0x3887ca7c in ?? ()
#3  0x6234deec in ?? ()
#4  0x38746cfc in ?? ()

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

View raw message