Re: [PATCH] Bug 2976: invalid URL on intercepted requests during reconfigure

On 03/02/2011 02:19 PM, Amos Jeffries wrote:
>
> While investigating bug 2976 (URLs suddenly becoming (null)://foo/ on
> intercepted traffic for a few seconds) it has become clear that the
> listening ports are badly abusing cbdata.
>
> They *are* passed as cbdata parameters from IPC to the connection
> accepting routines. However the parser is not aware of their cbdata'ness
> and is using new/delete directly on the config pointers.

Ouch. For the record, could you please paste the offending code that "is
using new/delete directly on the config pointers" if you still remember
where those offenders were?

> Long term I think the right solution is to RefCount the http_port_list
> object. Since their main property seems to be that the ConnStateData
> retain a long-term pointers to them despite SquidConfig disappearing.

It would be nice to come up with a unified approach to [re]configuration
for the long-term fix. A lot of code, from adaptation to storage, does
not support [re]configuration [well] because of similar problems.

I think we should
(a) make SquidConfig refcountable and its small pieces copy-able;
(b) make SquidConfig or any separately stored pieces constant;
(c) remove any state-changing code from the configuration code.

The configuration code should only be concerned with creating/parsing,
reporting, manipulating, and cleaning configuration options. One should
be able to copy small and efficiently share large configuration objects,
without worrying about reconfiguration wiping out or modifying those
objects. One should also be able to create several complete
configuration objects without any effect on Squid state (other than RAM
usage).

Thank you,

Alex.
Received on Wed Mar 09 2011 - 18:14:13 MST