apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ante" <a...@galning.org>
Subject RE: Hash table problems
Date Sun, 07 Aug 2005 18:50:14 GMT
I attached the whole source, the pool is a global variable and is created in
p_child_init. I think that should work anyways. The hej structure is
allocated on line 229 and added to the hash list if the key isn't found.

-----Original Message-----
From: Ryan Bloom [mailto:rbloom@gmail.com]
Sent: den 7 augusti 2005 20:33
To: Ante
Cc: dev@apr.apache.org
Subject: Re: Hash table problems

You haven't really given enough information to let us help you.  What is
hej, and how is it allocated?  The spot that the memory is getting
overwritten is in the Apache core, so this really should be happening.
 But, if that memory is allocated from a pool that doesn't live as long as
you think it does, then this could happen.  You can either send me a copy of
the module so that I can look at what is happening, or reply here with more
information about what you are doing with the key variable.

Ryan

On 8/7/05, Ante <ante@galning.org> wrote:
>  
>  
> 
> Hi, I'm writing a apache module and uses apr hash tables but my hash 
> key keeps getting overwritten, here's the code I use
> 
>   
> 
> if(!(torrent = apr_hash_get(torrents,hej->info_hash, 20))) {
> 
>            torrent = apr_pcalloc(pool, sizeof(struct torrent));
> 
>            apr_hash_set(torrents, hej->info_hash, 20, torrent); }
> 
>   
> 
> I set a watchpoint with gdb and the key got overwritten in
make_array_core.
> Here is a backtrace. 
> 
>   
> 
> (gdb) print (char *) 0x820ea20
> 
> $183 = 0x820ea20 "wl^\004Uú¥f>\027µO2HP<~\"/\220" 
> 
> (gdb) watch *0x820ea20
> 
> Hardware watchpoint 17: *136374816
> 
> (gdb) c
> 
> Continuing. 
> 
> Hardware watchpoint 17: *136374816
> 
>   
> 
> Old value = 73297015
> 
> New value = 0
> 
> 0x403d621b in memset () from /lib/libc.so.6
> 
> (gdb) backtrace
> 
> #0  0x403d621b in memset () from /lib/libc.so.6
> 
> #1  0x4027ecdc in make_array_core (res=0x820ea08, p=0x820d330, 
> nelts=4,
> 
>     elt_size=8, clear=1) at apr_tables.c:63
> 
> #2  0x4027ed8f in apr_array_make (p=0x820d330, nelts=4, elt_size=8)
> 
>     at apr_tables.c:86
> 
> #3  0x0808352d in prep_walk_cache (t=0, r=0x820d368) at request.c:306
> 
> #4  0x080838a6 in ap_directory_walk (r=0x820d368) at request.c:511
> 
> #5  0x080802af in core_map_to_storage (r=0x820d368) at core.c:3420
> 
> #6  0x0808263b in ap_run_map_to_storage (r=0x820d368) at request.c:67
> 
> #7  0x08083052 in ap_process_request_internal (r=0x820d368) at 
> request.c:149
> 
> #8  0x080666ba in ap_process_request (r=0x820d368) at 
> http_request.c:247
> 
> #9  0x08060d63 in ap_process_http_connection (c=0x8207330) at
> http_core.c:251 #10 0x0807496e in ap_run_process_connection 
> (c=0x8207330) at
> connection.c:43
> 
> #11 0x08074d5c in ap_process_connection (c=0x8207330, csd=0x8207278)
> 
>     at connection.c:176
> 
> #12 0x08068023 in child_main (child_num_arg=0) at prefork.c:610
> 
> #13 0x080680fa in make_child (s=0x80a9ea0, slot=0) at prefork.c:650
> 
> #14 0x08068222 in startup_children (number_to_start=10) at 
> prefork.c:722
> 
> #15 0x0806862b in ap_mpm_run (_pconf=0x80a80f0, plog=0x80d2198, 
> s=0x80a9ea0)
> 
>     at prefork.c:941
> 
> #16 0x0806f239 in main (argc=2, argv=0xbffffb24) at main.c:618
> 
>   
> 
> Any suggestions how I should fix this? 
> 
>   
> 
> //Andreas


-- 
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com

Mime
View raw message