apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <bl...@orcaware.com>
Subject Re: testall core dump with apr HEAD
Date Wed, 20 Aug 2003 16:40:54 GMT
Blair Zajac wrote:
> 
> Hello,
> 
> I just compiled CVS HEAD of apr and apr-util to build httpd 2.1.
> 
> I'm getting a core dump in running testall:
> 
> % gdb .libs/lt-testall
> GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux-gnu"...
> (gdb) run
> Starting program: /export/home1/blair/Code/Apache/2.0/h/srclib/apr/test/.libs/lt-testall
> [New Thread 1074592640 (LWP 16810)]

Can anybody verify this bug quickly.  Should just take a second.

Here's my output from valgrind:

% valgrind .libs/lt-testall
==20965== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==20965== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==20965== Using valgrind-1.9.6, a program instrumentation system for x86-linux.
==20965== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==20965== Estimated CPU clock rate is 1396 MHz
==20965== For more details, rerun with: -v
==20965==
==20965== Invalid read of size 4
==20965==    at 0x4027B6F8: apr_atomic_cas (apr_atomic.c:166)
==20965==    by 0x4027898C: apr_thread_mutex_lock (thread_mutex.c:129)
==20965==    by 0x4027A748: apr_pool_create_ex_debug (apr_pools.c:1540)
==20965==    by 0x402775D1: apr_initialize (start.c:96)
==20965==    Address 0xC is not stack'd, malloc'd or free'd

#0  0x400306f8 in apr_atomic_cas (mem=0x80bc4d8, with=0, cmp=0)
    at apr_atomic.c:166
166         apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)];
(gdb) p mem
$1 = (volatile apr_uint32_t *) 0x80bc4d8

The odd thing is that hash_mutex is NULL.

I ran gdb on testall and put a breakpoint on apr_atomic_init and
continued the program, and then it core dumped before reaching the
function.

It looks like a mutex is being created before hash_mutex is
initialized:

% gdb ./.libs/lt-testall
(gdb) b main
Breakpoint 1 at 0x804b5cc: file testall.c, line 118.
(gdb) r
Starting program: /export/home1/blair/Code/Apache/2.0/h/srclib/apr/test/.libs/lt-testall
[New Thread 1074583872 (LWP 21588)]
[Switching to Thread 1074583872 (LWP 21588)]

Breakpoint 1, main (argc=1, argv=0xbfffd9e4) at testall.c:118
118         CuString *output = CuStringNew();
(gdb) b apr_atomic_init
Breakpoint 2 at 0x40030509: file apr_atomic.c, line 73.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x400306f8 in apr_atomic_cas (mem=0x80bc4d8, with=0, cmp=0) at apr_atomic.c:166
166         apr_thread_mutex_t *lock = hash_mutex[ATOMIC_HASH(mem)];

Best,
Blair

-- 
Blair Zajac <blair@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/

Mime
View raw message