[EMAIL PROTECTED] wrote:
striker 2002/08/12 15:02:18
Modified:memory/unix apr_pools.c
Log:
Fix pools to play nice with gcc bounds checking.
Submitted by: Blair Zajac <[EMAIL PROTECTED]>
Revision ChangesPath
1.184 +5 -9 apr/memory/unix/apr_pools.c
This commit adds th
On Tue, Oct 22, 2002 at 02:23:20AM -, Ryan Bloom wrote:
> rbb 2002/10/21 19:23:20
>
> Modified:include apr_errno.h
>memory/unix apr_pools.c
> Log:
> Allow people who use userdata to distinguish between a successful retrieval
> from the pool userdata, and no
On Mon, 21 Oct 2002, Aaron Bannert wrote:
> On Tue, Oct 22, 2002 at 02:23:20AM -, Ryan Bloom wrote:
> > rbb 2002/10/21 19:23:20
> >
> > Modified:include apr_errno.h
> >memory/unix apr_pools.c
> > Log:
> > Allow people who use userdata to distinguish between
On Tue, Oct 22, 2002 at 01:08:35AM -0400, Ryan Bloom wrote:
> If you try to get a value from the table, and the value isn't set, then we
> shouldn't return NULL. The fact that we can't determine the difference
> between a NULL entry and an unset key is proof that the hash table API is
> incorrect.
On Mon, 21 Oct 2002, Aaron Bannert wrote:
> On Tue, Oct 22, 2002 at 01:08:35AM -0400, Ryan Bloom wrote:
> > If you try to get a value from the table, and the value isn't set, then we
> > shouldn't return NULL. The fact that we can't determine the difference
> > between a NULL entry and an unset k
On Tue, Oct 22, 2002 at 01:49:03AM -0400, Ryan Bloom wrote:
> Because there is a difference between unset and NULL value. One of them
> was specifically set by the program, the other is a programmer trying to
> query for a value that was never set. They are two different cases. This
> is the tim
>
> On Tue, Oct 22, 2002 at 01:49:03AM -0400, Ryan Bloom wrote:
> > Because there is a difference between unset and NULL value. One of them
> > was specifically set by the program, the other is a programmer trying to
> > query for a value that was never set. They are two different
> cases. This
"Bill Stoddard" <[EMAIL PROTECTED]> writes:
> > This is just a design difference. Most shells don't make a difference
> > between unset and NULL-value. This problem hasn't come up before, and
> > you haven't provided a concrete reason why it is broken now.
>
> I agree with Aaron here.
Same. Hash
On Fri, 18 Jul 2003 [EMAIL PROTECTED] wrote:
> ===
> RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
> retrieving revision 1.196
> retrieving revision 1.197
> diff -u -r1.196 -r1.197
> --- apr_pools.c 28 May 2003 04:
> From: Cliff Woolley [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 20, 2003 8:29 PM
[...]
> Are the pool->sibling pointers uniformly protected by the pool->parent
> mutex?
Yes. The child pools are in a singly linked list, which head is pool->child.
> I haven't investigated all of the implicat
[EMAIL PROTECTED] wrote:
>striker 2003/09/27 16:51:46
>
> Modified:misc/unix start.c
> memory/unix apr_pools.c
> Log:
> * misc/unix/start.c
>
>(apr_initialize): Remove atomics initialization from this function. Due
> to circular dependency, doing it here is too
> From: Branko Cibej [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 29, 2003 2:56 AM
> [snip]
>
> I can't believe we don't have a Win32 implementation of the atomics. So
> right now, HEAD doesn't compile on Windows. :-(
Sure we do. Take a look at include/apr_atomic.h
> Is the implementat
Sander Striker wrote:
>>From: Branko Cibej [mailto:[EMAIL PROTECTED]
>>Sent: Monday, September 29, 2003 2:56 AM
>>
>>
>
>
>
>>[snip]
>>
>>I can't believe we don't have a Win32 implementation of the atomics. So
>>right now, HEAD doesn't compile on Windows. :-(
>>
>>
>
>Sure we do. Take a
Branko Äibej wrote:
>Also, I'm being double stupid because it's not APR that doesn't compile,
>it's APR-iconv. Ho hum. Now how can that happen?
>
>/me grumbles and looks
>
>
Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
Win32, Netware, FreeBSD, Linux, MVS and djgpp; no
> From: Branko Cibej [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 29, 2003 3:22 AM
> Branko Äibej wrote:
>
> >Also, I'm being double stupid because it's not APR that doesn't compile,
> >it's APR-iconv. Ho hum. Now how can that happen?
> >
> >/me grumbles and looks
> >
> >
>
> Huh, not s
Sander Striker wrote:
>>From: Branko Cibej [mailto:[EMAIL PROTECTED]
>>Sent: Monday, September 29, 2003 3:22 AM
>>
>>
>
>
>
>>Branko Äibej wrote:
>>
>>
>>
>>>Also, I'm being double stupid because it's not APR that doesn't compile,
>>>it's APR-iconv. Ho hum. Now how can that happen?
>>>
>
> From: Branko Cibej [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 29, 2003 3:31 AM
[...]
> >Looks like a definition to me... Why doesn't this work?
> >
> >
> Uh -- I said HEAD, not the 0.9 branch.
Doh.
>>> Since there's a whole bunch of atomics that do _not_ have a
>>> Win32-specific
On Mon, 29 Sep 2003, [UTF-8] Branko Ä^Libej wrote:
> >>Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
> >>Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
> >>dangling references to it in apr_pools.obj.
>
> Uh -- I said HEAD, not the 0.9 branch.
As a data
Cliff Woolley wrote:
>On Mon, 29 Sep 2003, [UTF-8] Branko ?^Libej wrote:
>
>
>
Huh, not surprising. apr_atomic.h does _not_ define apr_atomic_init on
Win32, Netware, FreeBSD, Linux, MVS and djgpp; no wonder there are
dangling references to it in apr_pools.obj.
>>Uh
On Tue, 2003-12-09 at 18:43, [EMAIL PROTECTED] wrote:
> bnicholes2003/12/09 09:43:01
>
> Modified:memory/unix apr_pools.c
> Log:
> Since all NetWare memory is shared, allowing an application access to the
> APR global pool allows it to allocate memory and set cleanups that will neve
That seems reasonable to me. We discovered the problem with mod_jk2.
The code was traversing the pool hierarchy back to the root where they
proceded to create a mutex and set a cleanup. Since the the APR
global_pool is never cleaned up from the root down while APR is in use,
the mutex was allo
On Thu, Oct 07, 2004 at 07:28:55PM -, [EMAIL PROTECTED] wrote:
> +/* temporary defines to handle 64bit compile mismatches */
> +#define APR_INT_TRUNC_CASTint
> +#define APR_UINT32_TRUNC_CAST apr_uint32_t
> +#define APR_UINT32_MAX0xUL
> +
...
>}
>
>APR_
Joe Orton wrote:
Why is this a macro? It's not like apr_uint32_t is a name which is going
to change any time soon?
It's a macro because we don't want to lose sight of the
fact that we did something there that we utimately want to
back out (i.e. in APR 2.0 when we can change the API). If
we used apr
On Thu, Oct 07, 2004 at 04:54:13PM -0400, Allan Edwards wrote:
> Joe Orton wrote:
> >Why is this a macro? It's not like apr_uint32_t is a name which is going
> >to change any time soon?
>
> It's a macro because we don't want to lose sight of the
> fact that we did something there that we utimately
On Thu, Oct 07, 2004 at 10:04:22PM +0100, Joe Orton wrote:
> On Thu, Oct 07, 2004 at 04:54:13PM -0400, Allan Edwards wrote:
> > Joe Orton wrote:
> > >Why is this a macro? It's not like apr_uint32_t is a name which is going
> > >to change any time soon?
> >
> > It's a macro because we don't want to
Joe Orton wrote:
The fact that these casts are unnecessary can be tracked using comments,
a list of issues in STATUS, or, not wishing to rock the boat, bugzilla.
Using a macro just obfuscates the code.
s/unnecessary/undesirable/
I hardly think it is more obfuscating that any
macro might be conside
On Fri, Oct 08, 2004 at 09:58:07AM -0400, Allan Edwards wrote:
> Joe Orton wrote:
> >>The fact that these casts are unnecessary can be tracked using comments,
> >>a list of issues in STATUS, or, not wishing to rock the boat, bugzilla.
> >>Using a macro just obfuscates the code.
> >
> >
> >s/unneces
On Fri, 8 Oct 2004 15:08:38 +0100, Joe Orton <[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Oct 08, 2004 at 09:58:07AM -0400, Allan Edwards wrote:
> > Joe Orton wrote:
> > >>The fact that these casts are unnecessary can be tracked using comments,
> > >>a list of issues in STATUS, or, not wishing to roc
On Fri, Oct 08, 2004 at 11:22:00AM -0400, Jeff Trawick wrote:
> If you agree with the assumption that we can't throw away the reason
> for the cast but need something in the source file to help us
> remember, then it becomes a question of the clearest way to preserve
> the information.
>
> To me,
--On Friday, October 8, 2004 4:31 PM +0100 Joe Orton <[EMAIL PROTECTED]> wrote:
I think comments would be much clearer because they'd remove the "huh?"
factor when you read the code for the first time without knowing what
the macro means. But I don't care enough to go and revert the changes
and pr
Hi,
> rbb 01/07/14 15:31:38
>
> Modified:include apr_pools.h
>memory/unix apr_pools.c
> Log:
> Add a new function to be able to cancel a child cleanup. This is
> necessary for some other work I am doing.
I wanted to open up the discussion on cleanups, but se
so you can... make your _own_ cleanup type?
say... a thread-ending-cleanup type?
you can you do per-type cleanupping?
then it will call the cleanups and only free [or
register for reuse in the free list, depends
on the sms instance implementation] areas of memory
registered by that type?
wha
On Mon, Jul 23, 2001 at 10:19:13PM -, [EMAIL PROTECTED] wrote:
> wrowe 01/07/23 15:19:13
>
> Modified:include apr_pools.h
>include/arch/unix inherit.h
>memory/unix apr_pools.c
> Log:
> Depricated the broken apr_pool_child_cleanup_kill, and add
On Mon, Jul 23, 2001 at 10:19:13PM -, [EMAIL PROTECTED] wrote:
> wrowe 01/07/23 15:19:13
>
> Modified:include apr_pools.h
>include/arch/unix inherit.h
>memory/unix apr_pools.c
> Log:
> Depricated the broken apr_pool_child_cleanup_kill, and add
From: "Justin Erenkrantz" <[EMAIL PROTECTED]>
Sent: Monday, July 23, 2001 5:40 PM
> On Mon, Jul 23, 2001 at 10:19:13PM -, [EMAIL PROTECTED] wrote:
> > wrowe 01/07/23 15:19:13
> >
> > Modified:include apr_pools.h
> >include/arch/unix inherit.h
> >m
> wrowe 01/07/23 15:19:13
>
> Modified:include apr_pools.h
>include/arch/unix inherit.h
>memory/unix apr_pools.c
> Log:
> Depricated the broken apr_pool_child_cleanup_kill, and added the new
> apr_pool_child_cleanup_set() to replace the regist
[...]
> Sorry. Here's the net, correct patch applied to apr_pools.c;
>
> Index: apr_pools.c
> ===
> RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
> retrieving revision 1.101
> retrieving revision 1.103
> diff -u -r1.101 -r1.103
>
Never mind. I saw the fix being committed...
Sander
> [...]
> > Sorry. Here's the net, correct patch applied to apr_pools.c;
> >
> > Index: apr_pools.c
> > ===
> > RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
> > retrieving re
> nope, that wasn't the change. The new one is committed, please test.
>
> Bill
Besides the == bug (got to be!), there is also a disconnect between
pools and SMS regarding cleanups. The SMS doesn't keep the "plain"
and "child" cleanups together - so they can't be referenced in the
way that the
> > wrowe 01/07/23 15:19:13
> >
> > Modified:include apr_pools.h
> >include/arch/unix inherit.h
> >memory/unix apr_pools.c
> > Log:
> > Depricated the broken apr_pool_child_cleanup_kill, and added the new
> > apr_pool_child_cleanup_set() to re
On Fri, Dec 14, 2001 at 08:14:10PM -, [EMAIL PROTECTED] wrote:
> @@ -124,7 +124,11 @@
>
>struct allocator_t {
>apr_uint32_tmax_index;
> +#if APR_HAS_THREADS
>apr_thread_mutex_t *mutex;
> +#else
> +void *mutex;
> +#endif
>apr_po
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> On Fri, Dec 14, 2001 at 08:14:10PM -, [EMAIL PROTECTED] wrote:
> > @@ -124,7 +124,11 @@
> >
> >struct allocator_t {
> >apr_uint32_tmax_index;
> > +#if APR_HAS_THREADS
> >apr_thread_mutex_t *mutex;
> > +#else
[EMAIL PROTECTED] writes:
> striker 01/12/18 10:55:39
>
> Modified:include apr_pools.h
>memory/unix apr_pools.c
> Log:
> Enable apr_pool_tag by default, instead of only when APR_POOL_DEBUG
> is defined.
Thank you very much (especially since when I tried turning o
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 10 January 2002 19:53
> To: [EMAIL PROTECTED]
> Subject: cvs commit: apr/memory/unix apr_pools.c
>
>
> striker 02/01/10 10:52:50
>
> Modified:memory/unix apr_pools
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 24 January 2002 13:18
> To: [EMAIL PROTECTED]
> Subject: cvs commit: apr/memory/unix apr_pools.c
>
> striker 02/01/24 04:18:18
>
> Modified:.configure.in
>memory/unix apr_poo
On Thu, Jan 24, 2002 at 01:41:17PM -, [EMAIL PROTECTED] wrote:
>...
> + * | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
> + * -
> + * | | | | | | | | x | General debug code enabled (good for
> --with-efence)
> + *
> + * | | | | | | | x |
Greg Stein wrote:
...
+#if defined(APR_POOL_DEBUG)
+#if (APR_POOL_DEBUG != 0) && (APR_POOL_DEBUG - 0 == 0)
+#undef APR_POOL_DEBUG
+#define APR_POOL_DEBUG 1
+#endif
+#if APR_POOL_DEBUG == 0
+#undef APR_POOL_DEBUG
+#define APR_POOL_DEBUG 1
+#en
I distinctly remember this construct failing with the DEC C compiler on
mips-dec-ultrix. I don't know if that's an ANSI compiler, but I have
that syntax did fail for me once upon a time.
Bill
Ghhh. This may have been the bug
-Fitz
On Wednesday, February 6, 2002, at 03:01 PM, [EMAIL PROTECTED] wrote:
striker 02/02/06 13:01:36
Modified:memory/unix apr_pools.c
Log:
Fix a bug where we are NULL'ing too many bytes.
Submitted by: Wil
You think I would have looked at the reply-to address before sending, but
no, that would have been too easy.
This may have been the stack-smashing bug that I've been trying to track
down on Mac OS X. (Mark Benedetto King *just* tracked it down on the OS X
side toox).
We now return you to your
From: "B. W. Fitzpatrick" <[EMAIL PROTECTED]>
Sent: Wednesday, February 06, 2002 4:14 PM
>
> You think I would have looked at the reply-to address before sending, but
> no, that would have been too easy.
>
> This may have been the stack-smashing bug that I've been trying to track
> down on Ma
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 30 May 2002 01:02
> striker 02/05/29 16:02:24
>
> Modified:memory/unix apr_pools.c
> Log:
> Don't inline and export functions at the same time.
>
> Submitted by: Branko Cibej <[EMAIL PROTECTED]>
Hmm, I meant, Suggeste
> wrowe 01/09/28 08:22:35
>
> Modified:.CHANGES
>include apr_pools.h
>memory/unix apr_pools.c
> Log:
> Introduce apr_pool_lock for debugging, in combination with
> ALLOC_USE_MALLOC + DEBUG_WITH_MPROTECT. Only implemented
> on Win3
> so you can... make your _own_ cleanup type?
Yes.
> say... a thread-ending-cleanup type?
> you can you do per-type cleanupping?
Yes.
> then it will call the cleanups and only free [or
> register for reuse in the free list, depends
> on the sms instance implementation] areas of memory
> re
54 matches
Mail list logo
