Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
From: "Ante" <ante@galning.org>
To: "'Ryan Bloom'" <rbloom@gmail.com>
Cc: <dev@apr.apache.org>
Subject: RE: Hash table problems
Date: Mon, 8 Aug 2005 12:26:15 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <1f1d9820508071646741dfa82@mail.gmail.com>
Thread-Index: AcWbqjU/GXZH+NlcTd+hCKj71CNNlwAWRO0g
Message-Id: <20050808102710.DE6E537E42@smtp4-2-sn2.hy.skanova.net>

Thanks, i changed to the other pool in req2struct and it works perfect =
now.

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

I haven't really dug into the code yet, but one of the problems could
be the global variables.  If your Apache is using a multithreaded MPM,
then you are accessing a pool with multiple threads, which can be very
bad.

However, I believe the real problem is pool lifetime.  Your hej
structure is being allocated out of r->pool, which will only live for
a single request.  This happens in req2struct.  The torrents hashtable
that you are accessing is allocated out of the pool that you created
in your child_init function.  When a key/value pair are inserted into
a hash table, we don't copy the key or value, a pointer to the passed
in values are used.  This means that the pool used to allocate the
key/value must have at least the same lifetime as the pool used to
allocate the hash table.  In this case, you haven't met that
condition.  So, when your first request finishes, the request's pool
is cleared, and your key is overwritten.

Ryan

On 8/7/05, Ante <ante@galning.org> wrote:
> 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.
>=20
> -----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
>=20
> 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.
>=20
> Ryan
>=20
> 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 =3D apr_hash_get(torrents,hej->info_hash, 20))) {
> >
> >            torrent =3D 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 =3D 0x820ea20 "wl^\004U=FA=A5f>\027=B5O2HP<~\"/\220"
> >
> > (gdb) watch *0x820ea20
> >
> > Hardware watchpoint 17: *136374816
> >
> > (gdb) c
> >
> > Continuing.
> >
> > Hardware watchpoint 17: *136374816
> >
> >
> >
> > Old value =3D 73297015
> >
> > New value =3D 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=3D0x820ea08, p=3D0x820d330,
> > nelts=3D4,
> >
> >     elt_size=3D8, clear=3D1) at apr_tables.c:63
> >
> > #2  0x4027ed8f in apr_array_make (p=3D0x820d330, nelts=3D4, =
elt_size=3D8)
> >
> >     at apr_tables.c:86
> >
> > #3  0x0808352d in prep_walk_cache (t=3D0, r=3D0x820d368) at =
request.c:306
> >
> > #4  0x080838a6 in ap_directory_walk (r=3D0x820d368) at request.c:511
> >
> > #5  0x080802af in core_map_to_storage (r=3D0x820d368) at core.c:3420
> >
> > #6  0x0808263b in ap_run_map_to_storage (r=3D0x820d368) at =
request.c:67
> >
> > #7  0x08083052 in ap_process_request_internal (r=3D0x820d368) at
> > request.c:149
> >
> > #8  0x080666ba in ap_process_request (r=3D0x820d368) at
> > http_request.c:247
> >
> > #9  0x08060d63 in ap_process_http_connection (c=3D0x8207330) at
> > http_core.c:251 #10 0x0807496e in ap_run_process_connection
> > (c=3D0x8207330) at
> > connection.c:43
> >
> > #11 0x08074d5c in ap_process_connection (c=3D0x8207330, =
csd=3D0x8207278)
> >
> >     at connection.c:176
> >
> > #12 0x08068023 in child_main (child_num_arg=3D0) at prefork.c:610
> >
> > #13 0x080680fa in make_child (s=3D0x80a9ea0, slot=3D0) at =
prefork.c:650
> >
> > #14 0x08068222 in startup_children (number_to_start=3D10) at
> > prefork.c:722
> >
> > #15 0x0806862b in ap_mpm_run (_pconf=3D0x80a80f0, plog=3D0x80d2198,
> > s=3D0x80a9ea0)
> >
> >     at prefork.c:941
> >
> > #16 0x0806f239 in main (argc=3D2, argv=3D0xbffffb24) at main.c:618
> >
> >
> >
> > Any suggestions how I should fix this?
> >
> >
> >
> > //Andreas
>=20
>=20
> --
> Ryan Bloom
> rbb@apache.org
> rbb@rkbloom.net
> rbloom@gmail.com
>=20
>=20
>=20


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