Re: Making start/stop idempotent
http://www.squid-cache.org/bugs/show_bug.cgi?id=2599 On 31/10/2008, at 3:59 AM, Alex Rousskov wrote: On Thu, 2008-10-30 at 00:58 +0100, Henrik Nordstrom wrote: On tor, 2008-10-30 at 10:03 +1100, Mark Nottingham wrote: Hmm, good point. My aim was just start and stop. Seem reasonable to just limit it to those two? Yes. And maybe maybe rotate. Perhaps rotate should continue to fail. Those who do not like that, can always do something like "!check || rotate" in their cron jobs, right? In general, an operation that cannot accomplish its goal should fail. I am not going to fight against shutdown pretending that it has shutdown Squid, but faking rotate is more dangerous than convenient, IMO. Thanks, Alex. -- Mark Nottingham m...@yahoo-inc.com
Re: Lessons learned from string-fix and consequences on StringNg design
>> Definately. With a 32-bit signed size it _should_ be large enough for >> most uses. A debugs when it goes close to or over the signed rollover >> would be critical IMO. Maybe more, but debugs & assert for now. > Do not assert(), just use Must(false) or equivalent. No reason to kill > the proxy if the caller can simply cancel the offending transaction. > StringNg already uses exceptions for exceptional situations and this is > no different. I agree. In fact, I've defined a SBufTooBigException (inheriting TextException) for the purpose. -- /kinkie
Re: [MERGE] compat round 3
On 02/14/2009 10:09 PM, Amos Jeffries wrote: > Alex has managed to convince me that its okay to use just compat/* > So here is another round. Thank you for making this change! I think this patch still #includes compat/foo.h headers as foo.h. It should be #include "compat/foo.h" for all compat/*.h. Similarly, #include "compat/os/foo.h" is the right way to include. This applies to all #include cases, even inside foo.cc itself! I suspect you tried to fix this but missed a few cases. One example violating the above rule is GnuRegex.h. You can easily check by iterating over *.h files in compat/ and grepping the patch for the corresponding #include lines that do not have compat/. The same rule should apply to all other headers that are inside their own [polished] directories. Thank you, Alex.
Re: Lessons learned from string-fix and consequences on StringNg design
On 02/13/2009 10:00 PM, Amos Jeffries wrote: > Kinkie wrote: >> On Fri, Feb 13, 2009 at 11:36 AM, Henrik Nordstrom >> wrote: >>> tor 2009-02-12 klockan 17:19 +0100 skrev Kinkie: It would IMHO make sense to: 1. introduce StringNg::size_type, which should be a _signed_ 32-bit integer 2. introduce a static const StringNg::npos = -1 to be used in place of std::string::npos >>> Or use size_t in the API while using a smaler type in the internal >>> representation. >>> >>> size_t is only making a mess for printf style operations, and it's >>> relatively easy to deal with (and have to be dealt with at a number of >>> other locations..) >> >> Also doable. >> Currently there is no overflow-checks. Should they be added or should >> we rely in the callers? Anyone in favour of having some debugs() when >> a Buffer surpasses some predefined dimension? > > Definately. With a 32-bit signed size it _should_ be large enough for > most uses. A debugs when it goes close to or over the signed rollover > would be critical IMO. Maybe more, but debugs & assert for now. Do not assert(), just use Must(false) or equivalent. No reason to kill the proxy if the caller can simply cancel the offending transaction. StringNg already uses exceptions for exceptional situations and this is no different. Thank you, Alex.
Re: Squid 3.1.0.5 uses memory without bounds
mån 2009-02-16 klockan 14:27 +0100 skrev Steinar H. Gunderson: > I've reported dumps of these several times already. I'm not entirely sure > what more information you need. Not sure either. What I do know however is that valgrind traces in general gets very unreliable unless Squid is built with valgrind support. This due to some of the memory allocation magics Squid is performing resulting in valgrind not really knowing what is inuse or not or from where memory really was allocated. The --with-valgrind-debug option not only enables valgrind instrumentation to the code, it also switches cbdata and memory pools to a malloc tracer friendly mode of operation. I also know from experience that shutdown traces often is quite misleading as well, mostly due to the shutdown cleanup in Squid not cleaning everything up properly (not really needed as the os frees it all on exit, so nobody cares much), often resulting in false leak indications in such traces. I have found runtime valgrind reports triggered by mgr:mem to be very accurate however. Also you mentioned CBDataCall growing a lot.. that's from --enable-debug-cbdata, not related to valgrind. Not sure anyone has verified that code ever in Squid-3, or if it even provides any meaningful data. Adds another cachemgr screen with detailed cbdata info. Regards Henrik
Re: Lessons learned from string-fix and consequences on StringNg design
On Sat, Feb 14, 2009 at 6:00 AM, Amos Jeffries wrote: > Kinkie wrote: >> >> On Fri, Feb 13, 2009 at 11:36 AM, Henrik Nordstrom >> wrote: >>> >>> tor 2009-02-12 klockan 17:19 +0100 skrev Kinkie: It would IMHO make sense to: 1. introduce StringNg::size_type, which should be a _signed_ 32-bit integer 2. introduce a static const StringNg::npos = -1 to be used in place of std::string::npos >>> >>> Or use size_t in the API while using a smaler type in the internal >>> representation. >>> >>> size_t is only making a mess for printf style operations, and it's >>> relatively easy to deal with (and have to be dealt with at a number of >>> other locations..) >> >> Also doable. >> Currently there is no overflow-checks. Should they be added or should >> we rely in the callers? Anyone in favour of having some debugs() when >> a Buffer surpasses some predefined dimension? > > Definately. With a 32-bit signed size it _should_ be large enough for most > uses. A debugs when it goes close to or over the signed rollover would be > critical IMO. Maybe more, but debugs & assert for now. I've added an (arbitrary) limit at 256Mb, tuneable via static const. -- /kinkie
Re: Squid 3.1.0.5 uses memory without bounds
On Sun, Feb 15, 2009 at 06:33:41PM +0100, Henrik Nordstrom wrote: > In squid-3 it's --enable-valgdind-debug I assume you meant valgrind, not valgdind :-) > If you get a valgrind report in cache.log (or stderr) when visiting the > memory statistics cahemgre page (mgr:mem) then it's compiled correctly. > I think there is also a leak summary in the page itself. Still nothing, even after adding that flag and recompiling. It shows the same thing as the pprof logs, though; CbDataList eats memory like candy. > a) Confirmed leaks by valgrind. > > b) Memory pools which don't stop growing. Identified by their age being > 0.0 all the time. > > and additionally > > c) Memory access errors reported by valgrind. I've reported dumps of these several times already. I'm not entirely sure what more information you need. /* Steinar */ -- Homepage: http://www.sesse.net/
