Eric,
The timestamp changed, but the content looks the same.
--
Don Poitras - Host RSAS Institute Inc.SAS Campus Drive
mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513
On Wed, Aug 14, 2019 at 9:52 AM Don Poitras wrote:
>
> Eric,
> http://people.apache.org/~covener/trunk-proxy-segv.diff looks the same. Did
> you place somewhere else?
Sorry corrected now.
(Adjusting to scp being disabled and dropped it in my actual home
directory by accident.)
Eric,
http://people.apache.org/~covener/trunk-proxy-segv.diff looks the same. Did
you place somewhere else?
--
Don Poitras - Host RSAS Institute Inc.SAS Campus Drive
mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513
On Tue, Aug 13, 2019 at 3:12 PM Don Poitras wrote:
> You also moved the worker mutex unlock so it only happens if worker->s->hmax
> != NULL
Sorry, that was a bad edit, I refreshed the patch.
your utility to assign message numbers.
> -Original Message-
> From: Eric Covener
> Sent: Monday, August 12, 2019 3:25 PM
> To: Apache HTTP Server Development List
> Subject: Re: [PATCH 63503] - Reverse proxy server - SIGSEGV
>
> Hi Don, can you try this very sim
On Mon, Aug 12, 2019 at 4:33 PM Don Poitras wrote:
>
> Eric,
> I'm not sure what you're asking. The global mutex will cover the call to
> init_conn_pool(), so there isn't a problem with worker->cp getting overlayed
> if that's what you're thinking.
I am thinking the opposite. Two threads
Eric,
I'm not sure what you're asking. The global mutex will cover the call to
init_conn_pool(), so there isn't a problem with worker->cp getting overlayed if
that's what you're thinking. The problem is that ap_proxy_initialize_worker()
gets called repeatedly with the same worker pointer. The
Via inspection this looks quite sane.
> On Aug 12, 2019, at 3:24 PM, Eric Covener wrote:
>
> Hi Don, can you try this very similar patch? I applied yours to my
> sandbox to get more context and made a few minor changes (including
> pre-existing stuff that looked misleading)
>
>
Hi Don, can you try this very similar patch? I applied yours to my
sandbox to get more context and made a few minor changes (including
pre-existing stuff that looked misleading)
http://people.apache.org/~covener/trunk-proxy-segv.diff
On Mon, Aug 12, 2019 at 2:43 PM Eric Covener wrote:
>
> On
On Mon, Aug 12, 2019 at 2:37 PM Eric Covener wrote:
>
> On Mon, Aug 12, 2019 at 12:32 PM Don Poitras wrote:
> >
> > Eric,
> > The global mutex only serializes concurrent calls to
> > ap_proxy_initialize_worker(). The worker pool is also used when the
> > proxy_handler() is called from a
On Mon, Aug 12, 2019 at 12:32 PM Don Poitras wrote:
>
> Eric,
> The global mutex only serializes concurrent calls to
> ap_proxy_initialize_worker(). The worker pool is also used when the
> proxy_handler() is called from a thread kicked off from a _previous_ call to
>
Eric,
The global mutex only serializes concurrent calls to
ap_proxy_initialize_worker(). The worker pool is also used when the
proxy_handler() is called from a thread kicked off from a _previous_ call to
ap_proxy_initialize_worker() . Turning on the pool concurrency check shows this
On Sun, Aug 11, 2019 at 9:53 AM Don Poitras wrote:
>
> Hello,
> I see that proxy_util.c was updated a few days ago. Would it be considered
> a faux-pas to contact the developer directly to request a review of this
> patch? It's been almost 2 months and I'm worried it will just get lost in the
Hello,
I see that proxy_util.c was updated a few days ago. Would it be considered a
faux-pas to contact the developer directly to request a review of this patch?
It's been almost 2 months and I'm worried it will just get lost in the noise.
--
Don Poitras - Host RSAS Institute Inc.
14 matches
Mail list logo
